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.

[alibektas]

I would recommend using rust-analyzer.linkedProjects

[afroozeh]

Recently, I'm also observing issues with rust-analyzer.check.workspace" : false. It just checks the current crate and all the dependent crates on it. In very deep crates, it takes quite some time to check things on each save. Before, it was just changing the current crate. Has something changed recently in the behavior of this setting?

[alibektas]

@afroozeh Yes, we did it exactly like you describe. See #17912

In very deep crates, it takes quite some time to check things on each save

If this wasn't the case before, then it indicates that we did something wrong.

[afroozeh]

@alibektas I can confirm that it was not the case before, editing/save in that deep crate was immediate when rust-analyzer.check.workspace was false. Now, it seems like true or false value is meaningless because you're just checking all the dependent crates. And it has really degraded my developer experience using RustRover RustAnalyzer: each save takes about 5-10 seconds... Before I was invoking cargo check for the whole workspace on demand. I think, it would be good to have the option with these values instead of just true and false: "all", "dependent_crates", "current_crate"

Update: RustRover was a typo here, I meant RustAnalyzer.

[alibektas]

You may want to make sure that you have your rust-analyzer up-to-date. There was previously an issue with which crates we ran our flycheck on but #18197 hopefully resolved. If your rust-analyzer is indeed a more recent version, I will check if there are other cases where this issue persists but I highly doubt that.

[afroozeh]

@alibektas my RustAnalyzer is up to date. if you're now running cargo check on the current crate and all dependent crates, it's going to be slow for live editing for very deep crates in the dependency graph. I want an option that runs cargo check just for a single crate, i.e., cargo check -p <current_crate>. Again to double check, Is this the case when rust-analyzer.check.workspace is false? Or false means check the current crate and all dependent crates?

[alibektas]

@alibektas my RustAnalyzer is up to date. if you're now running cargo check on the current crate and all dependent crates, it's going to be slow for live editing for very deep crates in the dependency graph. I want an option that runs cargo check just for a single crate, i.e., cargo check -p <current_crate>.

Let me get back to you with this in a few days. I am rewriting most of the cargo check logic.

Again to double check, Is this the case when rust-analyzer.check.workspace is false? Or false means check the current crate and all dependent crates?

true : Add --workspace to cargo check
false : Add -p <package_name>

And pardon my ignorance but I thought that RustRover uses IntellijRust or is it now possible to use both of them?

[davidbarsky]

And pardon my ignorance but I thought that RustRover uses IntellijRust or is it now possible to use both of them?

Not without some active work: while it is possible to configure a classic, non-Fleet JetBrains IDE to use an arbitrary LSP server, I'm not sure why folks would want to point RustRover at rust-analyzer.

[afroozeh]

I'm sorry, I meant RustAnalyzer, there is no RustRover, it was a typo 😅 (I updated the comment to avoid confusing for other readers)

[afroozeh]

Let me get back to you with this in a few days. I am rewriting most of the cargo check logic.

alibektas Thank you. Please also make the semantic of the config also clear. As I said, it seems like when the flag is false, it checks the current crate and all dependent ones.

[afroozeh]

@alibektas is there any update on this issue?