Configure flycheck using workspace.discoverConfig by cormacrelf · Pull Request #18043 · rust-lang/rust-analyzer

cormacrelf · 2024-09-04T04:03:37Z

Recap of recent developments with non-Cargo build systems

We have workspace.discoverConfig, which configures a command to (basically) spit out a rust-project.json on stdout and treats it like you put a rust-project.json file 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 of workspace.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_file so 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_file here.
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 buck2 rust-project check command does not give diagnostics for dependencies of the target you ask for. This was fixed in fix: Fix flycheck getting confused which package to check #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

davidbarsky

some assorted comments. I'll do another pass later.

davidbarsky · 2024-09-05T15:24:26Z

-                // Trigger flychecks for the only crate which the target belongs to
-                Some((_, krate)) => vec![krate],
-                None => {
+            tracing::debug!("flycheck scope: {:?}", scope);


Suggested change

tracing::debug!("flycheck scope: {:?}", scope);

tracing::debug!(?scope);

davidbarsky · 2024-09-05T15:57:23Z

+                    PackageToRestart::Package(PackageSpecifier::BuildInfo { label: _ }) => {
+                        // No way to flycheck this single package. All we have is a build label.
+                        // There's no way to really say whether this build label happens to be
+                        // a cargo canonical name, so we won't try.
+                        return None;
+                    }


not a review comment, but more resignation: it's unfortunate that it is possible to have a PackageSpecifier::BuildInfo in FlycheckConfig::CargoCommand branch.

We can rename it FlycheckConfig::Automatic. Because it is! In cargo workspaces it does cargo stuff; in json workspaces it does JSON stuff.

Renamed to Automatic, it is a bit clearer.

davidbarsky · 2024-09-05T16:01:51Z

 }

-pub(crate) const SAVED_FILE_PLACEHOLDER: &str = "$saved_file";
+/// This is stable behaviour. Don't change.


fwiw, we can remove $saved_file with a bit of notice.

actually, no, I lied we need to keep this for while. the main user of this is Fuchsia and until they're using Bazel, I don't think it's feasible to remove $saved_file.

(cc: @P1n3appl3)

thanks for the ping. We'd actually be ok with removing $saved_file if we could use {label} in the flycheck override. Today we actually do that mapping ourselves (wrapper script checks a global file list to find all labels that include the saved file and runs a check build/clippy on all those in the build system).

I'd be happy to migrate us over to label replacement when this lands.

I'm keeping it because I think it's still useful -- a build system might know that there are multiple crates that use a particular file and compile both. $saved_file is still there but prefer {saved_file} to match all other command interpolations.

davidbarsky · 2024-09-06T13:39:24Z

Just to confirm my understanding: when you say:

Allows the discoverConfig to 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...?

cormacrelf · 2024-09-06T14:01:18Z

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

davidbarsky · 2024-09-06T14:44:39Z

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.

bors · 2024-09-24T10:17:51Z

