Analysis never completes unless rust-client.logToFile is true

[agentsim]

Using Visual Studio Code 1.15.1 with Rust 1.19 on MacOS 10.12.6, I've noticed that rls-vscode will be stuck in "RLS analysis: working" indefinitely.

When trying to determine why, I enabled rust-client.logToFile, and now the analysis completes and I see RLS warnings as expected in my code.

[nrc]

That setting only affects the client (not the RLS) so it is very unlikely that it is making a difference. One thing is that changing a setting causes a complete rebuild (though usually Cargo is sensible enough to not do everything from scratch), so it might be that you got stuck in a loop and changing the setting bumped you out of it. I would try doing a cargo clean (or rm -rf your target directory), it might that there is stale data somewhere causing an issue.

[agentsim]

I understand that it makes no sense :)

I think I can reproduce the problem at will with the following procedure:

1. Disable logToFile
2. Quit VS Code
3. rm -rf target
4. Restart VS Code
5. Switch to a Rust code tab
6. Wait 5 mins (still in analysis)
7. Enable logToFile
8. Repeat steps 2-5
9. After about 30s analysis is done

I've done this 4 or 5 times now, each time with the same result.

[nrc]

Do you get the same thing happening with rust-client.showStdErr? It's going to be hard to debug this without logs!

[agentsim]

No, rust-client.showStdErr also resolves the problem.

I compared the output of ls -R on the target folders as generated by RLS when it works vs. when it stalls. When it works there is a single extra file present, target/rls/debug/libarbitrage.d. My project is a single binary called arbitrage, so it would appear that RLS stalled after compiling all the crates but before compiling my code.

My Cargo.toml looks like this:

[package]
name = "arbitrage"
version = "0.1.0"

[dependencies]
config="*"
error-chain="*"
futures="*"
hyper="*"
hyper-tls="*"
serde="*"
serde_derive="*"
serde_json="*"
tokio-core="*"

[starrhorne]

I've also begun having this problem. I never had it before upgrading to vscode 1.15.1. This is on Linux.

RLS only makes it past startup when "rust-client.showStdErr": true. I haven't tried rust-client.logToFile.

There's one additional wrinkle, which may or may not be related. When startup completes, it seems that my "rust.rustflags": "-Awarnings" setting is being ignored, as I see a ton of unused method warnings that I never got before. Setting "rust.show_warnings": false didn't suppress the warnings either.

[Xanewok]

@starrhorne could you please try and run the vscode with RUST_LOG env var set for the rls to trace, running this with showStdErr set to true and see if you get any Received unactionable config messages?

[starrhorne]

Yep, here it is:

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_rac
er_fallback": Bool(false), "rustflags": String("-Awarnings"), "show_warnings": Bool(false), "sysroot": Null, "target": Null, "unstable_features": Bool(false), "use_crate_blacklist": Bool(true), "wait_to_build": Number(PosInt(500)), "worksp
ace_mode": Bool(false)})}) (error: ErrorImpl { code: Message("invalid type: unit value, expected a boolean"), line: 0, column: 0 })

Here's the whole log file: rls1503446526556.log.txt

If you need access to my code, that's no problem. Just let me know.

[Xanewok]

Could you try updating rls via rustup and see if the problem persists? It looks like you have a newer extension with an older version of the RLS (which causes a config mismatch - whole config gets ignored)

…

On Wed, 23 Aug 2017 at 02:06, Starr Horne ***@***.***> wrote: Yep, here it is: 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_rac er_fallback": Bool(false), "rustflags": String("-Awarnings"), "show_warnings": Bool(false), "sysroot": Null, "target": Null, "unstable_features": Bool(false), "use_crate_blacklist": Bool(true), "wait_to_build": Number(PosInt(500)), "worksp ace_mode": Bool(false)})}) (error: ErrorImpl { code: Message("invalid type: unit value, expected a boolean"), line: 0, column: 0 }) Here's the whole log file: rls1503446526556.log.txt <https://github.com/rust-lang-nursery/rls-vscode/files/1243749/rls1503446526556.log.txt> If you need access to my code, that's no problem. Just let me know. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#125 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC8y3Tm0nerRR4E88xg0aG_9rjlwsCYHks5sa20LgaJpZM4O8EFh> .

[starrhorne]

That's odd. I had run rustup update before commenting on the ticket.

Just to be sure, I reinstalled everything from scratch - rustup, rls, vscode and the extension. I'm still seeing this same behavior in VSCode 1.14.2 and 1.15.1.

Opening a rust file shows "RLS starting up." Then changing a character causes "RLS analysis: working" to be shown and spin forever. Adding rust-client.logToFile:true avoids the infinite-spinning, but results in a Received unactionable config error in the logs.

This is in a fresh-install. There are no other extensions or unrelated config.

[Xanewok]

@starrhorne can you post the output of rustup run nightly rls --version? The functionality on the RLS was introduced on 15.08, in rust-lang/rls@77d8274.

[starrhorne]

Sure, it's rls 0.1.0-nightly (5d4bbd9 2017-08-07)

[Xanewok]

Same thing as rust-lang/rls#450. Until the new rls component is published with a new nightly toolchain, I'd say you should set "rust.build_lib" to either true or false (old RLS version expects a bool, can't handle a null) and see if that fixes the issue for now.

[starrhorne]

Success! Setting rust.build_lib: false seems to have fixed the problem.

Thank you so much for your help! I really appreciate you taking the time.

[Xanewok]

Happy to help, glad it fixed the issue for now!