Include following changes:
- allow compilation for iOS projects;
- handle unicode pathname when loading source on Python 2;
- update JediHTTP;
- update Boost to 1.64.0;
- create a symlink instead of renaming libclang;
- ignore identifiers from comments and strings on certain events;
- ignore identifiers from comments and strings by filetype;
- improve CSS identifier regex;
- fix Godef build error;
- search Python library in lib64 folder in addition to lib;
- specify .NET Framework 4.5.
[READY] Clean C# inserting namespace code
Now that we require at least Vim 7.4.1578, we can remove the code that automatically insert namespaces in C# for Vim versions prior to 7.4.774.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2650)
<!-- Reviewable:end -->
[READY] Display diagnostics and parse initial buffer asynchronously using timers
Currently, we wait for an autocommand to trigger to display diagnostics. This is not ideal as users have to do some actions like moving the cursor or editing the buffer to see them. We can improve that by using [the timers feature introduced in Vim 7.4.1578](975b5271ee) to display diagnostics asynchronously. Here's a demo:
By displaying diagnostics asynchronously, we can drop the `CursorHold` and `CursorHoldI` autocommands as well as [the `g:ycm_allow_changing_updatetime` option](5a806dcb30/README.md (the-gycm_allow_changing_updatetime-option)). In addition, we can now parse the current buffer and display diagnostics on the `TextChanged` event instead of the `CursorMoved` one. Note that we still need to check `b:changed_tick` for the `InsertLeave` event.
Given that our policy is to support the latest version of Ubuntu LTS which is 16.04, and that version [bundles Vim 7.4.1689](http://packages.ubuntu.com/xenial/vim), we can increase our Vim version requirement to 7.4.1578.
Next steps will be to use timers for parsing the buffer when the server becomes ready and for completions.
Fixes https://github.com/Valloric/YouCompleteMe/issues/2165.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2636)
<!-- Reviewable:end -->
Use the timers feature to display diagnostics asynchronously instead of waiting
for an autocommand to trigger.
Increase Vim version requirement to 7.4.1578.
Drop the CursorHold and CursorHoldI autocommands.
Parse buffer on the TextChanged autocommand instead of CursorMoved.
[READY] Improve reparse requirement on BufEnter event
When opening a file, Vim triggers the `BufRead` event then the `BufEnter` one. By setting the `s:previous_allowed_buffer_number` variable in `s:AllowedToCompleteInBuffer`, we avoid a reparse on `BufEnter` after parsing the buffer on `BufRead`. This reduces the number of `BufferVisit` and `FileReadyToParse` requests sent to the server by one when opening a file.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2644)
<!-- Reviewable:end -->
[READY] Drop BufRead event
Since [we don't parse the buffer if no filetype is set](ad00f4c3f4/autoload/youcompleteme.vim (L334)), calling `s:OnBufferRead` on the `BufRead` event is only useful if the buffer filetype is set. But if that's the case, this means that the `FileType` event was fired before the `BufRead` one and thus the `s:OnBufferRead` function is already called. So, there is no point in calling `s:OnBufferRead` on the `BufRead` event. In fact, this costs us a `BufferVisit` and a `FileReadyToParse` request for nothing.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2645)
<!-- Reviewable:end -->
Considering that a buffer won't be parsed if no filetype is set and that it's
already parsed if the filetype is set when reading a buffer, there is no point
in parsing a buffer on the BufRead event.
[READY] Update autocommands examples in documentation
I am not aware of a Vim option to not switch to the location list (or quickfix) window when calling `lopen` (respectively `copen`) so I think it's a good idea to give an example in the docs on how to achieve this using the `YcmLocationOpened` and `YcmQuickFixOpened` autocommands.
Also, the `execute` calls are not needed.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2635)
<!-- Reviewable:end -->
[READY] Force parsing on buffer visit
When visiting a buffer that was previously parsed, its last parse may be outdated because of changes from other buffers. We need to force a new parse.
This partially fixes issue https://github.com/Valloric/YouCompleteMe/issues/2165 in the sense that you don't have to edit the buffer (or call `:YcmForceCompileAndDiagnostics`) anymore to refresh diagnostics but you still have to wait for the `CursorHold` event. This can be further improved by displaying diagnostics asynchronously using timers.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2629)
<!-- Reviewable:end -->
[READY] Refactor b:ycm_changedtick variable
Since we only use the `b:ycm_changedtick` variable to track the last time we parsed the buffer, we can change it to store a number instead of a dictionary.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2614)
<!-- Reviewable:end -->
[READY] Fix diagnostic highlighting with invalid location extent
ycmd may return a location extent with a starting column of zero (see the test for an example) which is not a valid column (columns are 1-indexed). We should use the location in this case. Also, when the location extent is not valid, we should call `AddDiagnosticSyntaxMatch` with the `is_error` parameter to highlight warnings as such and not as errors (`is_error` is `True` by default).
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2602)
<!-- Reviewable:end -->
[READY] Do not cache Python interpreter path
Once YCM is installed through a plugin manager in Vim (e.g. using the `:PluginInstall` command with Vundle), it picks a Python interpreter (most likely the one used to run YCM inside Vim), caches it, and starts the server with it. This fails since the `ycm_core` library is not yet compiled and the following message is displayed on the status line:
```
The ycmd server SHUT DOWN (restart with ':YcmRestartServer'). YCM core library not detected; you need to compile YCM before using it. Follow the instructions in the documentation.
```
After reading the documentation, the user may then build the library directly from Vim:
```
:!/path/to/YCM/install.py
```
or by opening a new terminal and calling the `install.py` script without leaving Vim. Once the compilation is done, he will restart the server with the `:YcmRestartServer` command. However, since the Python interpreter used to start the server is already cached, YCM will not pick the one from the `PYTHON_USED_DURING_BUILDING` file generated by the `install.py` script. If these Pythons are different (e.g. Python 2 versus Python 3), YCM will fail to start the server again. This doesn't happen if we don't cache the Python interpreter path.
I suspect this is the issue experienced in #2431 and often reported by users on Ubuntu 16.04 where Vim is compiled with Python 3 support but default Python is Python 2. See https://github.com/Valloric/YouCompleteMe/pull/2140#issuecomment-273495342 and https://github.com/Valloric/YouCompleteMe/issues/35#issuecomment-290877053.
Fixes#2431.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2598)
<!-- Reviewable:end -->
[READY] Split the OnBufferVisit function again
We can't use `VisitedBufferRequiresReparse` for the `FileType` autocommand event because ycmd may parse a buffer differently depending on its filetype. We have to use `AllowedToCompleteInCurrentBuffer` for this event (we can also use it for the `BufRead` one).
Fixes https://github.com/Valloric/ycmd/issues/731.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2595)
<!-- Reviewable:end -->
Send extra_conf_vim_data in requests from :YcmCompleter and :YcmDebugInfo commands
Send extra_conf_vim_data in requests from :YcmCompleter and :YcmDebugInfo commands. It's needed for passing compile_commands.json directory to every call of FlagsForFile in client_data argument.
# PR Prelude
Thank you for working on YCM! :)
**Please complete these steps and check these boxes (by putting an `x` inside
the brackets) _before_ filing your PR:**
- [ x] I have read and understood YCM's [CONTRIBUTING][cont] document.
- [ x] I have read and understood YCM's [CODE_OF_CONDUCT][code] document.
- [ x] I have included tests for the changes in my PR. If not, I have included a
rationale for why I haven't.
- [x ] **I understand my PR may be closed if it becomes obvious I didn't
actually perform all of these steps.**
# Why this change is necessary and useful
Directory of compile_commands.json may be different for different configurations. And there is needed a way for passing it to every call of FlagsForFile in client_data argument.
[Please explain **in detail** why the changes in this PR are needed.]
[cont]: https://github.com/Valloric/YouCompleteMe/blob/master/CONTRIBUTING.md
[code]: https://github.com/Valloric/YouCompleteMe/blob/master/CODE_OF_CONDUCT.md
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2570)
<!-- Reviewable:end -->
[READY] Prioritize errors over warnings on the same line
When multiple diagnostics are on the same line, warnings may have higher priority than errors. See #2141 for an example. This happens for several reasons:
- we sort diagnostics by column and then by kind. We should do the opposite;
- we place all signs; each sign overriding the previous one. Since only one sign is visible by line, we should just insert the first one (which has the highest priority);
- we draw highlighting matches (squiggles) in the same order as diagnostics; each match being drawn over the previous ones. We should draw them in reverse order (from lowest to highest priority).
Fixes#2141.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2592)
<!-- Reviewable:end -->
[READY] Merge back OnBufferRead and OnBufferEnter into OnBufferVisit
PR #2312 introduced an issue where the `completeopt`, `completefunc`, and `omnifunc` options are not set for buffers opened before the plugin is loaded. The `OnBufferVisit` function was split into `OnBufferRead` and `OnBufferEnter` but `SetUpCompleteopt`, `SetCompleteFunc`, and `SetOmnicompleteFunc` were not copied to `OnBufferEnter`.
Since the result of `VisitedBufferRequiresReparse` is identical to `AllowedToCompleteInCurrentBuffer` for a new buffer (its buffer number is necessarily new), we merge back the two functions into `OnBufferVisit` to fix the issue. Also, we change the `DisableOnLargeFile` function to include it in `AllowedToCompleteInCurrentBuffer`. This reduces duplication of code.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2589)
<!-- Reviewable:end -->
[READY] Accept capitalized name for Python executable
I was looking at `PathToPythonInterpreter` coverage and was surprised to see [that line](
01570aac03/python/ycm/paths.py (L84)) covered. This shouldn't be the case since we are supposed to use the Python from `PYTHON_USED_DURING_BUILDING`. This happens because the Python executable used in our Travis builds on macOS is named `Python` (with a capital letter) and so we don't accept it.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2590)
<!-- Reviewable:end -->
[READY] Remove Python version check
Even with the `-S` option (see PR https://github.com/Valloric/YouCompleteMe/pull/2502), starting the Python interpreter to check its version can be slow. For instance, on my machine (in PowerShell):
```ps
> Measure-Command -Expression {python -S -c "pass"}
...
TotalMilliseconds : 25,4387
```
It's also not particularly useful because, in the typical case, the Python used to start ycmd will be the one from `PYTHON_USED_DURING_BUILDING` which is necessarily a supported version. In the cases where the `g:ycm_server_python_interpreter` option is specified or a Python is found in the PATH, it's up to the user to provide a supported version. If they don't, the ycmd server will probably fail to start and the following error will be displayed to them:
```
The ycmd server SHUT DOWN (restart with ':YcmRestartServer'). Unexpected exit code 1. Use the ':YcmToggleLogs' command to check the logs.
```
They can then look at the logs to understand what went wrong.
Finally, the last case is when the Python is the one used by YCM itself. In that case, if the Python version is not supported, it will fail before doing the check so it doesn't matter.
As always, here are the improvements on startup time:
<table>
<tr>
<th rowspan="2">Platform</th>
<th colspan="2">First run (ms)</th>
<th colspan="2">Subsequent runs (ms)</th>
</tr>
<tr>
<td>Before</td>
<td>After</td>
<td>Before</td>
<td>After</td>
</tr>
<tr>
<td>Ubuntu 16.04 64-bit</td>
<td>147</td>
<td>134</td>
<td>74</td>
<td>65</td>
</tr>
<tr>
<td>macOS 10.12</td>
<td>189</td>
<td>165</td>
<td>127</td>
<td>107</td>
</tr>
<tr>
<td>Windows 10 64-bit</td>
<td>242</td>
<td>200</td>
<td>147</td>
<td>115</td>
</tr>
</table>
*Results obtained by running the `prof.py` script from [this branch](https://github.com/micbou/YouCompleteMe/tree/profiling-startup) on Python 3.6.*
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/2585)
<!-- Reviewable:end -->
