TestExplorer and Runnables (e.g. VSCode's 'Run test' CodeLens) (sometimes?) do not share a target dir

rust-analyzer version: rust-analyzer version: 0.3.2264-standalone

rustc version: rustc 1.84.0 (9fc6b4312 2025-01-07)

editor or extension: VSCode 1.96.4 -- rust-lang.rust-analyzer 0.3.2264

relevant settings:

"rust-analyzer.cargo.targetDir": true,

  "rust-analyzer.runnables.extraEnv": {
    "CARGO_TARGET_DIR": "target/rust-analyzer"
  }

  "rust-analyzer.cargo.extraEnv": {
    "RUSTC_BOOTSTRAP": "1"
  },

repository link (if public, optional): N/A -- I can probably set up a repro relatively quickly, though.

code snippet to reproduce: N/A -- The issue is observed when executing various cargo test

tl;dr -- Executing tests from the VSCode Test Explorer respects the rust-analyzer.cargo.targetDir setting, and will build/run tests in .../target/rust-analyzer/debug/deps, but executing tests from a rust-analyzer Runnable (e.g. clicking on the Run test CodeLens, or selecting a test task from the rust-analyzer: Run command palette select list) does not respect the rust-analyzer.cargo.targetDir setting, and will build/run tests in .../target/debug/deps. This causes unnecessary rebuilds of test binaries when switching between the different test runners in VSCode.

It's not clear to me if RUSTC_BOOTSTRAP=1 is still required to consistently share builds between rust-analyzer check and test explorer invocations -- a comment in #17149 indicates that this was the case last April -- but I tend to build with that env var set for other reasons.

The workaround I found for this scenario was to set CARGO_TARGET_DIR via rust-analyzer.runnables.extraEnv. It seems like the test explorer and runnables invocations are now correctly sharing the build chache, and I've not noticed anything going wrong with the check invocations. I've only spent about 15 minutes with this configuration set, though, so there may be issues with test executions interacting negatively with checks.

I'm not entirely sure that this is actually a bug. My expectation is that all rust-analyzer output -- from checks, runnable tests, and test explorer tests -- would all be built with respect to the rust-analyzer.cargo.targetDir, but I wouldn't be surprised if doing so would cause some builds to clobber one another. My apologies for opening this as a bug if it's expected behavior.

Thanks!

Start by reproducing the differing target directories with the shown rust-analyzer settings, comparing VSCode Test Explorer with the Run test CodeLens and the rust-analyzer: Run command. Trace how each invocation handles rust-analyzer.cargo.targetDir and runnable environment settings. Done means the supported test entry points use a consistent target directory without unnecessary rebuilds.