rust-analyzer version: rust-analyzer 1.94.0-nightly (e29fcf4 2026-01-04)
rustc version: rustc 1.94.0-nightly (e29fcf45e 2026-01-04)
editor or extension: neovim NVIM v0.12.0-dev-1574+g8d6963a6a0
relevant settings: N/A
repository link (if public, optional): N/A
code snippet to reproduce:
In any large codebase, I often run into an issue where one part of rust-analyzer seems to become quickly aware of changes I make while other parts (such as diagnostics and inlay hints) seem to lag behind considerably.
In this example, I updated the trait implementation for Dataset such that the operation in question would return id: i32 but diagnostics continues to show an error for some time (as in minutes, until more changes are made elsewhere, even after saving all files) and inlay hints continue to show the same stale data that is causing the incorrect diagnostics errors, but using the LSP hover action I can see that rust-analyzer is aware of the changes.
In the screenshot below you can see neovim lsp client's hover window displaying the correct updated return type of i32, but diagnostics errors and type inlays are both insisting that it's still the old i16 value:
I'm not sure of the exact repro steps other than it happens fairly often and seems to persist indefinitely until sufficient changes are made to the codebase. For example, I left the editor open (after a :wa to save all changes to disk) while I composed this bug report and just checked back on it to find the stale information and incorrect diagnostics still present. Using :e to reload the buffer shows the correct information, so I am not entirely certain whether this is a neovim LSP implementation bug or a rust-analyzer bug, as I'm presuming RA is supposed to be able to update its state automatically without needing to reload the buffer for this to work.
rust-analyzer version: rust-analyzer 1.94.0-nightly (e29fcf4 2026-01-04)
rustc version: rustc 1.94.0-nightly (e29fcf45e 2026-01-04)
editor or extension: neovim NVIM v0.12.0-dev-1574+g8d6963a6a0
relevant settings: N/A
repository link (if public, optional): N/A
code snippet to reproduce:
In any large codebase, I often run into an issue where one part of rust-analyzer seems to become quickly aware of changes I make while other parts (such as diagnostics and inlay hints) seem to lag behind considerably.
In this example, I updated the trait implementation for
Datasetsuch that the operation in question would returnid: i32but diagnostics continues to show an error for some time (as in minutes, until more changes are made elsewhere, even after saving all files) and inlay hints continue to show the same stale data that is causing the incorrect diagnostics errors, but using the LSP hover action I can see that rust-analyzer is aware of the changes.In the screenshot below you can see neovim lsp client's hover window displaying the correct updated return type of
i32, but diagnostics errors and type inlays are both insisting that it's still the oldi16value:I'm not sure of the exact repro steps other than it happens fairly often and seems to persist indefinitely until sufficient changes are made to the codebase. For example, I left the editor open (after a
:wato save all changes to disk) while I composed this bug report and just checked back on it to find the stale information and incorrect diagnostics still present. Using:eto reload the buffer shows the correct information, so I am not entirely certain whether this is a neovim LSP implementation bug or a rust-analyzer bug, as I'm presuming RA is supposed to be able to update its state automatically without needing to reload the buffer for this to work.