RLS in VS Code robustness & performance

[repi]

We use a single large workspace and monorepo and RLS very often hangs / stops working.

Also performance with having RLS build our repo for its own target can be quite bad, esp. working on laptop. Looking forward to future more incremental background service.

Related issues:

• clippy: force full re-clippy #2604
• rls: Performance issue of rls on large code base
• rust gamedev wg: RLS for huge projects

[repi]

Another thing that is extra problematic and annoying when RLS stops working in our large workspace is that then rustfmt on save in VS Code also stops working which most of us have started to rely on quite a bit.

And this is error prone because we require all of our code to be formatted and CI verifies this, so when it stops working dramatically increases the chances of submitting non-formatted code and failing the build.

[repi]

For a longer term improvements we've started sponsoring the rust-analyzer project as Embark with 1000€/month (as a start) on OpenCollective.

This is a great blog post where they reached out to the community and asking for additional support: https://ferrous-systems.com/blog/rust-analyzer-status-opencollective/

Still hoping for shorter term RLS improvements as it generally doesn't work at all with our Rust monorepo anymore in VS Code.

[AlexEne]

I was thinking for a short-term maybe we can do a spike and debug RLS (at least to fix some crashes).

I know your code is not public, but I wonder if we could potentially reproduce these stability issues with the rust compiler codebase or maybe servo ? or another big rust project ? (not sure if any other are at this scale).

Maybe even create a test hello world that depends on a ton of other crates?

I could raise an issue for us to try/track this in the rust-gamedev wg.

[repi]

Yes that is a good idea, one probably can reproduce similar hangs / unresponsiveness with RLS in other big Rust workspaces.

[repi]

Another problem we have with RLS is that we have large C++ dependencies built in their build.rs files and these will be built in RLS for no use and causing RLS to be inactive building for 5-10 minutes on a laptop. Our physx and ash-molten are examples of such crates.

Would want in build.rs to skip these heavy builds if building for RLS, or something similar.

Found a related issue here: rust-lang/cargo#6834

[nox]

As a workaround for RLS, you can do this:

    // Stop here if caller is RLS.
    let cargo = env::var_os("CARGO").unwrap();
    let output = Command::new(cargo).arg("--version").output().unwrap();
    if output.stdout.starts_with(b"rls ") {
        return;
    }

This doesn't help for cargo check though.

[rlabrecque]

My workspace isn't even large, 3 cargo crates in the workspace, ~200 LOC each, tonic, clap, r2d2-postgres, tracing based. Compiling on a laptop, RLS needs to be restarted at least hourly.

[repi]

Closing this as rust-analyzer a few months ago got good enough for us to switch over to it at Embark! It does have some issues (that we should file and track) but will be our primary focus going forward