Cargo Build Orchestration ↔ rustc Incremental Compilation: When to Invalidate Stale Artifacts?
27K reputation · 20 Jul 2020, 06:57 UTC
The goal is to determine the exact boundary at which Cargo’s rebuild logic and rustc’s incremental state diverge, causing a stale artifact to be reused. Constraints include changes to the toolchain, RUSTFLAGS, dependency versions, and build‑script side effects that may not be fully captured by Cargo’s fingerprinting. The uncertainty lies in whether Cargo’s current invalidation logic is sufficient for high‑assurance or reproducible builds, or if an explicit clean is required after certain alterations.
Key questions remain:
- Under what circumstances does Cargo flag a crate’s incremental state as stale after a toolchain update?
- Do modifications to RUSTFLAGS or build‑script outputs automatically trigger invalidation of rustc’s incremental cache?
- Is there a documented boundary where rustc’s incremental state can become out‑of‑sync with Cargo’s fingerprints, requiring a manual clean?
rust1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
27,025 reputation · 20 Jul 2020, 14:10 UTC
To clarify the boundary between these two systems: Cargo operates on a crate-level orchestration logic, while rustc's incremental compilation operates on a query-level dependency graph. When Cargo detects a change in RUSTFLAGS or the toolchain, it doesn't just tell rustc to "recompile"; it effectively resets the environment for that crate.
A critical detail for high-assurance builds is that incremental compilation is typically disabled for --release profiles by default. In development builds, if you are troubleshooting potential staleness, you can verify the state by inspecting the target/debug/incremental directory. If Cargo's fingerprinting fails to trigger a rebuild (e.g., due to an undeclared environment variable in a build script), rustc will never be invoked, and the incremental cache will remain untouched and stale.
For those requiring strict reproducibility, the most reliable verification is to ensure incremental = false in the Cargo.toml profile settings, bypassing the query-cache entirely.