A deep dive into how Rust IDEs understand code, based on a RustRover livestream with Lukas Wirth (rust-analyzer lead, Zed) and Vlad Beskrovny (JetBrains). Key topics include why IDEs must reimplement the compiler frontend for low-latency responses, the evolution from RLS to rust-analyzer, the challenges of Rust's cyclic module graph and name resolution, why procedural macros are isolated into separate processes to prevent IDE crashes, the complexity of replicating Rust's type inference rules, and how RustRover uses PSI stubs and MapReduce-style indexing while rust-analyzer uses Salsa-based query-driven memoization. The post also covers how RustRover integrates semantic analysis into debugging via a custom LLDB integration with MIR evaluation.

9m read timeFrom blog.jetbrains.com
Post cover image
Table of contents
Q1. How did Lukas and Vlad get started with Rust?Q2. Why do Rust IDEs reimplement parts of the compiler?Q3. How did Rust tooling evolve from RLS to rust-analyzer and RustRover?Q4. Why is name resolution in Rust so difficult?Q5. Why are procedural macros such a challenge for IDEs?Q6. Why is Rust type inference difficult to replicate?Q7. How does RustRover analyze large Rust projects?Q8. How does rust-analyzer approach the same problem differently?Q9. How does IDE analysis connect to debugging?Q10. Do Rust tooling authors secretly hate Rust?
123.8K Impressions14 Comments