Skip to content

experimental/runnables returns an incorrect cwd when in Cargo workspace #21825

@gessen

Description

@gessen

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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: bug

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions