integration with LanguageClient-neovim

[ngortheone]

Hi, based on @matklad comment #769 (comment) I tried replacing rls with rust-analyzed.

I use neovim with LanguageClient-neovim

let g:LanguageClient_serverCommands = {
   \ 'rust': ['~/.cargo/bin/ra_lsp_server'],
   \ 'python': ['~/.local/bin/pyls'],
   \ }

But it seems that almost nothing works - navigate to definition, show documentation, etc. Only some local completion. When I try jumping to definition I get autozimu/LanguageClient-neovim#808, other actions just give me [LC] Not found! error.

I hope I misconfigured something. Please help.

[archseer]

fwiw, we discussed similar issues over on reddit with other vim based clients: https://www.reddit.com/r/rust/comments/c8951c/status_of_rustanalyzer_achievements_and_open/esmkgvg/?context=3

I can get auto-completion to work, but none of the other commands.

My vim-lsp config:

   if executable('ra_lsp_server')
       au User lsp_setup call lsp#register_server({
         \ 'name': 'ra_lsp_server',
         \ 'cmd': {server_info->['ra_lsp_server']},
         \ 'root_uri':{server_info->lsp#utils#path_to_uri(lsp#utils#find_nearest_parent_file_directory(lsp#utils#get_buffer_path(), 'Cargo.toml'))},
         \ 'whitelist': ['rust'],
         \ })
   endif

[kamek-pf]

Same thing with ALE. Auto complete is pretty fast, but couldn't get jump to definition to work.
It looks like all the vim lsp implementations have the same issue, curious what's causing this.

[matklad]

I have a hypothesis what is the problem here:

There are two forms of responses to goto definition supported by lsp: Location and LocationLink.
Location is the old one and is just a pair of file name and text range. LocationLink is newer and has additional capabilities: it stores the range of the original reference (this helps the editor to highlight where the reference is) and it stores two ranges for the target: the range of the whole element and a sub range with identifier. Two ranges allow the editor to respond to goto definition by choosing the viewport then contains the whole range(with, for example, preceding doc comments), while positioning the cursor at the sub range.

Rust-analyzer only sends LocationLiks. Strictly speaking, this is a violation of the protocol: we should ask the client if it supports LocationLinks and send just Location if it doesn’t. We currently intentionally support only the most recent features of the protocol, to save engineering effort. But, given that a lot of people face this particular issue, we should fix it and send Location for vim.

That said, making all the various vim plugins support LocationLink is also a good idea: ( ;) ): scroll to see docs+body and place the cursor on the identifier is the right behavior for gotodef.

[oblitum]

Contrary to the experience in other [neo]vim clients, completion, signatureHelp, go-to-definition, symbols, all is working as expected in coc.nvim.

[matklad]

goto definition should work after #1511. Can someone check this? Alternatively, can someone provide minimal instructions for setting up vim with your favorite lsp plugin? :)

[archseer]

I'm doing a rebuild and I'll report back shortly :)

[archseer]

doesn't seem to work Oh! Nevermind. Tried it in a different project that can compile cleanly and it seems to work :)

[kamek-pf]

That fixed it for me too, thanks a lot @matklad!

[ngortheone]

It definitely made things better, but still not the same as rls.

One example:

#[derive(Copy, Clone, PartialEq)]
pub struct Something...

When I try to get documentation or navigate to PartialEq or Copy it still get no documentation and not found error on go to definition.

But if I try the same on import - it works.

use std::cmp::PartialEq;

[matklad]

When I try to get documentation or navigate to PartialEq or Copy it still get no documentation and not found error on go to definition.

We don't support goto definition in this case. The fix here is to hard-code the set of built-in derives.

[ngortheone]

@matklad thanks for clarification! Now I can try test-driving rust-analyzer.

From the PR that you mentioned I understood that LanguageClient-neovim works only with "old" style definitions. Can you elaborate on "old" vs "new" style. I will use it to open an issue in LanguageClient-neovim.

[matklad]

That's basically what #1474 (comment) says. The relevant LSP spec is here: https://microsoft.github.io/language-server-protocol/specification#textDocument_definition