rust-lang
Configure flycheck using workspace.discoverConfig
Recap of recent developments with non-Cargo build systems
- We have workspace.discoverConfig, which configures a command to (basically) spit out a
rust-project.jsonon stdout and treats it like you put arust-project.jsonfile on disk. - JSON projects have a nice section for runnables, but they're currently limited to
RunnableKind { Check, Run, TestOne, }. You cannot have the JSON project configure its own flychecks. Which means that configuring a non-Cargo build system is a complicated dance ofworkspace.discoverConfig+check.overrideCommand+"check.workspace": false. - The
{label}substitution (available for runnables) was not usable for the flycheck command. I think because the only users of discoverConfig have been content with$saved_fileso far. So we currently have build labels in the JSON project that can't even be used for flychecking.
What this does
This PR adds this functionality:
- Allows the discoverConfig to describe how to flycheck crates, using a new runnable kind of "flycheck".
- Allows all types of flycheck override commands to use
{label}. If you are not using discoverConfig / rust-project.json and therefore don't have build labels attached to crates, then{label}means the cargo canonical name. Previously we only supported$saved_filehere. - The flycheck begin notification now includes a pretty-print of the actual command in use (if you're not just letting RA run cargo). Super useful to know that things got configured ok, at the bottom of your VSCode window.
And fixes:
- ~~Flychecks were being run on random downstream crates instead of the crate containing the file you saved, which would randomly result in
cargo check-ing a bigger downstream dependency, leading to unnecessarily slow flychecks and wasted CPU cycles. See the comments in notification.rs. I noticed this because the buck2rust-project checkcommand does not give diagnostics for dependencies of the target you ask for.~~ This was fixed in rust-lang/rust-analyzer#18845 it seems, although it also appears to have completely disabled flycheck for rust-project.json. I certainly noticed there was no flycheck at all when I tried mainline RA on 2025-12-02. I guess if you don't add tests for behaviour, the behaviour slowly fades away!
Notes for users
For people actually using this, it works well in VSCode if you configure rust-analyzer.workspace.discoverConfig in your settings.json, as per the manual. However, because rust-analyzer.toml support is still in its infancy, to get this going in Neovim, you will need my PR to rustaceanvim to get the settings into the initialization request, and I advise having rustaceanvim autoload settings from a file called rust-analyzer.json.
Tagging: @alibektas @davidbarsky
Just to confirm my understanding: when you say:
Allows thediscoverConfigto describe how to flycheck crates, using a new runnable kind of "flycheck".
The code changes here seem to imply that it'd be relying on the runnables in a rust-project.json; not that you're adding a few field to the configuration object/value. Is that correct? Do you intend to add a new field to discoverConfig...?
Correct. However now that I think about it, the runnable templating would be a useful thing to expose to end users to override. They can then have custom test commands, debug commands, etc.
(Noting that Meta's internal test harness has different flags to the OSS one. Would we want to have another configuration layer for rust-project to pick up and change its output? I would hope not!)
Correct.
Sorry, I realized I phrased my question ambiguously: are you planning on adding another field to workspace.discoverConfig for flycheck-specific? If the answer is yes, I'd push back on that and ask for a more wholistic design of flycheck's configuration: it's pretty messy and I don't want to make it worse.
However now that I think about it, the runnable templating would be a useful thing to expose to end users to override. They can then have custom test commands, debug commands, etc.
I agree! I think it's be nice to expose that via the standard rust-analyzer configuration mechanism.
Noting that Meta's internal test harness has different flags to the OSS one.
Oi, I didn't realize that fact, but good to know. Lemme see if I can try and unify the two.
Would we want to have another configuration layer for rust-project to pick up and change its output? I would hope not!
We should probably move this discussion over to the buck2 repo, but I've wanted a rust-project.toml for ages. There a lot of stuff in rust-project that's #[cfg(fbcode)]'d that I'd want to be controlled through configuration. It also means that setting up Buck with rust-analyzer could be as simple as placing a predefined .rust-project.toml and .rust-analyzer.toml at the root of a Buck workspace. Heck, we could even make the buck2 init command do that.
:umbrella: The latest upstream changes (presumably #18123) made this pull request unmergeable. Please resolve the merge conflicts.
What is the status of this? (Looking into cleaning up our PR backlog again but I haven't been following this PR)
Well, I've been using it with my team pretty comfortably for 8 months. Will soon be upgrading a bunch of systems and will have to rebase this anyway. I will keep this PR updated when I do.
@Veykril this is rebased onto master. I actually found during rebasing that a number of the things I did have been done independently in other PRs, just slightly differently. So the diff is a little smaller.
To remind you:
- Adds a new runnable kind
"flycheck"/ RunnableKind::Flycheck. Must be distinct from check (check runnable is for human-readable output) - Substitutes
{label}or$saved_filein it - Abstracts over cargo vs projectjson flycheck sources
- Uses all this to flycheck
This lets your 3rd party build tool configure how RA will flycheck.
I also added a pretty big docs overhaul for non-cargo build systems. I recommend reviewing this commit-by-commit, as there is a bit of diff noise now due to some renames etc.