April 20, 2026, 8:10am 1

TL/TR
what can I do to avoid the re-builds to happen and instead have consistent, reusable build results for these: cargo test, CodeLens, TestExplorer?

Backgound
(Note: this is a more specific spin of from Why are builds of my crate's test not consistent (cargo build vs cargo test vs VSCode-Test-Explorer))
Using: rust-analyzer extension for VSCode
Name: rust-analyzer
Id: rust-lang.rust-analyzer
Description: Rust language support for Visual Studio Code
Version: 0.3.2870
Publisher: The Rust Programming Language
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=rust-lang.rust-analyzer

Reprocue:

1. cargo new ra_rebuild_test
2. cargo add proc-macros2
3. use rust-analyzer.testExplorer": true (e.g. in ./vscode/settings.json)
4. add any test into main.rs, e.g.

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        assert_eq!(2 + 2, 4);
    }
}

5. Use VSCode's TestExplorer to run it_works
6. cargo test --no-run --verbose

Expected: no rebuild necessary.
Observe: it says this and rebuilds:

 Dirty proc-macro2 v1.0.106: the env variable RUSTC_BOOTSTRAP changed
   Compiling proc-macro2 v1.0.106
[...]

This is no big deal for a simple project, however gets ugly when the project grows larger, as described in Why are builds of my crate's test not consistent (cargo build vs cargo test vs VSCode-Test-Explorer)).

Note: I don't observe this, when useing VSCode's CodeLense feature to run the individual test (which I suppose is also a feature brought in by rust-analyzer extension into VSCode)

Questions

1. why is it necessary for rust-analyzer to make use of RUSTC_BOOTSTRAP in TestExplorer, but - as it seems - not in the CodeLens feature?
2. why is this environment variable relevant for rebuilding proc-macro2 (and as it seems not for some other dependencies)?
3. what can I do to avoid the re-builds to happen and instead have consistent, reusable build results for these: cargo test, CodeLens, TestExplorer?