Add bridge between incrementals #367
Conversation
blyxyas
force-pushed
the
bridge_between_incrementals
branch
from
391b852 to
3e6af69
Compare
| Redoing work between `cargo check`, `cargo build` and other commands such as `cargo clippy` is one of the greatest pain | ||
| points in the realm of compiler performance. Being able to reuse this information would speed up by a lot both |
There was a problem hiding this comment.
For me, this comes across as a pretty strong statement and yet it doesn't match my experience or those I've talked to.
There was a problem hiding this comment.
It might come across as stronger than I expected. But I've heard multiple people complain before about having to recheck everything after a cargo check for a cargo build and similar.
| `cargo check`, `cargo build`, and any other external tool that might benefit from sharing incremental information | ||
| such as `cargo clippy`. | ||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
Unsure where this might fit but our issue for this is rust-lang/cargo#3501
There was a problem hiding this comment.
Not the same effort but I've tried this: rust-lang/cargo#15627. And @bjorn3 pointed out an issue that is needed to be address:
A check and regular build will produce a different crate hash, so if you do
cargo check; cargo build -p some_dep; cargo checkyou are now forced to rebuild everything that depends onsome_depas the crate hash ofsome_depchanged.
There was a problem hiding this comment.
In this model, cargo build -p some_dep would have the atomic bits "emit-bin", mark red all emit-exclusive queries, rerun those, and save them into the "emit-bin" atomic response (along with other emit-exclusive metadata)
Any activity looking for some_dep's "emit-bin" information would request that, but if they do not request it, they'll be met with the information produced by cargo check.
So for the second cargo check, it would be like if some_dep was never built in the first place.
@nikomatsakis Could I submit this late? I read August 18 instead of July 18 in your email. I think it's still worth but obviously no worries if it messes up the project's timeline.
This Project goal would create a bridge (i.e. compatibility layer) between all compiler-adjacent activities in order to reuse compilation cache between
cargo check,build,clippyand any other tool (So it would also be useful for tools like cargo-semver-checks, iinm). The end goal would be to unify workflows, and:Again, sorry for the late submission. I'm still very confident that it's a good goal.
Rendered