Doesn't work with rls (Rust Language Server)

[vorner]

Hello

When I try to use vim-lsc with rls (rust language server), I get this error:

Error detected while processing function lsc#server#channelCallback[3]..lsc#protocol#consumeMessage[20]..lsc#dispatch#message:
line    1:
E715: Dictionary required

I think the rls is installed correctly, because it works in neovim with autozimu/LanguageClient-neovim, but I'd actually prefer to use the original vim over neovim. I don't have any other language server installed right now, so I can't check if it is broken with some other one.

How should I debug this further?

[natebosch]

Most likely RLS uses a different structure than I expected for some response. I'll see if I can get it installed and look for a repro, if I can't I'll update with some info on debugging so we can narrow it down.

[natebosch]

Ok, I tracked down the first issue - vim-lsc uses expects no space between the : and the content length value in the headers - this is clearly a bug as the protocol specifies there should be a space. This is easy to fix and I'll get an update out soon.

I see the plugin sending the initialize, the server responding to that, then the plugin sending didOpen and didChange but it doesn't ever give me any diagnostics, not sure if its something with my setup.

I think I have a second bug here where a completion request that gets back an empty list might put us in a state where we never ask for completions again. Will dig in to that.

[natebosch]

I've pushed a fix for the first issue - can you pull it down and try it out? I'll keep digging on the possible problem around completion.

[natebosch]

Fixed also the problem where it would stop requesting completions. I can now see it sending didOpen, didChange and multiple completion requests and all I ever get are empty completion suggestions. I'm assuming this is a problem with my rls setup.

If you have a correctly set up rls I'm thinking this should unblock you. Please pull down the latest and let me know how it works for you.

If you still see issues the next step is to try capture the messages being sent back and forth and see if we're missing something the server expects to get it configured properly.

I tried setting the trace option when I sent the initialization request, but if it's writing logs I don't know where they are going.
You can capture the communication manually by wrapping rls with a shell script (assuming you're on mac or linux) with something like:

#!/bin/bash
tee in.log | rls | tee out.log

Then point your vim config to run that script instead of rls directly.

[vorner]

Hello

It helped a lot. I still have some smallish issues, but it mostly works:

• Can I turn on the suggestions after :: as well as .?
• It seems rls sometimes sends multi-line definitions which look a bit un-aesthetical in the output (I'd attach a screenshot, but github doesn't seem to like that png file :-( ‒ basically, every newline is replaced by ^@).
• Sometimes I get a „Could not decode message“ error:

[lsc] Could not decode message: {"jsonrpc":"2.0","id":16,"result":[{"uri":"file:///home/vorner/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-core-0.1.7/src/reacto
r/mod.rs","range":{"start":{"line":104,"character":11},"end":{"line":104,"character":11}}}]}

I have logs for these, but it seems I'm unable to attach them currently (my internet connection is very broken at the moment and it times out or something). If they are needed, I'll send them over the weekend, when I get to a better connection.

I'm attaching at least the corresponding request:

{"id":16,"jsonrpc":"2.0","method":"textDocument/definition","params":{"textDocument":{"uri":"file:///home/vorner/prog/corona/src/lib.rs"},"position":{"character":16,"line":138}}}

I noticed this doesn't happen every time on the same place. If I first let it do some completion, then go-to-definition twice in a row and the second is into another file, this happens. If I just jum through definitions or just do completions, it works fine.

Regarding setting up rls, you probably need something like:

• rustup default nightly
• rustup component add rls
• rustup component add rust-src
• rustup component add rust-analysis
• cargo install racer
• export RUST_SRC_PATH=$HOME/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/

(I'm not sure if all this is still needed, they gradually improve the experience, but rls is still very young)

[natebosch]

Glad to hear it's working 😄

Can I turn on the suggestions after :: as well as .?

Yeah I should have done this a while ago - it doesn't currently honor the triggerCharacters suggested by the server. Filed #18 to track.

It seems rls sometimes sends multi-line definitions which look a bit un-aesthetical in the output

I'm not sure I follow. Is this during completion? A screenshot and logs would definitely help here.

Sometimes I get a „Could not decode message“ error:

Hmm, the one you pasted looks like it should have worked, except for the line break in the middle which I'm assuming is an artifact of copying it rather than being present in the original... The only reason to get that error should be if json_decode throws or if the result isn't a dict. Seeing the communication logs that end up with that message would be helpful too.

[natebosch]

Ah, I made a mistake where lots of exceptions could show up like decoding issues. Sync past 33b6259 and hopefully we can better track down where your complete or goto definition issues are coming from.

[natebosch]

Fixed the triggerCharacters as well.

Remaining issue, I think, is "It seems rls sometimes sends multi-line definitions which look a bit un-aesthetical in the output" - If you can give some more information on this I can take a look.

[vorner]

Thank you, the :: works fine now. And that decode error turned out to be „No write since last change“ error.

I still can't attach to github, so I put the screenshot elsewhere: https://vorner.cz/tmp/lsc.png. As you can notice, the definitions of the functions are really multi-line in the source file, and I guess rls really sends them so (the logs agree with the theory). It's nothing serious, I just think it would look a bit nicer to either cut-off on the first newline or turn all successive whitespace (including newlines) into single space.

The logs are https://vorner.cz/tmp/log.in (vim → rls) and https://vorner.cz/tmp/log.out (rls → vim). The completion on the screenshot is id 9.

[natebosch]

Thanks for the details - that what just what I needed.

The "No write since last change" sounds like trying to jump to a definition in another file and not having set hidden.

8278065 should fix the last remaining issue with the long lines in the completion menu - I'm truncating to the first line so you won't see anything after the first ^@

Hopefully this covers everything. If you run into further problems you can reopen this issue or file a new one.