"RLS analysis: working ◐" never stops

[azerupi]

I have been trying to get the RLS working on mdBook for some time now. It just never gets past "RLS analysis: working ◐".

I tried running vscode with the following command, as suggested:

RUST_LOG=rls_analysis=info code

But it never outputs anything. I also tried with and without setting "rust.build_lib": true because I have a project containing both. But unfortunately that didn't work. I can reproduce this on both my mac and my linux pc.

The thing is, though, that the vscode-rust extension with RLS enabled can cope with my project without any trouble. Giving me auto-completion, linting as I type, etc. So to me, it seems like the RLS can work with the project, but somehow the official Rust extension does something different that makes it fail or hang.

Can I do something else to try and debug this? Does anyone have a clue as to why this could happen?

[Xanewok]

@azerupi can you try setting "rust-client.showStdErr": true together with setting RUST_LOG as you did? Then the output should be under Output > Rust Language Server, maybe that will contain some useful information?

[azerupi]

Huh, I am not sure why. But adding that in the settings and relaunching vscode made the problem vanish. I doubt it is a direct cause of adding that setting, but I will investigate.

[azerupi]

Ok, that is really really weird. I tried relaunching vscode with and without that key in the settings and it does actually change the behaviour for me.. 😨

Without the "rust-client.showStdErr": true line, the RLS spins forever. However, with that pref enabled it finishes after a couple of seconds of analysis. I didn't expect that, and if that can be reproduced by others that could explain why so many people are having trouble with the RLS.

Edit: I can reproduce that on at least one other repository. However, I tried it on the RLS repository and it did work without the key there.

[Xanewok]

I think that's a second or a third report like that, spooky stuff 👻 👻

My only idea is that the rls-vscode extension doesn't catch properly all the rustDocument/diagnosticsEnd, which makes the spinner stop. I guess it'd be a good idea to take a look at the extension itself.
Meanwhile, can you tell me if the spinner never spins forever, even once, with the "rust-client.showStdErr": true?

[azerupi]

Meanwhile, can you tell me if the spinner never spins forever, even once, with the "rust-client.showStdErr": true?

I am not going to say I am 100% positive because it has only been a couple of hours. But the behaviour has been consistent until now. I currently have the setting enabled and will keep it so for the moment, so if I spot the forever spinner I will let you know 😉

[leafgarland]

I had a similar issue (I think). I saw this error message in the RLS output:

DEBUG:rls::actions: Received unactionable config: Object({"rust": Object({"analyze_package": Null, "build_bin": Null, "build_lib": Null, "build_on_save": Bool(false), "cfg_test": Bool(false), "clear_env_rust_log": Bool(true), "goto_def_racer_fallback": Bool(false), "rustflags": Null, "rustup": Object({"nightlyToolchain": String("nightly-x86_64-pc-windows-msvc"), "toolchain": String("stable-x86_64-pc-windows-msvc")}), "show_warnings": Bool(true), "sysroot": Null, "target": Null, "unstable_features": Bool(false), "use_crate_blacklist": Bool(true), "wait_to_build": Number(PosInt(500)), "workspace_mode": Bool(false)})}) (error: ErrorImpl { code: Message("invalid type: unit value, expected a boolean"), line: 0, column: 0 })

I figured that it wasn't happy with null for one of the config properties, and narrowed it down to rust.build_lib. If I set that to false, instead of the default null then things seem to be working again.

[Xanewok]

@leafgarland could you post the output of rustup run nightly rls --version? The functionality on the RLS side was introduced in 15.08, in 77d8274.

[leafgarland]

rls 0.1.0-nightly (5d4bbd9 2017-08-07). An earlier version, sorry. I did rustup update nightly and it looked like it removed and installed rls, so I assumed I was on the latest version.

[Xanewok]

No worries - from what I know RLS isn't updated, well, nightly, as it has to be manually pushed to be published as a toolchain component, so I assume the next version will be bundled with the newest nightly fairly soon.

[booyaa]

This may be a similar bug (which I suspect relates to the extension rather than rls):

