Tracking Issue for bootstrap spurious rebuilds

This is a tracking issue for collecting spurious rebuild issues in bootstrap. Spurious rebuilds refer to rebuilds that seem unnecessary, e.g. if running ./x test run-make twice in a row without modifying any sources rebuilds cargo. Note that is this not always the case, e.g. at the time when this issue was created, mir-opt tests build a special std with mir-opt RUSTFLAGS, which will need to be rebuilt if trying to go to stage2 because a stage2 rustc will expect a stage1 "standard" std build without mir-opt RUSTFLAGS (there are other solutions to that, not in the scope of this issue).

Categories

NOTE: There is only currently one category of spurious rebuilds that I am acutely aware of, it's entirely possible to have other classes of causes for spurious rebuilds.

Differing RUSTFLAGS

While some of these issues are closed, the fixes are usually stopgap solutions.

• #131636
• #131437
• #130108
  • Remark: this is RUSTFLAGS too via cargo.configure_linker.
• #126464
• #123177

Preventing spurious rebuilds due to differing RUSTFLAGS

To solve the class of spurious rebuilds due to differing RUSTFLAGS, we will need to properly handle them. Specifically, we need to (https://github.com/rust-lang/rust/issues/131636#issuecomment-2412844566):

• Centralize RUSTFLAGS handling to forbid naive "conditional" RUSTFLAGS.
• Conditional RUSTFLAGS should be propagated to bootstrap shims using environment variable (something like IMPLICIT_RUSTFLAGS) so they can't invalidate the build cache.
• Ensure bootstrap should never set any conditional rustflag explicitly on cargo.

Discussion

https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Mechanism.20for.20better.20RUSTFLAGS.20handling

Start by reproducing the bootstrap behavior with ./x test run-make twice, then read the linked issues #131636, #131437, #130108, #126464, and #123177 and the referenced Zulip discussion. Done means conditional RUSTFLAGS are centralized, propagated to bootstrap shims without invalidating the build cache, and are not set explicitly on cargo.