Rust analyzer "cargo check" blocks debug builds

[cart]

I'm working on a project where iterative compile times are important. If i make a change, save it, and immediately start a debug build then it will almost always get blocked by rust analyzer's invocation of the "cargo check" command. My build then needs to wait until cargo check completes.

Blocking doesn't occur if I run a release build. This creates the weird situation where release builds are actually faster to complete:

Finished release [optimized] target(s) in 0.80s

vs

Finished dev [unoptimized + debuginfo] target(s) in 1.31s

This is especially troublesome for initial cargo check runs, which can block builds for minutes at a time.

[matklad]

The workarounds are:

• set "rust-analyzer.checkOnSave.enable": false (you should still get errors in the editor if you invoke build manually)
• set "rust-analyzer.checkOnSave.extraArgs": ["--target-dir", "/path/to/proect/target/check"]

[cart]

Brilliant. The second option is exactly what I was looking for. My first instinct was "why isn't this the default?", but then I looked at the target folder doubling in size. The current default behavior seems like the right choice for most people. Then people (like me) who are willing to trade some disk space for non-blocking behavior can do so. Ideally theres a way to avoid duplicate artifacts, have check on save enabled, and avoid blocks, but I understand that such an ask might be outside the bounds of the constraints rust-analyzer operates in. Maybe RA could detect when there is a user-initiated cargo lock contention and force-stop its internal cargo check execution?

Thanks for your help! I consider this issue solved for me.

[flodiebold]

I wonder, if you let it share the target folders, does the cargo build that runs after check has finished have to rebuild all dependencies? Otherwise you might spend some time waiting for the lock, but it's maybe just time you'd otherwise spend waiting for the dependencies to build?

[lnicola]

My impression is that cargo check is mostly but not completely a subset of cargo build. Running cargo check after cargo build will do some work, but will still take less than a clean check.

In a test with a tiny project depending on rand, cargo build took 1.2s for me, a clean cargo check took 1s and a cargo check after cargo build took 0.6s.

I think this is most annoying when you load a freshly-cloned/cleaned repository, but it's less of an issue otherwise.

[cart]

Those numbers are relatively consistent with my rust-analyzer experience as well. In my project I get ~0.8 seconds for iterative debug builds (release vs debug is nearly indistinguishable) and ~1.3 seconds for iterative debug builds waiting on a rust analyzer cargo check.

Those numbers are definitely workable, but I've worked hard to make the change/build/run/check loop as tight as possible for my project (its a real time app with "hot reloading" in various forms). Every millisecond is valuable to me.

[lnicola]

What if you set cargo build as your check command?

[cart]

Thats a really smart idea. Sadly i just tested it and for some reason thats significantly slower for iterative builds (~1.5 seconds when immediately invoked and hitting a block. ~0.8 seconds when waiting for cargo check to finish). It seems like cargo decides it needs to re-do the work for some reason. Note that i have reverted the "custom target folder" configuration option.

[lnicola]

That's without your previous watchexec setup, I assume, if you had one? If it's visibly slower when called from rust-analyzer compared to running it from the command line, it may be worth further investigation.

[cart]

Nope no watchexec setup (i didnt even know what that was until now)

To be clear, the "cargo build" initialized by RA runs at the same speed as a command line "cargo build". The approach im using is:

1. save change (RA cargo build triggers)
2. manually run "cargo run" before RA "cargo build" finishes
   • EDIT (for clarity): this immediately blocks because of the RA cargo build
3. RA "cargo build" finishes in ~0.8 seconds
4. "cargo run" finishes in ~1.5 seconds.

[cart]

I have a feeling that using something like watchexec to run the binary whenever RA's cargo build finishes would give me 0.8 second build/runs. But then im running the program every time i save a file (which isn't desirable)

[lnicola]

Yeah, I was about to suggest using cargo run instead of build/check. Note that we pass --all-features by default, that might explain why run takes longer.

[cart]

I was sure that was going to be it, but sadly passing --all-features to cargo run also didnt change the total build/run time.

[lnicola]

Different environment options might also trigger rebuilds. You could try to start Code from a terminal, then use the Code terminal to run cargo run. But it's pretty far-fetched :-).

Still, might be a fun issue to look at.

[cart]

Sadly that also had no effect for me. However that might be because my vscode is a "snap", which might change the env variables.

[matklad]

I think it's fair to close this: although the probelm is real, I don't think we'll be able to come up with anything better than the current set of work-arounds.