rust-analyzer.check.workspace = false is ignored on server startup

[BaxHugh]

"When rust-analyzer.check.workspace" : false is set I expect that cargo check should only be run on the rust crate which I have open in vs code. However, rust-analyzer runs cargo check across all workspace members [[edit] when the server is first started. After which saving a file shows that check is only run on the crate which is opened.] This is a problem as I am working in a mono repo which has many member crates: when I'm working in one, where VS Code is only open at the member crate's manifest directory, the rust-analyzer is slow [[edit] to start] as it is unnecessarily checking all the workspace crates.

I have reproduced this problem in a simple toy workspace.

rust-analyzer version: (eg. output of "rust-analyzer: Show RA Version" command, accessible in VSCode via Ctrl/⌘+Shift+P) rust-analyzer 0.3.2112-standalone

rustc version: (eg. output of rustc -V) rustc 1.77.0 (aedd173a2 2024-03-17)

editor or extension: (eg. VSCode, Vim, Emacs, etc. For VSCode users, specify your extension version; for users of other editors, provide the distribution if applicable) VSCode version 1.93.1 38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40 x64 rust-analyzer extension: v0.3.2112

relevant settings: (eg. client settings, or environment variables like CARGO, RUSTC, RUSTUP_HOME or CARGO_HOME) in .vscode/settings.json for the workspace (user level settings.json file removed) "rust-analyzer.check.workspace": false,

code example to reproduce: To reproduce, please see the zipped demo project: ra-workspace-issue-demo.zip

This has the structure

./
├── bar
│   ├── Cargo.toml
│   └── src
│       └── lib.rs
├── Cargo.lock
├── Cargo.toml
└── foo
    ├── Cargo.toml
    └── src
        └── lib.rs

i.e. a Cargo workspace with two workspace.member crates which do not depend on each other. In both lib.rs files, I have called a non existent function such that cargo check reports an error.

If I open, say, the foo crate: code ./foo in the problems panel, I can clearly see that rust-analyzer has reported problems in the foo crate which is not open in VS Code. (similarly I can confirm by introducing a build.rs file with panics, and the rust-analyzer output shows the error when it has built the crate it should not be running check on).

Screenshot showing that problems from both the foo and bar crate are being reported, despite only foo being open

[edit] Screenshot showing that after a save, only problems from the open crate are reported

[ChayimFriedman2]

I cannot reproduce. Initially rust-analyzer indeed checks all packages, but when editing and saving it checks only one.

[BaxHugh]

Thanks for the feedback @ChayimFriedman2. When you say initially rust-analyzer checks all packages. Do you agree that, that is not the desired behaviour? check.workspace = false specifies that the --workspace flag is not passed, but instead -p=crate is. If the -p argument is passed all along, then cargo check should never be run on anything but the single crate which is opened. That is how I understand it.

[BaxHugh]

@ChayimFriedman2 I can confirm that I see the same behaviour as you. The screenshot showing both problems is after first restarting the RA server. Once I save a file, the problems listed reduce to just the crate that is open.

I'll update the original post to reflect this.

However, RA checking the whole workspace on startup is still a problem for me, as there are a lot of crates and deps in the workspace, and starting the server takes a long time, after opening the project in VSCode.