Why building a Rust LSP is hard

This explains why implementing a Rust language server is much harder than it looks, by tracing the practical engineering choices and trade-offs needed to produce useful results from partial information. An LSP must respond to an initialize handshake without blocking on full indexing, so implementations either defer heavy workspace discovery or stay passive until the first query. Real-world problems include keeping a synchronized virtual file system and source generations to avoid race conditions between editor edits and filesystem changes, serializing editor messages to preserve order, running many read queries in parallel while canceling outdated work after state mutations, and using LSP refresh primitives where possible - with the caveat that some responses (like document symbols) cannot be refreshed by the client.

Indexing has clear layered responsibilities: parse/CST, item tree, module resolution/definition maps, a semantic layer, and then body analysis. Different LSP features require different depths: document symbols can be served from a single-file parse, hover needs defmaps and resolution, inlay hints require body analysis and type inference, and references require workspace-wide search plans with text-based pruning to avoid scanning thousands of bodies for pathological names like Option. rust-analyzer solves incrementality with salsa’s memoized database; Rust Glancer and rust-analyzer share layers but make different trade-offs in when and how data is computed. Building a usable LSP is primarily an exercise in managing partial, changing state under strict latency and correctness constraints.