<Post
dpc's avatar
professional

Cargo work includes avoiding unchanged lockfile parsing and moving the nightly build-dir layout forward.

What does it mean exactly? What are the plans? Any benefits in near to mid term I can expect?

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…