☔ The latest upstream changes (presumably #18123) made this pull request unmergeable. Please resolve the merge conflicts.

Veykril · 2025-05-05T07:35:34Z

What is the status of this? (Looking into cleaning up our PR backlog again but I haven't been following this PR)

cormacrelf · 2025-05-05T07:51:06Z

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.

cormacrelf · 2025-12-02T07:55:15Z

@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_file in 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.

Veykril · 2025-12-02T08:00:29Z

I'll try to take a look this week.

cormacrelf · 2025-12-03T08:57:39Z

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.

Veykril · 2025-12-15T07:05:41Z

Just gotta make clippy happy now and then I am fine with merging this 👍

…roject.json runnable For JSON / override users, pretty-print the custom flycheck command with fewer quote characters Better debug logging in flycheck

Because (1) it is what we use when there is no relevant config (2) we automatically use either rust-project.json's flycheck, or cargo This also puts check_command config into CargoOptions. It's a cargo option, after all.

It was pretty useless without this. Previously: Parsing target pattern `{label}` Caused by: Invalid target name `{label}`. (...) Build ID: 6dab5942-d81c-4430-83b0-5ba523999050 Network: Up: 0B Down: 0B Command: run. Time elapsed: 0.3s BUILD FAILED * The terminal process "buck2 'run', '{label}'" terminated with exit code: 3.

rust-project requires {arg} these days. No good giving people bad information even if it's not crucial to documenting this.

I am not familiar with this code at allso just doing what I can to unblock.

cormacrelf · 2026-01-07T23:36:49Z

Clippy issues were in hir-ty, done.

stale

cormacrelf · 2026-01-08T12:39:13Z

Ripper, thanks a ton mate

Wilfred · 2026-01-08T17:16:03Z

Nice work! I particularly appreciate the docs polish too :)

We should look at updating rust-project to use this new interpolation syntax too.

After rust-lang#18043 introduced per-package flycheck for JSON projects, the code assumed that `world.flycheck` indices matched `world.workspaces` indices. However, not all workspaces have flycheck enabled (e.g., JSON projects without a flycheck template configured), so the flycheck vector can be shorter than the workspaces vector. This caused an index-out-of-bounds panic when saving a file in a JSON project without flycheck configured: thread 'Worker' panicked at notification.rs: index out of bounds: the len is 0 but the index is 0 Fix by looking up the flycheck handle by its ID (which is the workspace index set during spawn) rather than using the workspace index directly as a vector index.

PR rust-lang#18043 changed flycheck to be scoped to the relevant package. This broke projects using check commands that invoke rustc directly, because diagnostic JSON from rustc doesn't contain the package ID. This was visible in the rust-analyzer logs when RA_LOG is set to `rust_analyzer::flycheck=trace`. Before: 2026-02-02T07:03:48.020184937-08:00 TRACE diagnostic received flycheck_id=0 mismatched types package_id=None scope=Workspace ... 2026-02-02T07:03:55.082046488-08:00 TRACE clearing diagnostics flycheck_id=0 scope=Workspace After: 2026-02-02T07:14:32.760707785-08:00 TRACE diagnostic received flycheck_id=0 mismatched types package_id=None scope=Package { package: BuildInfo { label: "fbcode//rust_devx/rust-guess-deps:rust-guess-deps" }, workspace_deps: Some({}) } ... 2026-02-02T07:14:48.355981415-08:00 TRACE clearing diagnostics flycheck_id=0 scope=Package { package: BuildInfo { label: "fbcode//rust_devx/rust-guess-deps:rust-guess-deps" }, workspace_deps: Some({}) } Previously r-a assumed that a diagnostic without a package ID applied to the whole workspace. We would insert the diagnostic at the workspace level, but then only clear diagnostics for the package. As a result, red squiggles would get 'stuck'. Users who had fixed compilation issues would still see the old red squiggles until they introduced a new compilation error. Instead, always apply diagnostics to the current package if flycheck is scoped to a package and the diagnostic doesn't specify a package. This makes CargoCheckEvent(None) and CargoCheckEvent(Some(_)) more consistent, as they now both match on scope.

See rust-lang#18043, and specifically commit 8d8cc93.

See rust-lang#18043, and specifically commit 8d8cc93, which this partially reverts.

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 4, 2024

cormacrelf force-pushed the feature/rust-project-discovery branch from f1dbc97 to 52354dc Compare September 4, 2024 04:08

cormacrelf mentioned this pull request Sep 4, 2024

rust-project check TARGET facebook/buck2#767

Open

cormacrelf changed the title ~~Configure flycheck using discovered using [workspace.discoverConfig]~~ Configure flycheck using workspace.discoverConfig Sep 4, 2024

cormacrelf commented Sep 4, 2024

View reviewed changes

Comment thread crates/rust-analyzer/src/handlers/notification.rs Outdated

cormacrelf force-pushed the feature/rust-project-discovery branch 2 times, most recently from 5bf5e0d to 09ef79a Compare September 5, 2024 04:53

davidbarsky previously requested changes Sep 5, 2024

View reviewed changes

cormacrelf commented Sep 6, 2024

View reviewed changes

Comment thread crates/base-db/src/input.rs Outdated

jason-test-account-1 mentioned this pull request Oct 30, 2025

rust-project check TARGET jason-test-acct-2/buck2#38

Open

cormacrelf force-pushed the feature/rust-project-discovery branch from 09ef79a to b6e93b8 Compare December 2, 2025 07:46

cormacrelf force-pushed the feature/rust-project-discovery branch 3 times, most recently from e484bfc to 978412c Compare December 3, 2025 08:44

Veykril reviewed Dec 14, 2025

View reviewed changes

Comment thread crates/rust-analyzer/src/flycheck.rs Outdated

Veykril approved these changes Dec 14, 2025

View reviewed changes

cormacrelf force-pushed the feature/rust-project-discovery branch from 978412c to 721eb04 Compare December 15, 2025 01:12

This comment has been minimized.

Sign in to view

rustbot added has-merge-commits S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 7, 2026

cormacrelf added 7 commits January 8, 2026 10:19

flycheck: notifications show full command when configured in a rust-p…

9c18569

…roject.json runnable For JSON / override users, pretty-print the custom flycheck command with fewer quote characters Better debug logging in flycheck

flycheck: Rename FlycheckConfig::CargoCommand to Automatic

d3ddae5

Because (1) it is what we use when there is no relevant config (2) we automatically use either rust-project.json's flycheck, or cargo This also puts check_command config into CargoOptions. It's a cargo option, after all.

doc: Update docs for runnables to include run/flycheck

a7eb8c0

doc: make example for workspace.discoverConfig actually work

7ee0643

rust-project requires {arg} these days. No good giving people bad information even if it's not crucial to documenting this.

doc: overhaul non-cargo build system docs

5a98555

Fix hir-ty clippy issue

96f0185

I am not familiar with this code at allso just doing what I can to unblock.

cormacrelf force-pushed the feature/rust-project-discovery branch from 3c8ba82 to 96f0185 Compare January 7, 2026 23:25

rustbot removed has-merge-commits S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 7, 2026

Veykril added this pull request to the merge queue Jan 8, 2026

Merged via the queue into rust-lang:master with commit 8d89929 Jan 8, 2026
16 checks passed

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 8, 2026

This was referenced Jan 9, 2026

Project json compatibility improvements #21423

Merged

fix: project json runnable kind bin substitution #20396

Closed

lukasoyen mentioned this pull request Jan 15, 2026

fix: lookup flycheck by ID instead of vector index #21475

Merged

Wilfred mentioned this pull request Feb 2, 2026

fix: Stale diagnostics with rust-project.json and rustc JSON #21571

Merged

Wilfred added a commit to Wilfred/rust-analyzer that referenced this pull request Feb 25, 2026

Use a more specific package identifier

304a935

See rust-lang#18043, and specifically commit 8d8cc93.

Wilfred added a commit to Wilfred/rust-analyzer that referenced this pull request Feb 26, 2026

Use a more specific package identifier

c654d25

See rust-lang#18043, and specifically commit 8d8cc93.

Wilfred added a commit to Wilfred/rust-analyzer that referenced this pull request Feb 26, 2026

Use a more specific package identifier

4198260

See rust-lang#18043, and specifically commit 8d8cc93.

Wilfred added a commit to Wilfred/rust-analyzer that referenced this pull request Mar 2, 2026

Use a more specific package identifier

d5a93f6

See rust-lang#18043, and specifically commit 8d8cc93.

Wilfred added a commit to Wilfred/rust-analyzer that referenced this pull request Mar 2, 2026

Only track package ID for Cargo-based projects

de2fb03

See rust-lang#18043, and specifically commit 8d8cc93, which this partially reverts.

	tracing::debug!("flycheck scope: {:?}", scope);
	tracing::debug!(?scope);

Conversation

cormacrelf commented Sep 4, 2024 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Recap of recent developments with non-Cargo build systems

What this does

Notes for users

Uh oh!

Uh oh!

davidbarsky left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cormacrelf Sep 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

davidbarsky commented Sep 6, 2024

Uh oh!

cormacrelf commented Sep 6, 2024

Uh oh!

davidbarsky commented Sep 6, 2024

Uh oh!

bors commented Sep 24, 2024

Uh oh!

Veykril commented May 5, 2025

Uh oh!

cormacrelf commented May 5, 2025

Uh oh!

cormacrelf commented Dec 2, 2025

Uh oh!

Veykril commented Dec 2, 2025

Uh oh!

cormacrelf commented Dec 3, 2025

Uh oh!

Uh oh!

Veykril commented Dec 15, 2025

Uh oh!

This comment has been minimized.

cormacrelf commented Jan 7, 2026

Uh oh!

Uh oh!

cormacrelf commented Jan 8, 2026

Uh oh!

Wilfred commented Jan 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

cormacrelf commented Sep 4, 2024 •

edited by rustbot

Loading

cormacrelf Sep 6, 2024 •

edited

Loading