Rust analyzer "cargo check" blocks debug builds #4616
Comments
|
The workarounds are:
|
|
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. |
|
I wonder, if you let it share the target folders, does the |
|
My impression is that In a test with a tiny project depending on I think this is most annoying when you load a freshly-cloned/cleaned repository, but it's less of an issue otherwise. |
|
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. |
|
What if you set |
|
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. |
|
That's without your previous |
|
Nope no 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:
|
|
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) |
|
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. |
|
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. |
|
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. |
|
Sadly that also had no effect for me. However that might be because my vscode is a "snap", which might change the env variables. |
|
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. |
|
Another solution/workaround idea would be for |
It runs But there might still be a bug, e.g. if a no-op |
|
This is still a big problem for me as my build relies on |
|
You can set environment variables using |
|
Tried that, now it's clobbering my cache every time I try to build instead of every startup :( e: that seems to have stopped for now, might have involved the "loading metadata" step rather than the check? |
|
This is continuing to be a (very frustrating) problem. It looks like every time RA declares it's "loading metadata", it clobbers my debug compile cache. This happens at least once every time I launch vscode, and often at other times, sometimes several times in a row (maybe every time I touch a Cargo.toml? but also sometimes when I haven't...). My environment is set consistently between my terminal and |
|
What do your Knowing how to reproduce this would be helpful. cc #5828 |
|
Relevant configuration segment: |
|
Good new is I can reproduce this, bad news is I still don't see why this is happening but its certainly Note that you can set the rustflags in the |
|
So @Ralith so you have to replace the |
|
Well I suppose we could support the known set ourselves here... cc #9626 |
|
Thanks for investigating! |
|
Did anyone found out how to set with no effect. |
|
@mirgee note that we log the config we get from the editor. When using vscode, I enable logs like look for |
|
Documenting for anyone else running into this issue: I was having lots of spurious rebuilds for the openssl-sys package (and some dependees of it). It turned out to be because I was setting $PKG_CONFIG_PATH to something custom in my .bashrc. I run VSCode via the Unity launcher, not from a terminal, so it was not getting the setting from .bashrc.. But as soon as I opened a terminal, whether within VSCode or not, that terminal had a different $PKG_CONFIG_PATH and so triggered a rebuild. Removing the line in my .bashrc that sets $PKG_CONFIG_PATH fixed it. Here's a minimal project to reproduce: src/main.rs fn main() {
println!("Hello, world6!");
}src/Cargo.toml [package]
name = "rebuild-repro"
version = "0.1.0"
[dependencies]
openssl-sys = "0.9.77"~/.bashrc cargo 1.67.0-nightly (eb5d35917 2022-11-17) And here's how I debugged:
Note the mention of PKG_CONFIG_PATH. This happens because openssl-sys has a build script: build.rs. That invokes pkg-config, which emits a bunch of I noticed that the "new" version of PKG_CONFIG_PATH included some directories that were specific to my user, which led me to look for that variable in my dotfiles and find it in .bashrc. Hope this is helpful to someone in the future! Bonus helpful link: https://doc.rust-lang.org/stable/cargo/faq.html#why-is-cargo-rebuilding-my-code slow-rebuild-log-1.txt |
Otherwise if we want to build manually in a different terminal after saving, we will get an annoying conflict, where our build is blocked by the editor build until it is finished: "Blocking waiting for file lock on build directory" rust-analyzer can still autocomplete just fine if we disable checkOnSave, we will just miss out on the cargo check warnings. ref: rust-lang/rust-analyzer#4616
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:
vs
This is especially troublesome for initial cargo check runs, which can block builds for minutes at a time.
The text was updated successfully, but these errors were encountered: