Strict version hash is sensitive to presence of standard library source code on host

[dtolnay]

I am reporting a likely unintended side effect of #142594 that should get compiler team scrutiny.

Since Rust 1.89.0 or nightly-2025-06-23 (#142594), compiling the same source code will produce a different output artifact depending on whether or not standard library sources are present during compilation.

For example, with this src/lib.rs file:

pub fn repro() {
    unimplemented!("...")
}

$ rustup component remove rust-src --toolchain=nightly-2025-06-22
$ rustc +nightly-2025-06-22 src/lib.rs --crate-name=repro --crate-type=lib --edition=2024 --emit=metadata && rustc +nightly-2025-06-22 -Zls=root librepro.rmeta | rg '^hash'
hash f498d9b8b442661b3b48683256f3913a stable_crate_id StableCrateId(6398988076306807592)

$ rustup component add rust-src --toolchain=nightly-2025-06-22
$ rustc +nightly-2025-06-22 src/lib.rs --crate-name=repro --crate-type=lib --edition=2024 --emit=metadata && rustc +nightly-2025-06-22 -Zls=root librepro.rmeta | rg '^hash'
hash f498d9b8b442661b3b48683256f3913a stable_crate_id StableCrateId(6398988076306807592)

$ rustup component remove rust-src --toolchain=nightly-2025-06-23
$ rustc +nightly-2025-06-23 src/lib.rs --crate-name=repro --crate-type=lib --edition=2024 --emit=metadata && rustc +nightly-2025-06-23 -Zls=root librepro.rmeta | rg '^hash'
hash 1e9121fe4158816afef1f8c53f33dabd stable_crate_id StableCrateId(18041666587592679647)

$ rustup component add rust-src --toolchain=nightly-2025-06-23
$ rustc +nightly-2025-06-23 src/lib.rs --crate-name=repro --crate-type=lib --edition=2024 --emit=metadata && rustc +nightly-2025-06-23 -Zls=root librepro.rmeta | rg '^hash'
hash 3bfa9667f7c341fe78b80185c86717eb stable_crate_id StableCrateId(18041666587592679647)

[bjorn3]

To be fair, the compiled code does actually change depending on the presence of the standard library source code. If it is present, we un-remap the standard library source locations in debuginfo, #[tracked_caller] and file!().