Forum messed up my original post, hope this works OK
I recently re-installed the latest VSCode (with rust-analyzer extension)and rustup.
But the VSCode editor appears NOT to be feeding edits to the compiler like it always did in the past!
Take the default Hello World program in main.rs (I should add here that I created a legit project here with cargo new hello_world so structure 'shouldn't' be the issue).
If I add a nonsense line:
rubbish = 5;
...after the println!("Hello, world!");
line, then do cargo build, then no errors are produced!
However, if I 'Run' it or do a Debug THEN the changes are fed to the compiler and the error shows up.
If I comment out the nonsense line // rubbish = 5; The text goes green in the editor (good) but rubbish is still underlined in red and when hovered over says "cannot find value rubbish in this scope" even though it's now a comment!
Again, if I do a cargo build then the "cannot find value rubbish in this scope" is still showing.
What's going on here?
I last used this arrangement in 2023 and everything worked perfectly well. What got broken?
Do I need to use RustRover nowadays?
Maybe some setting needs altering in VSCode? Like, the settings for 'Format on Save' or 'Format on paste' etc. ?
I tried searching all day for a solution, but found nothing.
Are you saving the file after you edit it? In general, not all errors will show up until you save. (This is because rust-analyzer can't find all errors itself, it asks rustc for the final answer, and rustc only looks at saved files from disk, not the editor contents.)
rust-analyzer should automatically run cargo check and update errors when you save, as long as you haven't changed any settings about that.
Saving the file after editing it sorts things out, yes. But in the past, I NEVER had to resort to saving a source file until I'd finished messing with it. Edits always got sent to the compiler without having to manually save files all the time.
But as I said above, the behaviour is just bizarre from rust-analyzer. Commenting out a line 'should' not cause that line to be falsely 'analyzed'. It's a comment.
Sorry, by play I meant Run or F5. I don't use VSCode too often so take all my comments here with a grain of salt as I'm more familiar with neovim.
My bet is what's happening is vscode is retaining the squiggles even after you modify the file buffer (but before you save). I've noticed this in neovim as well, but though it was mainly due to having a bloated project.
If I recall correctly, rust-analyzer runs rustfmt only on file save. You might like enabling some auto save plugin in vscode to work around this.
Maybe Rust Rover does a better job at this. I'd expect any editor making use of rust-analyzer to have the same require save for formating problem.
This does not happen. The compiler cannot read your editor contents, and never has been able to; only rust-analyzer can do that. Look at the problem list in VS Code. Each error should be labeled with either “rustc” or “rust-analyzer”, like this:
The ones from rust-analyzer are expected to update as you type, but the ones from rustc will only update when you save. Which kind are the wrong errors you are seeing?
Well, I'm either completely misremembering the work flow (quite possible ;)), or something has changed in VSCode. I simply don't remember having to manually save so much to force the expected behaviour.
For example, if you make edits, you get a notification of the modified file, but you can simply close VSCode and you don't get prompted to save before exiting. When you reload VSCode, you're back where you left off.
So, maybe(?) in the past, VSCode was using that 'editor cache' to send to the compiler, when doing a 'cargo build'? But, not now?
That has never been a thing. Rustc simply doesn't have a way to compile files that are not written to the disk. While technically vscode does save files somewhere in it's config directory even when you don't explicitly save them, this is only used for preserving unsaved when you close vscode and reopen it again. Vscode also saves them with a header that rustc simply can't parse.
