Rust analyzer continually using stale, out-of-date code after gi

[ppearson]

I've recently started having an issue with a particular Rust project of mine that I'm developing on multiple machines, that when I do a git pull (outside of VSCode, I'm doing it on the command line in a terminal), and then restart VSCode, Rust analyzer can't build the project, because it hasn't apparently noticed that the files have changed.

i.e. it will complain that a field is not public, despite the recent git pull adding the pub in front of it, and VSCode's view itself clearly showing the pub in front of the field in question it's complaining (and underlining in red!) about.

Running cargo build or cargo build --release from the command line of the project directory (outside of VSCode) works perfectly, as the code itself is fine (after the git pull), so it seems pretty clear rust-analyzer is operating on stale information somehow about the state of my source files.

This is happening on both machines (one MacOS, one Linux), and the MacOS one is definitely using the latest VSCode (Linux machine might be slightly behind), and relatively recent rust-analyzer.

I can't seem to fix this from within VSCode itself, i.e. running the Reload Workspace, Rebuild Build Dependencies and stopping and restarting the server do absolutely nothing to fix this, and neither does completely killing VSCode and making sure the language server isn't still running.

The log item doesn't show anything other than:

[Error - 18:28:56] Server process exited with code 0.

and I'm not sure if that's related or not, I can't see any other errors.

The only way I can find to clear this, is to close VSCode, and run cargo clean, and then cargo build again, and then restart VSCode, and then rust analyzer will be okay with the code again, however, as mentioned above, cargo build worked fine (correctly) without the need for the clean, so it seems like an issue with VSCode or rust-analyzer.

Even force-modifying one of the files it's incorrectly complaining about to add whitespace doesn't trigger it to fix itself, and the modified timestamps on the files look okay.

I'm not checking any VSCode stuff (even launch.json) into git, so it only has Cargo.* and my .rs files.

Is there any way to try and work out why this is happening in terms of logs, or verbose options?

I notice previous Github issues regarding this which have been closed due to I guess it being sporadic for people in the past, but it's been persistently happening to me for a while now.

[Veykril]

Does this happen for any project or only for a specific one? One thing you could try doing is deleting the vscode workspace cache.

[lnicola]

No, cargo build with the right set of features and targets will fail if you hit the issue I'm describing. We run it when opening a project, maybe some recent changes made us quit if there's a problem. I've never seen r-a do this before.

[ppearson]

Okay thanks, I'll wait until it happens again (probably in a day or two after I switch machines again), and try and force-modify the incorrectly-erroring .rs with more than just white-space changes, and see if that does anything to re-validate it...

[ppearson]

Okay, this is utterly bizare now.... I'm trying to make 'breaking' modification changes to the .rs files that Rust-analyzer is incorrectly complaining about that are more than whitespace changes, and I'm even more confused now, but it does seem like there's a lack of cache invalidation going on somewhere...

One example I tried on a file that had one incorrect error (i.e. cargo build correctly doesn't think there's an error with the .rs file) was to add an invalid extra } at the end of a struct impl definition (so a duplicate), and then I saved the file.
Rust-analyzer then noticed the extra issue post-modification with a:

unexpected closing delimiter: '}', so the new error (number 2 of 2) was now valid (invalid error 1 was unresolved import where it doesn't recognise a rename happened in the git pull), and rust-analyzer shows this new one correctly, both in the Problems tab, and in the source code view itself.

I then removed the extra } char, and saved the file, expecting the error count of that .rs file to go back to 1 again (or hopefully even 0!), and it doesn't - it still thinks that extra } is there even though it's not! It's showing a red underline for the 'new' error which shouldn't exist where whitespace is. Restarting VSCode cleared the red underline in the editor, but the Problems tab still incorrectly shows that unexpected closing delimiter: '}' line, even though that's no longer a problem in the source file (as less <filename.rs> shows in the terminal, and VSCode's own view of the file supports as well).

[ppearson]

Had it happen again on the Linux machine again as well...

Again, I've tried wiping my VSCode cache (I really don't want to do that again really, it's quite painful re-configuring it manually, I guess it's probably possible to extract the config to .json somewhere?), then restarting VSCode, and it's still doing it...

I added a new method to a struct (which the git pull brought in as well as the use of it) that r-a is complaining about incorrectly, with function or associated item not found in ..., with the function it apparently can't find underlined in red, but I can literally Ctrl-click the function it can't find that's underlined in the code view, and it correctly jumps there!

Edit: I guess that means whatever is doing the cargo check or cargo build under-the-hood for Rust-analyzer is still operating on out-of-date files?

[lnicola]

function or associated item not found in

Do you have a screenshot? Is that a rustc or r-a error?

[lnicola]

We shouldn't quit that way, but there's a Cargo issue which causes it to show random errors when building after you switch git branches during a cargo build. There only fix is to run cargo clean.

[Veykril]

One more thing you can try is changing the file watcher to server "rust-analyzer.files.watcher": "server",

[ppearson]

Hmm, I tried this on the Mac again after the issue happened again after a git pull (the git pull done with VSCode closed, I then restarted it again after the pull), and that doesn't seem to change anything, even with multiple restarts of VSCode (turning it on required a restart of the server anyway)...

I notice Rust-analyzer > Trace: Server as a preference.... would that be helpful to try and debug this? I've turned it on, but it's (understandably!) quite verbose. I can see:

[Trace - 15:50:32] Received notification 'textDocument/publishDiagnostics'.

items which include the incorrect errors. I can see a lot of other things, but nothing which obviously looks like something to do with anything which might explain what's going on...
Before that there are a lot of $/progress trace items, for things like: 'rustAnalyzer/Indexing'...