Next Few Years

The most fundamental data structure in rust-analyzer, even more fundamental than a syntax tree, is the VFS, or Virtual File System. It serves two dual goals:

• providing consistent immutable snapshots of the file system,

• applying transactional changes to the state of the file system.

This abstraction is the boundary between the pure-functional universe of rust-analyzer, and the messiness of the external world. It needs to bridge case-insensitive file systems, symlinks and cycles to a simpler model of "tree with utf8 paths" we want inside. Additionally it should work with non-path files: there are use-cases where we want to do analysis of Rust code, which doesn’t really reside on the file system.

One specific aspect I am struggling with is dynamism. On the one hand, it seems that a good design is to require to specify the set of files in VFS upfront, as a set of globs. This is important because, to properly register file watchers without losing updates, you need to crawl the file-system eagerly. However, specifying a set of globs up-front makes changing this set later messy.

I would be curious to hear about existing solutions in this area. One specific question I have is: "How does watchman handle dynamic addition/removal of projects?". If you have any experience to share, please comment on the VFS issue in rust-analyzer. Ideally, we turn VFS into just a crates.io crate, as it seems generally useful, and can encapsulate quite a bit of complexity.

The current VFS is …​ not great, I don’t feel comfortable building rust-analyzer on top of it.

At the moment, proc-macros are implemented as dynamic libraries, loadable into the compiler process. This works ok-enough for the compiler, but is a pretty bad fit for an IDE:

• if a proc-macro crashes, it brings down the whole process,

• it’s hard to limit execution time of proc-macro,

• proc-macros can be non-deterministic, which breaks internal IDE invariants.

At the moment, we paper over this by running proc-macros in a separate process and never invalidating proc-macro caches, but this feels like a hack and has high implementation complexity. it would be much better if proc-macros were deterministic and controllable by definition, and WASM can give us that.

I am slightly worried that this will get push-back from folks who want to connect to databases over TCP at compile time :) Long term, I believe that guaranteeing deterministic compilation is hugely important, irrespective of IDE story.

There’s a very important language property that an IDE can leverage to massively improve performance:

What happens inside a function, stays inside the function

If it is possible to type-check the body of a function without looking at the bodies of other functions, you can speed up an IDE by drastically reducing the amount of work it needs to do.

Rust mostly conforms to this property, but there are a couple of annoying violations:

• local inherent impls with publicly visible methods.

• local trait impls for non-local types.

• #[macro_export] local macros.

• local out-of-line modules.

If we want to have fast & correct IDE support, we should phase out those from the language via edition mechanism.

Note that auto-trait leakage of impl Trait is not nearly as problematic, as you only need to inspect a function’s body if you call the function. Of course, as an IDE author I’d love to require specifying auto-traits, but, as a language user, I much prefer the current design.

rust-analyzer uses a novel and rather high-tech query-based architecture for incremental computation. Today, it is clear that this general approach fits an IDE use-case really well. However, I have a lot of doubts about specific details. I feel that today rust-analyzer lacks mechanical sympathy and leaves a ton of performance on the table. A lot of internal data structures are heap-allocated Arc -droplets, we overuse hashing and underuse indexing, we don’t even intern identifiers!

To get a feeling of how blazingly fast compiler front-ends can be, I highly recommend checking out Sorbet, type checker for Ruby. You can start with these two links:

• https://blog.nelhage.com/post/why-sorbet-is-fast/

• https://www.youtube.com/watch?v=Gdx6by6tcvw

I am very inspired by this work, but also embarrassed by how far rust-analyzer is from that kind of raw performance and simplicity.

Part of that I think is essential complexity — Rust’s name resolution and macro expansion are hard . But I also wonder if we can change salsa to use Vec -based arenas, rather than Arc s in HashMap s.

In my opinion the two important characteristics that determine long-term success of a project are:

• How long does it take to execute most of the tests?

• How long does it take to build a release version of the project for testing?

I am very happy with the testing speed of rust-analyzer. One of my mistakes in IntelliJ was adding a lot of tests that use Rust’s standard library and are slow for that reason. In rust-analyzer, there are only three uber-integrated tests that need the real libstd, all others work from in-memory fixtures which contain only the relevant bits of std.

But the build times leave a lot to be desired. And this is hugely important — the faster you can build the code, the faster you can do everything else. Heck, even for improving build times you need fast build times! I was trying to do some compile-time optimizations in rust-analyzer recently, and measuring “is it faster to compile now?” takes a lot of time, so one has to try fewer different optimizations!

The biggest problem here is that Rust, as a language, is hard to compile fast. One specific issue I hit constantly is that changing a deep dependency recompiles the world. This is in contrast to C/C++ where, if you don’t touch any .h files, changing a dependency requires only re-linking. In theory, we can have something like this in Rust, by automatically deriving public headers from crates. Though I fear that without explicit, physical “this is ABI” boundary, it will be much less effective at keeping compile times under control.

As an aside, if Rust stuck with .crate files, implementing IDE support would have been much easier :-)