Skip to content

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

Merged
Veykril merged 2 commits intorust-lang:masterfrom
Wilfred:check_type_names
Feb 7, 2026
Merged

fix: Stale diagnostics with rust-project.json and rustc JSON#21571
Veykril merged 2 commits intorust-lang:masterfrom
Wilfred:check_type_names

Conversation

@Wilfred
Copy link
Copy Markdown
Contributor

@Wilfred Wilfred commented Feb 2, 2026 •
edited
Loading

PR #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.

@Wilfred
internal: Document and rename DiagnosticsReceived variants
1cd872e
@Wilfred
fix: Stale diagnostics with rust-project.json and rustc JSON
2cefe47 
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.
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 2, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Feb 2, 2026

⚠️ Warning ⚠️

  • There are issue links (such as #123) in the commit messages of the following commits.
    Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.

@Wilfred
Copy link
Copy Markdown
Contributor Author

Wilfred commented Feb 2, 2026

I spent a while trying to find a nice way to write a unit test for this but didn't succeed. I have tested an r-a build manually for both cargo and non-cargo projects though.

Veykril
Veykril approved these changes Feb 7, 2026
View reviewed changes
Copy link
Copy Markdown
Member

@Veykril Veykril left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That explains the issue i was observing when i was checking out buck2 a couple weeks ago, nice!

Thanks!

@Veykril Veykril added this pull request to the merge queue Feb 7, 2026
Merged via the queue into rust-lang:master with commit fc55443 Feb 7, 2026
15 checks passed
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 7, 2026
@Wilfred Wilfred deleted the check_type_names branch February 7, 2026 19:06
@ShoyuVanilla ShoyuVanilla mentioned this pull request Feb 12, 2026
Merged
@Veykril
Copy link
Copy Markdown
Member

Veykril commented Feb 13, 2026

I think this regressed things, for cargo, diagnostics for crates only clear once the check is complete (if it doesn't produce diagnostics) instead of clearing when the respective crate has finished checking.

@Veykril
Copy link
Copy Markdown
Member

Veykril commented Feb 13, 2026

Yea in fact I think we cannot use the scope variable to determine how to add diagnostics (whether to associate them with a package or the workspace), that var can change depending on how one triggers flychecking which may cause stale diagnostics. I'll revert this PR for now.

@Veykril Veykril mentioned this pull request Feb 13, 2026
Merged
@Wilfred
Copy link
Copy Markdown
Contributor Author

Wilfred commented Feb 16, 2026

Argh, sorry about that, and thanks for the head up about the revert.

@Wilfred
Copy link
Copy Markdown
Contributor Author

Wilfred commented Feb 17, 2026

@Veykril I've been trying to reproduce this to write a test and fix the issue properly. I can't reproduce on any of a custom rust-project.json, a simple project built with cargo, or a project with multiple crates in a workspace built with cargo. I've also experimented with explicit check commands:

    "rust-analyzer.check.overrideCommand": [
        "cargo",
        "check",
        "--workspace",
        "--message-format=json",
        "--all-targets"
    ],

Any ideas how to repro this?

@Wilfred
Copy link
Copy Markdown
Contributor Author

Wilfred commented Feb 17, 2026

Aha, this seems to work in a cargo project:

    "rust-analyzer.check.overrideCommand": [
        "rustc",
        "--error-format=json",
        "$saved_file",
    ],

Adding an unused variable, saving, and then removing it, the lint persists.

@Wilfred Wilfred mentioned this pull request Feb 17, 2026
Merged
@Wilfred Wilfred mentioned this pull request Feb 25, 2026
Merged
Wilfred added a commit to Wilfred/rust-analyzer that referenced this pull request Mar 3, 2026
@Wilfred
fix: Stale diagnostics when a custom check command is configured
350b5c3 
We can't use the flycheck scope, because that value varies depending
on how the flycheck was triggered. See also rust-lang#21571, which was reverted
due to issues with scope.

Instead, treat empty diagnostics as a flycheck for the entire
workspace, add comments explaining the JSON diagnostic format, and add
an integration test.
@Wilfred Wilfred mentioned this pull request Mar 3, 2026
Merged
Wilfred added a commit to Wilfred/rust-analyzer that referenced this pull request Mar 3, 2026
@Wilfred
fix: Stale diagnostics when a custom check command is configured
6acb298 
We can't use the flycheck scope, because that value varies depending
on how the flycheck was triggered. See also rust-lang#21571, which was reverted
due to issues with scope.

Instead, treat empty diagnostics as a flycheck for the entire
workspace, add comments explaining the JSON diagnostic format, and add
an integration test.
Wilfred added a commit to Wilfred/rust-analyzer that referenced this pull request Mar 3, 2026
@Wilfred
fix: Stale diagnostics when a custom check command is configured
601f76c 
We can't use the flycheck scope, because that value varies depending
on how the flycheck was triggered. See also rust-lang#21571, which was reverted
due to issues with scope.

Instead, treat empty diagnostics as a flycheck for the entire
workspace, add comments explaining the JSON diagnostic format, and add
an integration test.
Wilfred added a commit to Wilfred/rust-analyzer that referenced this pull request Mar 3, 2026
@Wilfred
fix: Stale diagnostics when a custom check command is configured
9b636b4 
We can't use the flycheck scope, because that value varies depending
on how the flycheck was triggered. See also rust-lang#21571, which was reverted
due to issues with scope.

Instead, treat empty diagnostics as a flycheck for the entire
workspace, add comments explaining the JSON diagnostic format, and add
an integration test.
Wilfred added a commit to Wilfred/rust-analyzer that referenced this pull request Mar 6, 2026
@Wilfred
fix: Stale diagnostics when a custom check command is configured
c6c2135 
We can't use the flycheck scope, because that value varies depending
on how the flycheck was triggered. See also
rust-lang#21571, which was reverted due to issues with
scope.

Instead, treat empty diagnostics as a flycheck for the entire
workspace, add comments explaining the JSON diagnostic format, and add
an integration test.
lnicola pushed a commit to lnicola/rust that referenced this pull request Apr 9, 2026
@Wilfred
fix: Stale diagnostics when a custom check command is configured
f225909 
We can't use the flycheck scope, because that value varies depending
on how the flycheck was triggered. See also
rust-lang/rust-analyzer#21571, which was reverted due to issues with
scope.

Instead, treat empty diagnostics as a flycheck for the entire
workspace, add comments explaining the JSON diagnostic format, and add
an integration test.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Veykril Veykril Veykril approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@Wilfred @rustbot @Veykril