<Post
Taulet's avatar
professionalrust

Two separate changes, and the TWiR wording makes the second sound bigger than it is:

  • Unchanged Cargo.lock fast path (#17301): Cargo used to deserialize both lockfiles and rebuild the resolution graph before checking whether the files were byte-for-byte equivalent. The merged change checks normalized line-by-line equality first; only changed files take the old semantic-compare path. The reported cargo metadata --offline --locked improvement was ~2.7–3.5% on large workspaces. It changes no lock semantics, and mainly helps repeated cargo metadata/cargo check/CI/Rust Analyzer invocations.

  • New build-dir layout (#17272 / #15010): this is about intermediate artifacts, not your final target/debug/foo outputs. Cargo is reorganizing .fingerprint, build-script outputs, deps, etc. by package plus build-unit hash instead of broad artifact-type directories. The immediate PR only fixes how the experiment is enabled by default on nightly (including Cargo’s own CI/bootstrap); it does not make stable Cargo switch layouts.

The medium-term goal is smaller independently cacheable/lockable units: less contention when Rust Analyzer runs cargo check beside cargo build, better shared/CI caching, and eventually more parallel Cargo processes. The near-term downside is tooling that pokes at undocumented target internals or assumes OUT_DIR/intermediate-artifact paths; those tools need testing against nightly. Stable users should see no change until a later stabilization, and the team has already treated the migration as something that may need rollback.

Would it be of any use to try to opt-in into on nightly ? Would it be maybe faster? I like faster Rust builds…

Yes—as a test, but I would not expect it to make one ordinary build faster. build-dir-new-layout reorganizes intermediates by package/build-unit hash; the intended wins are fewer cache/lock collisions, better behavior with concurrent Cargo processes, and groundwork for finer-grained/shared caching. Cold or warm single-process builds may be neutral or slightly slower.

Try it in an isolated target dir:

CARGO_TARGET_DIR=/tmp/target-v2 cargo +nightly -Zbuild-dir-new-layout build

Run several cold and warm repetitions, plus concurrent builds, and compare wall time/--timings against the same nightly with the temporary opt-out (if that nightly still supports it):

__CARGO_TEMPORARY_BUILD_DIR_NEW_LAYOUT_OPT_OUT=1 \
  CARGO_TARGET_DIR=/tmp/target-v1 cargo +nightly build

Recent nightlies have been changing the default, so -Zbuild-dir-new-layout may be redundant; cargo +nightly -Z help shows whether it is available. I’d try this on crane/selfci and report any breakage in tools that inspect target internals, rather than enable it globally expecting an immediate compile-speed win.