RLS always starts full analysis after VS Code is restarted

[ancwrd1]

After updating to a recent nightly toolchain RLS always performs full project analysis each time the VS Code (with Rust plugin) is restarted, instead of using the cached data from target directory like in the previous builds. It causes massive CPU load even on small projects.

There is rls.toml file in the root directory with "build_lib=true" setting.

[nrc]

This is a regresssion and feels like it could be a regression in Cargo. I'll try to reproduce.

cc @alexcrichton - any obvious changes recently that might cause this?

[nrc]

full project analysis

To clarify, this means analysis of all crates or just the primary crate? The former is bad, the latter is expected.

[ancwrd1]

All crates, like doing a full rebuild.

[rookwood101]

I'm also experiencing this problem, using RLS is basically impossible on my laptop; it gets so hot.

[Xanewok]

After setting RUST_LOG to cargo::ops::cargo_rustc::fingerprint it can be observed that the rebuilding is caused by RUSTFLAGS mismatch, somehow caused by dedup_flags. Temporarily commenting that out seems to temporarily get rid of the problem. From what i understand the flags still should consistently remain the same, even after deduping, not causing a problem. Nevertheless, this needs some more investigating.

[ghost]

Is there an easy temporary fix available for this somehow? This bug is basically a show stopper and has made me stop using RLS. Even on a very fast workstation, this means it can take several minutes before RLS becomes responsive after opening the project.

[nrc]

@Xanewok interesting, that def seems like a bug in dedup_flags - it should be consistent. Maybe should use something ordered rather than a HashMap? (BTreeMap or something)

[nrc]

This is still happening for me.

[Xanewok]

@nrc May not be related, but if you're using logging in rls_vscode, remember that with every file addition/modification/deletion inside project root (e.g. rls*.log files) project fingerprint stops matching since last compilation and (only) it will be rebuilt.

[nrc]

So, on investigation it seems that multiple builds were getting kicked off and post-processing is taking too long, but that we're no longer doing a full rebuild.

[dodheim]

@nrc : FWIW, when using rustc 1.20.0-nightly (622e7e6 2017-06-21) + rls from rustup, I was definitely getting a full rebuild of all crates; or if I wasn't, coincidentally, RLS analysis was consistently within 1sec of the time taken for a full rebuild on a very large project. Using rustc 1.20.0-nightly (ab5bec2 2017-06-22) + rls from source (commit 02b01dd), analysis is back down to very quick/manageable levels.

So if there was a regression, it at least seems fixed already. :-]

[Crazy-Owl]

I still get what seems a full rebuild on latest nightly 1.20.0-nightly (6d9d82d3d 2017-07-14) after VSCode restart with RLS mode enabled. I restart the editor, hear the sound of my laptop coolers, look into htop output and see that there are a lot of rustc compiling tasks for crates that my crate dependencies depend on.

I've done a cargo build before launching the editor, and yet this does not help -- RLS seems to rebuild everything.

[nrc]

doing a cargo build won't help - the RLS keeps its builds separate from regular ones. It should only build dep crates if you've updated your compiler or changed any deps (e.g., by cargo update, which is shared between the command line and the RLS).

[Crazy-Owl]

Indeed, it was a single rebuild, I just didn't expect it to happen since I was unaware of RLS keeping its builds separate. Thanks for clarifying!

[cars10]

So is there anything we can do to fix that? Really annoying to wait 10 minutes each time i want to use rls.

[nrc]

@cars10 it is a feature and hard to fix without breaking other things. In particular, if we shared data, we'd have to do a full build each time you built in the RLS after building outside (and vice versa), so that would slow you down more.

Our angle for improving this is to make sure we don't build when we don't need to and making the indexing quicker - there is some improvement already in these areas (which will be in the next release) and some more to come.