rust-analyzer settings should unset LD_LIBRARY_PATH

Summary

x check rebuilds rustc_llvm frequently because LD_LIBRARY_PATH is set by rustup when running rust-analyzer.

I noticed that x check was rebuilding rustc_llvm basically every time I modified a source file. I tracked this down to the following env variable change:

cargo::core::compiler::fingerprint:     dirty: EnvVarChanged { name: "REAL_LIBRARY_PATH", old_value: Some("/home/jyn/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib"), new_value: None }

The problem was that I had installed rust-analyzer from rustup, not as a standalone tool. As a result, rustup sets
LD_LIBRARY_PATH=$(rustc --print target-libdir) in the environment under the assumption that rust-analyzer needs it to link to rustc_private crates. This can in fact happen; see https://github.com/rust-lang/rustup/issues/4245#issuecomment-2712693006.

To avoid this, we should add rust-analyzer.cargo.extraEnv = { LD_LIBRARY_PATH = null } to the default settings. That unsets it only for commands spawned by rust-analyzer, while keeping direct invocations of x the same.

Command used

x check compiler

Bootstrap configuration (bootstrap.toml)

profile = "compiler"
change-id = 137170

[rust]
deny-warnings = false

Operating system

PopOS 22.04 (Ubuntu derivative)

HEAD

i'm currently on fedf10752b9. i don't remember what commit i was on when i first saw this bug; i assume it is still present.

Additional context

; rustup which rust-analyzer
/home/jyn/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rust-analyzer
; rust-analyzer --version
rust-analyzer 1.87.0-nightly (43f0014 2025-03-25)

Start with the rust-analyzer default settings and the bootstrap.toml configuration, then reproduce the behavior with x check compiler. Confirm that commands spawned by rust-analyzer no longer inherit LD_LIBRARY_PATH and that direct invocations of x remain unchanged.