rust-lang
internal: start porting VFS to Salsa
This is a small PR that starts porting the VFS over to Salsa (For context, https://github.com/rust-lang/rust-analyzer/issues/18948). In this PR, I'm starting by converting FileId to a salsa::input. The harder part—which is not done in this PR—is removing the vfs field on GlobalState and refactoring the read/write lock that is currently separate from the Salsa database.
I think that if we want to simplify the VFS, it will need to take a dependency on Salsa. This means that the proc-macro-server-api will also need a Salsa dependency.
The dependency graph is proc-macro-srv-cli -> proc-macro-api -> span -> vfs. Span declares EditionedFileId, which can be constructed from a vfs::FileId.
Then we can continue as we did (do now? I don't remember), with span using a cfg and defining FileId as either a salsa::input or a wrapper around u32.
Then we can continue as we did (do now? I don't remember), with span using a cfg and defining FileId as either a salsa::input or a wrapper around u32.
Yeah, we do a #[cfg(feature = "salsa")]/#[cfg(not(feature = "salsa"))] dance with SyntaxContext in crates/span/src/hygiene.rs. I think that we should probably do something similar to vfs::FileId, but I'll hold off on implementing that until I move the vfs over use a Ruff-style Files, as that might design implications.
(The implementation for a ruff-style Vfs will be in a separate PR.)
We should probably reconsider exposing span to proc-macro-srv in general, once we have bidirectional messages there, the server knowing the format is merely a performance thing (as we could skip going back and forth for some semantic requests).
It's not a blocker really, it's mainly about dependency cruft. Salsa is a big dependency and the proc-macro server should never need to use or depend on it.