Rename CheckPythonVersion to IsPythonVersionCorrect.
In embedders, sys.executable may contain a Vim path instead of a Python
one. To avoid starting a Vim instance in this case, we check that given
path ends with a Python 2.6 or 2.7 name using a regex.
Add tests for this regex.
If the check for available completers isn't run because the server isn't
alive, or the check request erred or times out, don't cache the result. Only
cache valid returns.
[READY] Update CMake generators for MSVC in README
Following PR Valloric/ycmd#285, older versions of CMake (< 3.0) don't support the MSVC generator names with the year component but newer versions accept both formats. So, replace the generator names in README.md by the old ones.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1893)
<!-- Reviewable:end -->
[READY] Update notifications when ycmd server crashed
Instead of printing the last 30 lines of the `stderr` logfile if the server crashed, we tell the user to run the `:YcmToggleLogs stderr` command to check the logs.
Remove `SERVER_CRASH_MESSAGE_SAME_STDERR` message because we are always using the `stderr` logfile since PR #1753. Also, console ouput cannot be used to see the logs.
Simplify `_NotifyUserIfServerCrashed` method by using `CheckFilename` function from `vimsupport` module.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1875)
<!-- Reviewable:end -->
This covers users that have already installed YCM before and are looking
to set up Rust completion. They're unlikely to start reading from the
Installation section, so we mention the need for the new build flag to
prevent "why doesn't it work for me" confusion.
Add support for the Rust programming language
Support for the Rust programming language is added using ycmd's racerd completer. This PR contains documentation for using the Rust completer and an update to the ycmd submodule.
## TODO
- [x] Update ycmd submodule once Valloric/ycmd#268 lands
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1888)
<!-- Reviewable:end -->
[READY] Fix GoTo lists arriving at the wrong column.
## Problem
When a `GoTo` command returns a list of destinations, such as declarations and definitions in Python and references in JavaScript, we pop the Vim quick fix list with a list of destinations. however, we always jump to the character before the actual declaration/definition.
## Resolution
Vim's QuickFix lists require 1-based columns, which is what is returned from ycmd's commands, so don't subtract 1 from the column number.
As noted in the comments, the Vim documentation for `setqflist` is somewhat vague about this "byte offset", but it is confirmed to mean "1-based column number" both in testing and in `:help getqflist`.
## Manual testing
Tested this with the Tern completer (`:YcmCompleter GoToReferences`) and Jedi completer (`:YcmCompleter GoToDeclaration`). For the Jedi completer, use something like:
```python
x = 1
if False:
x = 2
else:
x = 3
print( str(x) )
```
Then `:YcmCompleter GoToDeclaration` on `x`. This returns a list, which pops up the quick fix window.
*Previous behaviour*
Previously, the jump would go to the character before the actual declaration (i.e. the `<space>` before `x` in each line)
## Automated testing
Just some simple execution of the changed code, proving that we don't take 1 from the column.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1876)
<!-- Reviewable:end -->
Vim's QuickFix lists require 1-based columns, which is what is returned
from ycmd's commands.
As noted in the comments, the Vim documentation for setqflist is
somewhat vague about this "byte offset", but it is confirmed to mean
"1-based column number" both in testing and in :help getqflist.
[READY] Fix traceback when v:completed_item is empty
### Problem
A traceback is raised in Vim when completing in a C♯ file while the ycmd server crashed:
```
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
Traceback (most recent call last):
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
File "<string>", line 1, in <module>
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
File "C:\\Users\\micbou\\.vim\\bundle\\YouCompleteMe\\autoload\../python\ycm\youcompleteme.py", line 305, in OnCompleteDone
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
action(self)
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
File "C:\\Users\\micbou\\.vim\\bundle\\YouCompleteMe\\autoload\../python\ycm\youcompleteme.py", line 102, in <lambda>
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
'cs': lambda( self ): self._OnCompleteDone_Csharp()
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
File "C:\\Users\\micbou\\.vim\\bundle\\YouCompleteMe\\autoload\../python\ycm\youcompleteme.py", line 428, in _OnCompleteDone_Csharp
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
File "C:\\Users\\micbou\\.vim\\bundle\\YouCompleteMe\\autoload\../python\ycm\youcompleteme.py", line 327, in GetCompletionsUserMayHaveCompleted
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
if self._HasCompletionsThatCouldBeCompletedWithMoreText( completions ):
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
File "C:\\Users\\micbou\\.vim\\bundle\\YouCompleteMe\\autoload\../python\ycm\youcompleteme.py", line 393, in _HasCompletionsThatCouldBeCompletedWithMoreText
_NewerVim
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
if not completed_item:
Error detected while processing function <SNR>27_OnCompleteDone:
line 1:
KeyError: 'word'
```
It happens because the Vim variable `v:completed_item` is empty. From Vim documentation on `v:completed_item`:
> Dictionary containing the complete-items for the most recently completed word after CompleteDone. **The Dictionary is empty if the completion failed**.
### Solution
Check if `v:completed_item` is empty before accessing its `word` key.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1860)
<!-- Reviewable:end -->
Use check_call to capture error from build process
Without this install.py always exits 0 and no way to tell vim-plug its installation actually failed.
Before:
```
$ ./install.py
...
-- Configuring incomplete, errors occurred!
See also "/tmp/ycm_build.Vu_ej5/CMakeFiles/CMakeOutput.log".
See also "/tmp/ycm_build.Vu_ej5/CMakeFiles/CMakeError.log".
Traceback (most recent call last):
File "/root/.vim/plugged/YouCompleteMe/third_party/ycmd/build.py", line 312, in <module>
Main()
File "/root/.vim/plugged/YouCompleteMe/third_party/ycmd/build.py", line 303, in Main
BuildYcmdLibs( args )
File "/root/.vim/plugged/YouCompleteMe/third_party/ycmd/build.py", line 248, in BuildYcmdLibs
subprocess.check_call( [ 'cmake' ] + full_cmake_args )
File "/usr/lib64/python2.6/subprocess.py", line 505, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '-G', 'Unix Makefiles', '/root/.vim/plugged/YouCompleteMe/third_party/ycmd/cpp']' returned non-zero exit status 1
$ echo $?
0
```
After:
```
$ ./install.py
...
-- Configuring incomplete, errors occurred!
See also "/tmp/ycm_build.p6F7yK/CMakeFiles/CMakeOutput.log".
See also "/tmp/ycm_build.p6F7yK/CMakeFiles/CMakeError.log".
Traceback (most recent call last):
File "/root/.vim/plugged/YouCompleteMe/third_party/ycmd/build.py", line 312, in <module>
Main()
File "/root/.vim/plugged/YouCompleteMe/third_party/ycmd/build.py", line 303, in Main
BuildYcmdLibs( args )
File "/root/.vim/plugged/YouCompleteMe/third_party/ycmd/build.py", line 248, in BuildYcmdLibs
subprocess.check_call( [ 'cmake' ] + full_cmake_args )
File "/usr/lib64/python2.6/subprocess.py", line 505, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '-G', 'Unix Makefiles', '/root/.vim/plugged/YouCompleteMe/third_party/ycmd/cpp']' returned non-zero exit status 1
Traceback (most recent call last):
File "./install.py", line 32, in <module>
Main()
File "./install.py", line 21, in Main
subprocess.check_call( [ python_binary, build_file ] + sys.argv[1:] )
File "/usr/lib64/python2.6/subprocess.py", line 505, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python', '/root/.vim/plugged/YouCompleteMe/third_party/ycmd/build.py']' returned non-zero exit status 1
$ echo $?
1
```
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1855)
<!-- Reviewable:end -->
[READY] Add JavaScript completion using Tern completer
## JavaScript completer
Adds support for native JavaScript completion using ycmd's Tern completer.
WIP because relies on #1848 to be merged first.
This PR:
- Adds functional documentation to the README.md
- Adds configuration documentation to the README.md
- Updates the vim doc inline with the above
- And, most importantly, updates `ycmd` submodule to include the Tern completer and the additional fixes.
## ycmd changes
There are quite a lot of commits going in to ycmd. Here's a summary of the PRs:
```
8ec8386 Auto merge of #283 - micbou:appveyor-python-issue, r=puremourning
d079a92 Auto merge of #280 - puremourning:tern-global-config, r=Valloric
dee9afe Auto merge of #281 - puremourning:tern-timeout-exit, r=Valloric
24f5d51 Auto merge of #279 - micbou:coverage, r=Valloric
115a51d Auto merge of #275 - d0k:reparse, r=Valloric
68edd9d Auto merge of #270 - micbou:refactor-tests, r=Valloric
1caabf5 Auto merge of #272 - puremourning:tern-completer-locking, r=Valloric
5c3823d Auto merge of #274 - micbou:coverage-exclude, r=vheon
22bacb3 Auto merge of #271 - puremourning:tests-coverage-doc, r=Valloric
```
Full list can be obtained via the following command in `third-party/ycmd`: `git log --oneline 22c8670c93b4ae9930c9cdf31ad9995c7fd057bd..8ec83866948b24591f62525f027b7aa4aac3e1ad`
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1849)
<!-- Reviewable:end -->
[READY] Raise warnings on FileReadyToParse for completers not supporting diagnostics
Fixes#1829
## Background
Detailed analysis is available on [the issue](https://github.com/Valloric/YouCompleteMe/issues/1829). But principally: if the filetype being edited is not a filetype suporting YCM native diagnostics, then warnings, errors, etc. (including the "unknown extra conf" warning/prompt) are not displayed after the "FileReadyToParse" `event_notification`
## Resolution
The approach is: for filetypes which do not support diagnostics, rather than ignoring all `FileReadyToParse` event responses, simply call the `Response` method, which raises the appropriate error or handles the "confirm extra-conf" behaviour. Any other data returned by the completer (such as diagnostics!), are simply ignored.
## Manual Testing
Tested with tern completer which raises an error if the `.tern-project` file is not found.
Tested with a modified tern completer with the following `OnFileReadyToParse`:
```python
def OnFileReadyToParse( self, request_data ):
self._WarnIfMissingTernProject()
module = extra_conf_store.ModuleForSourceFile( request_data[ 'filepath' ] )
if not module:
if not self._raised_extra_conf_warning:
self._raised_extra_conf_warning = True
raise NoExtraConfDetected
return
# use module!
```
Results all as expected:
- with no `.tern-config`: tern config warning (once)
- with `.tern-config`, but no `.ycm_extra_conf`: no extra conf warning (once)
- with `.tern-config` and `.ycm_extra_conf`: confirmation prompt (once)
## Automated Testing
This was a marathon. Or a mockathon, I suppose.
Briefly:
- I wrote a `event_notification_test.py` which tests these new `YouCompleteMe` object behaviours, via a complex series of mocking
- I had to refactor the `postcomplete_tests.py` to prevent it from leaving `MagicMock` instances all over the place because this lead to the above test failing (apparently) randomly
- In order to debug the above shenanigans I updated `run_tests.py` to allow passing arguments to nosetests, like we do in `ycmd`
There are more comments in the code and on the various commit messages, explaining what's going on.
With regard to style, there is quite a lot of:
```python
@contextlib.contextmanager
def something():
with patch(this):
with patch(that):
with patch(the_other):
yield
@patch( foo )
def do_a_test( foo ):
with something():
do_a_thing()
assert foo.called()
```
The reason for this relative ugliness is that there is a lot of boilerplate mocking code. Because of a number of foibles of `mock` and the versions of python we support, I found this to be the least hacky way of ensuring that everything was cleaned up and was relatively sane to read and maintain.
Explanation for the `with`-ception that is going on:
- @patch is my preferred method, but it is more difficult to comment well and doesn't work when used with `@contextlib.contextmanager`, so you have to use `with`
- multiple managers in a single `with` statement is not supported in Python 2.6
- `contextlib.nested` is deprecated and buggy (apparently)
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/valloric/youcompleteme/1848)
<!-- Reviewable:end -->
- Fix some subordinate clause gymnastics
- Signpost the tern configuration advice better
- Signpost the link to the Tern docs better
- Sort out some bullet-list issues
Like we do in ycmd, allow additional arguments of run_tests to be passed
directly to nosetests.
In order to maintain the existing behaviour, and not require fiddly command
lines, always run nosetests in the python directory (using the -w - working
directory) switch.
Previously, running postcomplete_tests.py could lead to MagicMock objects being
left around within the ycm modules. This lead to random test failures in other
modules.
Further, by using mock.patch appropriately, tests withing postcomplete_tests.py
no longer rely on mocking performed by previous tests (and can be successfully
run individually)
