VSCode Test Explorer regularly requires a full rebuild

[brandonson]

rust-analyzer version: rust-analyzer version: 0.3.1932-standalone (47a901b9b 2024-04-21)

rustc version: 1.77.2

editor or extension: VSCode Insiders with RA 0.3.1932

It's pretty common for running tests via the Test Explorer to require a full rebuild of all dependencies. Seems like build results are getting trampled and lost when check runs. That is, the common test - fix/save file - test - fix/save file loop seems to require a rebuild of everything at every step.

Seems to happen regardless of rust-analyzer.cargo.targetDir being set to true or not. However, "rust-analyzer.check.extraArgs": ["--target-dir", "rust-analyzer-check"] seems to mitigate it, but running cargo test from the CLI requires and forces a full rebuild.

[HKalbasi]

The json output format of cargo test is unstable, so we use RUSTC_BOOTSTRAP=1 to enable it. Some popular dependencies require a rebuild when this environment variable changes. As a workaround, you can set RUSTC_BOOTSTRAP=1 everywhere to avoid the rebuild, including the terminal you run cargo test and in rust-analyzer.cargo.extraEnv

[JohnstonJ]

As a brand-new Rust / VS Code user, I am also affected by this painful issue. My settings.json is set as follows, which assists with this problem:

{
    "rust-analyzer.cargo.extraEnv": {
        "RUSTC_BOOTSTRAP": "1",
    },
    "rust-analyzer.runnables.extraEnv": {
        "RUSTC_BOOTSTRAP": "1",
    },
    "rust-analyzer.testExplorer": true,
    "rust-analyzer.cargo.targetDir": true
}

I don't know if this is the optimal configuration, but it definitely helps. I also set the RUSTC_BOOTSTRAP environment variable when running cargo commands from the CLI.

I really don't have other interest in using nightly features, and don't want to accidentally start using them in my code, so hopefully this extension will soon be able to avoid the use of this environment variable. The status quo is not the best out-of-box experience.

[HKalbasi]

The tracking issue for stablizing it in compiler is https://github.com/rust-lang/testing-devex-team/issues/1

Note that you won't accidentally use unstable features since they are gated behind #[feature] or --Zunstable, though your dependencies can intentionally use unstable features without you being noticed.

[pcone]

+1 - this basically makes the test explorer unusable by default on medium - large projects. Until I found the RUSTC_BOOTSTRAP workaround I had to do a full rebuild every time I rebooted my machine.

[joshka]

Given that using RUSTC_BOOTSTRAP will clobber other builds that don't use it, would it make sense to automatically set a target-dir on all places where RUSTC_BOOTSTRAP is in use to avoid this instead of enabling RUSTC_BOOTSTRAP every place where it's not necessary? Or perhaps have a per build type target-dir setting rather than a single setting for all types? Either of these approaches solves the direct problem. Happy to contribute either as a PR, but need guidance about which is the more correct approach.

1. Create a config setting for target-dir that applies to all cargo commands that use RUSTC_BOOTSTRAP
2. Create a config setting for each place RUSTC_BOOTSTRAP is used (https://github.com/search?q=repo%3Arust-lang%2Frust-analyzer+RUSTC_BOOTSTRAP&type=code)
3. Default the target-dir for test explorer runs to target/test-explorer or something

Either way, there should be a default configuration that makes sense for the default case to prevent this from occurring. Users should not have to understand the underlying problem here. I'm not certain that I understand all the edge cases properly on this to work out what this should be.

Semi related issue:

• https://github.com/rust-lang/rust-analyzer/issues/18978

[rlivings39]

Hope the JSON format stabilizes. I stopped using the test explorer integration for now because of the rebuild pain. Following this issue so I can re-enable it when this is resolved.