I have a suspicion the perpetual RLS analysis: working is the extension waiting for input. I noticed this recently, when opening a previously a crate that I had worked on (for scale it was the "hello world" boiler plate you get when you do cargo new --bin foo. Hitting enter to create a new line trigger the client to send something to RLS and the analysis to complete.

[Binero]

For me setting rust-client.showStdErr to true seems to have also solved the issue.

@booyaa For me hitting enter did not solve the issue. It makes it go from 'starting up' to 'working'. Once it's in working, all features like squiggly lines, auto complete and formatting stop working.

[zimond]

This is still happening.

[parkovski]

From a quick look, it seems the stderr pipe is never getting cleared on the typescript end when neither of those options are set. I'm traveling today and can't set up these projects to test this, but here's a potential fix if someone wants to try it:
At https://github.com/rust-lang-nursery/rls-vscode/blob/ca8a48396fd8a8fdce51bdf04c7b62581a84111c/src/extension.ts#L132

if (!CONFIGURATION.logToFile && !CONFIGURATION.showStderrInOutputChannel) {
    childProcess.stderr.resume();
}

This isn't a full solution because if the log stream fails to open and showStderrInOutputChannel is false, the same problem should happen, so it needs to be dealt with there too.

Also see the node docs on stream - https://nodejs.org/api/stream.html#stream_class_stream_readable - the pipe has to be switched into flowing mode either by adding a data listener or calling resume, otherwise end will never be emitted.

[nrc]

Hmm, we've changed out stderr handling in VSCode quite a bit, I wonder if this is fixed?

[lnicola]

I haven't run into this in a while. There were times when the analysis didn't seem to finish, but it was just very slow, I think.

[nrc]

Cool, please let us know if the behaviour returns.

[cynecx]

I am still experiencing this.

The log file contains:

thread '<unnamed>' panicked at 'need to specify SYSROOT or RUSTC env vars, or rustc must be in PATH', src/libcore/option.rs:839:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I am on rls-preview 0.122.0-nightly (48fd42f 2017-11-01).

[nrc]

@cynecx do you use Rustup? If you try to run rustc from the command line, does it work? If you're on Linux, but running VSCode from an icon in a launcher, it is possible that the launcher is giving you a different environment compared to a terminal. You test that by running VSCode from the command line.

[cynecx]

@nrc I am on macOS and am also using rustup, rustc from the command line also works. It seems that rustc is runnable from the integrated terminal.

[nrc]

Hmm I wonder if there is a bug in the VSCode client or if there is a problem with the RLS which is just ending up at that panic? I'll open a new issue.

[hecaex]

I had the exact same issue as @cynecx !
I got rid of this bug by adding: rust.build_lib": true to my config.
Now it shows:

RLS: done

Immediatelly, whenever I open a project.
I also use macOS btw.

edit: typo

[cynecx]

I can confirm that @hecaex's fix does workaround this issue :)

[oceanusxiv]

I'm here to report that using macOS, this problem still persists, and using @hecaex does not in fact fix it for me

[nrc]

The spinner not stopping is a very generic symptom. It just means that the RLS has crashed (or otherwise got stuck) while processing your project. If you're seeing this, please could you post a link to the project which is causing it (if possible) and go though some of the steps in debugging.md to get some logging info. It is probably better to open a new issue for each case until we can diagnose exactly what is going wrong.

[oceanusxiv]

I'll clarify. I already did the steps in debugging to get some log info, and the reason I'm pitching in here is because the log info is exactly the same as above, which is

thread '<unnamed>' panicked at 'need to specify SYSROOT or RUSTC env vars, or rustc must be in PATH', src/libcore/option.rs:839:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I'm using the generic generated template project for a rust library, which can be generated by entering

cargo new communicator

on the terminal.

EDIT: I also ran vs code from the terminal, checked my rustc path, and ran rustc from within vs code and in terminal, which all seemed correct

[MaxBittker]

should be fixed if you rustup update now

[Binero]

@MaxBittker For me, that made it a lot worse. Now it gets stuck even on small "Hello world" projects. It sometimes does give feedback despite being stuck on working, but usually this takes up to half a minute, and it's very unreliable.

[Binero]

Seems like another update must've landed not too long before I posted that yesterday, as the issue of the spinner being stuck is resolved now, although the behaviour of RLS itself is still very unreliable.

[floxo115]

I had the same problem. Updated with rustup and now the spinner stopped and everything seems to work!

[sachaarbonel]

I'm having the same issue in workspace setup on this project : https://github.com/Sach97/dodge