You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a workspace with ~30 crates in it; cargo check can sometimes take quite a while. So, doing an edit and then attempting to build in a shell often means the build is blocked waiting on cargo check to release the lock on the build directory.
A simple solution would be to have the check use a different build directory, so local builds and whatever the Rust plugin wants to do simply can't collide.
But you can apparently pass a path, e.g. --target-dir" "/tmp/foo
There is an open, unassigned issue to solve that here
Despite that, it looks as if it might work to simply point the analyzer at, say, /tmp/$WORKSPACE_PATH_HASH (some short name derived from the workspace path to avoid collisions) or something like that.
Or it might be possible to simply ensure that, while cargo check uses the configuration of the debug profile (or whatever) it doesn't use $TARGET/debug for whatever it wants to write.
Could be implemented as an enablable option to use a $TMP subdir and just ensure the subdir exists before calling it; or as an option to pass arguments or env vars when calling cargo check - although that might be problematic, since if someone did that, every Rust project would try to use the same directory (unless you want to implement some sort of variable dereferencing in the settings).
Anyway, it appears solvable, and would make a big difference in productivity for anyone who winds up waiting several minutes for cargo check for their build/test/whatever to run.
The text was updated successfully, but these errors were encountered:
I have a workspace with ~30 crates in it;
cargo check
can sometimes take quite a while. So, doing an edit and then attempting to build in a shell often means the build is blocked waiting oncargo check
to release the lock on the build directory.A simple solution would be to have the check use a different build directory, so local builds and whatever the Rust plugin wants to do simply can't collide.
It appears that is doable, with some caveats:
--target-dir" "/tmp/foo
Despite that, it looks as if it might work to simply point the analyzer at, say,
/tmp/$WORKSPACE_PATH_HASH
(some short name derived from the workspace path to avoid collisions) or something like that.Or it might be possible to simply ensure that, while
cargo check
uses the configuration of thedebug
profile (or whatever) it doesn't use$TARGET/debug
for whatever it wants to write.Could be implemented as an enablable option to use a
$TMP
subdir and just ensure the subdir exists before calling it; or as an option to pass arguments or env vars when callingcargo check
- although that might be problematic, since if someone did that, every Rust project would try to use the same directory (unless you want to implement some sort of variable dereferencing in the settings).Anyway, it appears solvable, and would make a big difference in productivity for anyone who winds up waiting several minutes for
cargo check
for their build/test/whatever to run.The text was updated successfully, but these errors were encountered: