Open oli-obk opened 5 years ago
Quick note that cargo-fix also uses that mechanism – acting as a custom RUSTC that collects fixes – but since it's part of cargo has different options: It supports "only act on final crate" and "always rebuild final crate", for example.
- add a flag that one can pass to any cargo subcommand which will, instead of running the compiler, just emit the commands to be invoked in the order in which they are supposed to be invoked.
I think that this is not enough for crates with multiple binaries or libraries, because they use more than one rustc
command for the final crate.
Describe the problem you are trying to solve
Currently tools like clippy, miri and rls run
cargo
via the command line and then try to reconstruct therustc
invocation for the final crate in order to run custom code just for the final crate. Clippy and miri inject a custom driver via theRUSTC
env var. During execution of the driver, the driver decides whether it is being invoked for a dependency or for the final crate and then either runsrustc
or its own code. Rls runs the full cargo command withrustc
, but keeps reinvokingrustc
on the final crate.Futhermore, running
cargo check && cargo clippy && cargo check
will rebuild all dependencies and the final crate 3 times, even though the latter two calls should just be fetching data from the incremental cache and essentially be nops.Describe the solution you'd like
I'm currently considering the following two options:
cargo check
andcargo rustc
to replace only the finalrustc
invocations with a custom driver without causing a rebuild of all dependencies when switching from regularcargo check
invocations.Notes
I'm fine with doing this experimentally by only allowing it on nightly
cargo
.