We eagerly compile all the filters up front, then gather the
compiled filters into a DiagnosticFilter lazily, caching the
result to avoid garbage lists.
[READY] Move test_utils.py file to tests folder
We don't want `test_utils.py` to appear in the coverage reports. Instead of blacklisting it in `.coveragerc`, we move it to the tests folder.
This will decrease coverage.
<!-- 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/2389)
<!-- Reviewable:end -->
[READY] Refactor tests using a YouCompleteMe instance
This PR adds a decorator function, similar to the `IsolatedYcmd` and `SharedYcmd` decorators from ycmd, that passes a YouCompleteMe object to tests. Its options can be customized with the parameter of the decorator. I need this to write new tests.
There is one thing annoying with this change is that Vim does not highlight a decorator function with no character between the parentheses so `@YouCompleteMeInstance()` will not be highlighted. I've contacted the maintainer of the Python syntax file about this bug. Anyway, that's not a good reason to not make this change.
<!-- 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/2386)
<!-- Reviewable:end -->
[READY] Add coverage support
There should not have anything to configure on codecov website.
I updated the `run_tests` script to behave exactly like the one in ycmd repository: when passing tests as arguments, you need to specify the path from the root project, not the `python` folder. For instance:
```
./run_tests.py --skip-build -- python/ycm/tests/event_notification_test.py
```
instead of
```
./run_tests.py --skip-build -- ycm/tests/event_notification_test.py
```
This way, you can now complete the path to the test.
<!-- 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/2385)
<!-- Reviewable:end -->
[READY] Use deleted buffer instead of current buffer when sending BufferUnload event notification
When deleting a buffer, we use the current buffer to send the `BufferUnload` event notification request to ycmd instead of the buffer being deleted. This is an issue when the current buffer is not of the same filetype as the deleted one. In this case, three different scenarios may occur:
- the current buffer filetype is not allowed: no request is sent to the ycmd server. The `OnBufferUnload` method from the completer corresponding to the filetype of the deleted buffer is not called. If the filetype is a C-family language, the translation unit is not destroyed. If it is TypeScript, we don't tell TSServer to close the file (not really an issue unless the file is modified elsewhere);
- the current buffer filetype has no semantic support in ycmd: the request is sent to the ycmd server but no semantic completer is used. Same result;
- the current buffer filetype has semantic support in ycmd: the `OnBufferUnload` method from the wrong completer is called in ycmd. LibClang and TSServer are able to cope with that and ignore the file. Same result in definitive.
The solution is obvious: build the request for the deleted buffer in this case. However, this involves more changes than expected because the code was written with the assumption that requests are always for the current buffer.
The `include_buffer_data` parameter from `BuildRequestData` was removed as it is always used with its default value.
This fix may alleviate issue https://github.com/Valloric/YouCompleteMe/issues/2232 in the sense that it now gives a reliable way to limit memory usage by deleting buffers in the case of multiple TUs.
Next step is to update PR https://github.com/Valloric/ycmd/pull/542 by removing the `unloaded_buffer` parameter from ycmd API then remove it from the `BufferUnload` request in YCM.
<!-- 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/2367)
<!-- Reviewable:end -->
Send the request as the unloaded buffer instead of the current buffer
for the BufferUnload event notification. This fixes the issue where
the filetype of the current buffer is not the same as the unloaded
buffer one, making the ycmd server uses the wrong completer when
handling the request.
Use JoinLinesAsUnicode in GetUnsavedAndCurrentBufferData().
# 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.
Rationale: Tests are in https://github.com/Valloric/ycmd/pull/617. This does not change any behavior in YCM itself, only makes things go faster.
- [ 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
GetUnsavedAndCurrentBufferData() is invoked on every kepress. On a large file (15+k loc), using this new function takes kepress latency down to <10ms from ~100ms.
The function used here is added to ycmd in https://github.com/Valloric/ycmd/pull/617. I will update this PR to include a ycmd submodule update if and when that PR is merged.
<!-- 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/2370)
<!-- Reviewable:end -->
[READY] Update ycmd. Update docs for GetTypeImprecise and GetDocImprecise
# 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
Updates ycmd submodule to latest (see below), and updates the subcommand documentation to cover `GetDocImprecise` and the new `GetTypeImprecise`.
Other user-visible changes being included (Release notes):
- PR 590: Enable KeepGoing option when creating translation units in Clang completer
- PR 595: Fix default include paths for macOS Sierra
- PR 596: Fix javascript subcommand errors for relative paths.
- Fix for #607
- PR 609: Support GetTypeQuick completer subcommand in clang completer
- PR 615: Rename GetDocQuick subcommand to GetDocImprecise
Text in the subcommand documentation is deliberately almost identical to `GoToImprecise`
[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/2359)
<!-- Reviewable:end -->
[READY] Bumps required Vim to 7.4.143 and adopts TextChangedI.
Long and personal experience, when TextChangedI gets used, YCM seems
to perform better, diagnostics will trigger much less frequently at
inappropriate occasions, even less with whitespace agnostic triggers,
if I recall correctly...
There's a previous discussion at #1337. At the time this change was bundled in
a single pull request with other changes.
It has gone through the test of the time, sole issue I've stumbled upon was reported
by @puremourning at https://github.com/oblitum/YouCompleteMe/issues/10. This
is what me and other users of my fork use daily.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1901)
<!-- Reviewable:end -->
[READY] Mention all natively supported languages in documentation
We mention all supported languages except C-family languages and JavaScript in the `Semantic Completion for Other Languages` section of the documentation. Add them.
<!-- 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/2344)
<!-- Reviewable:end -->
Long and personal experience, when TextChangedI gets used, YCM seems
to perform better, diagnostics will trigger much less frequently at
inappropriate occasions, even less with whitespace agnostic triggers,
if I recall correctly...
[READY] Handle keyboard interruption when evaluating Vim expression with user input
When evaluating a Vim expression in Python that involves code expecting user input (e.g. `input()`, `inputlist()`, `complete_check()`, etc.), if this evaluation is interrupted by the user (with `CTRL-C` for instance), Vim will pass the interruption to the Python interpreter which in turn will raise a `KeyboardInterrupt` exception. We don't want these exceptions to be displayed to the user (because the way Vim handles Python exceptions is really annoying) so we catch them where appropriate.
Fixes#2289.
<!-- 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/2329)
<!-- Reviewable:end -->
[READY] Do not depend on UltiSnips internals to fetch snippets
Use the `UltiSnips#SnippetsInCurrentScope` public function instead of the `UltiSnips_Manager` internal object to fetch snippets. Fixes#2320.
Give a workaround in the FAQ for snippets not suggested as candidates if added with the `:UltiSnipsAddFiletypes` command.
<!-- 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/2321)
<!-- Reviewable:end -->
[READY] Do not send BufferVisit and FileReadyToParse notification events when current allowed buffer has not changed
See discussion in PR #2265 and the commit message.
Since only the `BufEnter` autocommand event is concerned, we are splitting `s:OnBufferVisit` in two functions:
- `s:OnBufferRead`, identical to current `s:OnBufferVisit`, for the `BufRead` and `FileType` autocommand events;
- `s:OnBufferEnter` for the `BufEnter` event.
We only send the `BufferVisit` and `FileReadyToParse` event notifications to `ycmd` in `s:OnBufferEnter` when the entered buffer, in which we are allowed to complete, is different from the last one.
Closes#2265.
<!-- 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/2312)
<!-- Reviewable:end -->
