Systemnahes Programmieren

Let me preface all of this by saying that rust-analyzer is an amazing project, and I am eternally grateful for the many people who contribute to it! It makes developing rust code a breeze, and it has surely significantly contributed to Rust's widespread adoption.

If you've ever worked with a very large cargo workspace (think hundreds of crates), you know that rust-analyzer eagerly builds compile time dependencies (e.g. proc macros) and indexes all the crates in your workspace at startup. For very large workspaces, this can take quite a while. Even after indexing is complete, operations like searching for symbols and autocomplete can be laggy. If you often open and close your editor (shout out to all the (neo)vim users out there), it can take a few minutes for rust-analyzer to finish starting up again. Setting check.workspace = false and cachePriming.enable = false can help significantly, but in my experience, they don't solve the problem completely.

After reading through the rust-analyzer manual, I noticed that rust-analyzer supports integrating with third party build tools, like bazel and buck. In short, it is possible to point rust-analyzer to a command that it will invoke with a path to a source code file to discover information about the crate that the file belongs to. This "automatic project discovery" is intended to give third party build tools a way to communicate information about the structure of a project (e.g. the dependency graph) such that rust-analyzer doesn't need to use cargo. I realized that, theoretically, it should be possible to write a tool that still uses cargo under the hood and selectively tells rust-analyzer about a workspace's dependency graph as new files are opened.

That's where cargo-subspace comes in. cargo-subspace is a CLI tool that takes a path to a source code file as an argument and prints out information about the crate that the file belongs to and that crate's dependencies. It works like this:

Find the manifest path (i.e. the path to the Cargo.toml) for the source code file's crate to determine the crate that owns the file
Invoke cargo metadata, which returns the full dependency graph for the workspace
Prune the dependency graph so that it only contains the file's crate and that crate's dependencies
Build compile time dependencies (e.g. proc macros and build scripts) for only the crates in the pruned dependency graph
Print the pruned dependency graph in the JSON format expected by rust-analyzer

As you open new files in your editor, rust-analyzer will invoke the tool to discover information about how the crate fits into the larger dependency graph of the workspace, lazily indexing and building compile time dependencies as you go. I've found that this approach significantly reduces rust-analyzer's startup time and makes it much zipper and more stable.

If you frequently work with very large cargo workspaces, I'd love for you to try it out and give me some feedback. I tested it myself and it seems to work the way I'd expect, but I'm sure there are some edge cases I haven't considered. There are also some other features I'm considering adding (e.g. an option to include all the dependents of a crate in the dependency graph and not just the dependencies, the ability to read from an "allowlist" file to always index and load a subset of the crates in the workspace, etc.), and I'd be curious to hear if y'all have any other ideas/requests. Installation and configuration instructions can be found in the README.