Currently, the programmer must save the file he is working on, and only then can the LSP rust-analyzer invoke cargo-check to check for errors. Ideally, rust-analyzer would be able to run cargo-check without requiring a file save, making feedback faster. This would align more closely with how other LSPs work.
Rustc doesn't support reading source files from anything other than the real filesystem. The primary thing that needs to change for rust-analyzer to support cargo check without saving is adding some way for rustc to read files that don't actually on the real filesystem such that rust-analyzer can present it's own VFS to rustc. There is no issue tracking this.
Thinking outside the box, what about abusing a FUSE file system. I assume Windows and Mac also have similar things, but I don't really know those platforms well.
Could be a way forward if it turns out this is difficult to implement.
Mounting FUSE to replace/overlay the current project directory would be hacky and disruptive. If you mount it elsewhere, you get different file paths, and this causes all sorts of subtle problems with things like .cargo/config.toml discovery and relative paths in the workspace.
Being able to run rustc on a .crate without extraction would be nice to reduce the space cargo’s long term caches take too. Unfortunately both build scripts and proc-macros currently rely on file system access to the crate’s source code. If we get the proc-macro-include RFC implemented that should replace all direct filesystem access for them (and actually, this would be a good justification for that RFC if it’s not mentioned). Build scripts are harder, a lot of them don’t need file system access because they’re just doing things like rustc version detection, but there are still a lot that do things like run cmake on embedded sources or parse the crate’s own sources that would need filesystem access.