Flycheck diagnostics should be triggered by changes to the project files that were not triggered by the client

[osiewicz]

Rust Analyzer does not seem to trigger flycheck without user saving (even if the state of the files on disk did change), which leads to stale rustc diagnostics.

rust-analyzer version:

rust-analyzer version: 0.3.2896-standalone (e266f5cab8 2026-05-10) [/Users/hiro/.vscode/extensions/rust-lang.rust-analyzer-0.3.2896-darwin-arm64/server/rust-analyzer]

rustc version: rustc 1.95.0 (59807616e 2026-04-14)

editor or extension: VSC and Zed (I don't believe version is relevant here)

relevant settings: N/A

code snippet to reproduce:
Start with following code in git repo (committed):

fn food() {}
fn main() {
  food();
}

Introduce an error and save (without committing):

fn food() {}
fn main() {
  food(1);
}

Result: 2 diagnostics ✅
Now, run a git restore .:

fn food() {}
fn main() {
  food();
}

Result: 1 outstanding rustc diagnostic ❌
Expected result: No diagnostics

In this scenario, RA does not witness any didSaves after git restore which means that flycheck is never triggered. However, it could trigger it after a brief debounce or what have you.

[ChayimFriedman2]

This will never change because rustc and Cargo need to see the files on disk. You can have autosave enabled if you want. We can remove the diagnostics after the file was changed, but that severely limits their usefulness.

[osiewicz]

The repro does materialize files on disk in a way that cargo/rustc can observe; having autosave enabled would not help with that anyhow.
Stale diagnostics are not useful, they're straight up harmful.

[ChayimFriedman2]

Right, in case of git operations the files are on disk. I'm not sure the fix is worth it though.