Idea: cargo flag to make it cancellable

1

Quite often I run manually cargo run etc. only to see it wait on some existing cargo invocation, either from rust-analyzer or cargo watch, etc. Makes me wonder: could we have a flag to make cargo preemptible? E.g. before starting any new crate build it would would check if any other instance is waiting for it and quit with an appropriate error code and message to yield for a more urgent invocation? The tooling that runs cargo "in the background" could just use that flag and retry.

3 Likes
2

I have vim-ale, rust-analyzer (via vim-ale), tarpaulin, etc. each use their own target directory. In addition to avoiding lock contention, it also avoids ping-ponging the build across different configurations (e.g., nightly for clippy, but stable for building).

1 Like
3

This is an interesting idea. How would one go about that? Do cargo subcommands have a --target DIR option or something like that?

4
1 Like
5

I have the same problem. My editor runs cargo check on save, and that delays me running cargo test. It clashes frequently enough that my go-to command for running tests is

killall cargo; cargo test
1 Like
6

I believe it's 1.85 that will not thrash the cache on RUSTFLAGS. If there are other cases that do but really shouldn't, please open an issue!

I'd like to be better about locks. The ideal solution (reader/writer lock per intermediate artifact) might blow up ulimits. However, we could look into different lock setups that wouldn't run into that. For example, one idea would be to make a lock for a hash for characteristics that create a fully unique build, like rustc version. Host builds (build scripts and proc-macros) cause a lot more sharing than might be expected which would limit this.

7

I mean, it’s desired that the IDE share artifacts with the normal command-line invocations. It would just be nice™ if the command-line invocations took priority, even if the IDE operation had already begun.

6 Likes
8

If sharing of artifacts were fine grained enough priority would not be a meaningful issue; each process would be doing each unit of work or just waiting for it to be done by another process. I think this is preferable overall, but some processes declaring themselves expendable might be a reasonable short term solution.

2 Likes
9

It would be great if cargo stored several past configurations, instead of rewriting. That would've avoided that ping-ponging of cache invalidation

1 Like
10

To be fair, /target directories get bloated enough as it is, never mind if everything had multiple copies.

11

There is a lot of old stuff left around in the cargo directories as is. Having a GC command (or even automatic GC based on some condition or other) would be a good idea. You can see this by checking the size of the target dir after working on a project a few days, cleaning it out and rebuilding. It will usually be sevaral GB smaller.

But since it already leaves things around, I do wonder how much more things would have to be left around for it to be usable as @Ddystopia suggested. Perhaps it just needs some additional bookkeeping?

12

I use symlinks all over the place to place my target directories so that they can all live near each other and ncdu is able to easily find "bloated" directories and I can clear them out by hand. I use sccache to make this as painless as possible to recover from.

1 Like
13

Cargo does, for some situations.

See cargo::core::compiler::fingerprint - Rust

If its in Metadata::c_extra_filename, then it will cause a unique copy on disk.

1 Like