-
Notifications
You must be signed in to change notification settings - Fork 2k
Description
rust-analyzer version: rust-analyzer 1 (51966da 2026-03-08)
rustc version: rustc 1.92.0 (ded5c06cf 2025-12-08)
editor or extension: Emacs with Eglot
relevant settings: N/A
repository link (if public, optional): N/A
code snippet to reproduce: N/A
When working in a Cargo workspace, experimental/runnables returns an incorrect cwd parameter for tests, testmods, doctests, and benchmarks. Because the returned cargoArgs include the --package argument, the cwd parameter should be the workspaceRoot rather than the specific package directory. For standard binaries, the cwd is handled correctly.
This is the minimal workspace layout I'm using:
├── Cargo.toml
└── member
├── Cargo.toml
├── examples
│ └── hello.rs
└── src
└── lib.rs
The member crate was created using cargo new member --lib. The only modification I made was changing the assert to trigger an error. The root Cargo.toml looks like this:
[workspace]
resolver = "3"
members = [
"member",
]Requesting experimental/runnables returns a cwd of <project_dir>/member, while workspaceRoot is set to <project_dir>. The command rust-analyzer generates is:
cargo test --package member --lib -- tests::it_works --exact --nocapture
Executing this outputs:
thread 'tests::it_works' (107291) panicked at member/src/lib.rs:12:9:
Because of the --package flag, I suspect this command is actually meant to be run from the workspace root. While it executes successfully from both the workspace root and the member directory, Emacs's error reporting breaks: the cwd is set to the member directory, but the file path in the error output is member/src/lib.rs:12:9. The exact same issue occurs with doctests and benchmarks.
However, when running a simple example:
fn main() {
panic!("");
}rust-analyzer provides the following command:
cargo run --package member --example hello
In this case, the cwd is correctly set to <project_dir>, matching the workspaceRoot. I checked the rust-analyzer source code, and it appears there is different logic for setting the cwd depending on whether the target is a standard binary or something else (link).