"x.py check" dirties the build cache for "x.py build"

[RalfJung]

To reproduce, run

./x.py test ui --test-args pat
./x.py check compiler/rustc
./x.py test ui --test-args pat

The last command should finish immediately and not do any work. This worked fine until a few weeks ago.

However, now, this leads to rebuilds:

$ ./x.py test ui --test-args pat --bless
Building bootstrap
    Finished dev [unoptimized] target(s) in 0.02s
Building stage0 library artifacts (x86_64-unknown-linux-gnu)
    Finished release [optimized + debuginfo] target(s) in 0.07s
Building compiler artifacts (stage0 -> stage1, x86_64-unknown-linux-gnu)
   Compiling psm v0.1.21
   Compiling rustc_llvm v0.0.0 (/home/r/src/rust/rustc/compiler/rustc_llvm)
   Compiling stacker v0.1.15
   Compiling rustc_data_structures v0.0.0 (/home/r/src/rust/rustc/compiler/rustc_data_structures)
   Compiling rustc_span v0.0.0 (/home/r/src/rust/rustc/compiler/rustc_span)
   Compiling rustc_abi v0.0.0 (/home/r/src/rust/rustc/compiler/rustc_abi)
   Compiling rustc_type_ir v0.0.0 (/home/r/src/rust/rustc/compiler/rustc_type_ir)
   Compiling rustc_feature v0.0.0 (/home/r/src/rust/rustc/compiler/rustc_feature)
   Compiling rustc_error_messages v0.0.0 (/home/r/src/rust/rustc/compiler/rustc_error_messages)
   Compiling rustc_target v0.0.0 (/home/r/src/rust/rustc/compiler/rustc_target)
   Compiling rustc_ast v0.0.0 (/home/r/src/rust/rustc/compiler/rustc_ast)
   Compiling rustc_next_trait_solver v0.0.0 (/home/r/src/rust/rustc/compiler/rustc_next_trait_solver)

I don't know what this "psm" crate it but it seems to be where the problem starts.

[Zalathar]

I tried bisecting this behaviour, and it seems to have been introduced by #120060.

[RalfJung]

Cc @saethlin

[Zalathar]

Perhaps configure_linker not being called in check builds has something to do this. If Cargo ends up seeing different environment variables, maybe it decides to invalidate its caches even though those variables (theoretically) shouldn't matter for a check build.

[onur-ozkan]

cross-ref to the reason of this issue: #120060 (comment)