So lately I’ve been having separate conversations that all seem to be swirling about a central theme, and I wanted to try and bring those different threads together onto one thread.
It’s hard for me to clarify what this thread is about. I’m going to use the sort of generic title of a “Strategy for rustc and the RLS” for the time being. Probably a good place to start is to try and enumerate our goals. I have many in mind.
First and foremost, how can rustc help enable a truly excellent IDE experience?
But also a number of other things, that I think are interrelated:
- How can we make rustc more maintainable and accessible?
- Related: How can we grow the base of rustc contributors?
- Related: How can we improve the pace of rustc innovation?
- How can we support procedural macros that parse and manipulate Rust code?
- How can we expose parts of rustc as libraries?
We have a lot of pieces floating around. I’ll just list out a few here, but I’m going to forget things.
@matklad’s work on libsyntax2:
- @matklad has been building up a replacement for libsyntax from scratch. The parser is designed from the first to be incremental, fully whitespace preserving, and to do error recovery. As a result, it is well-suited to IDEs, but also to things like procedural macros.
- rustc’s incremental support and the transition to a query system:
- rustc now has a pretty powerful incremental system, but it’s not yet usable “end to end” – that is, we always parse, expand macros, run name resolution, and lower to HIR – even if the input files haven’t changed. This needs to change if we want to have the super fast response times that an IDE needs.
- extracting libraries like Chalk and Polonius
- One of my interests of late has been extracting out complex problems from rustc into libraries that can be independently supported. These libraries tend to follow a pattern of having a core chunk of shared code along with a wrapper that does unit testing. Chalk (trait system) and Polonius (borrow checker) are two examples. This approach feels very appealing to me as a way to turn rustc into more of a component architecture, but it’s not yet proven (neither Chalk nor Polonius are in use). How far can we take it? Can we make MIR into a library? What about our representation of types? for example)
- RLS today and tomorrow
- Right now the RLS communicates via save-analysis. We want it to use the query system (probably?). We also want faster response times and perfect results etc. We have to think about also how to ensure that the RLS is well-maintained – particularly as its usage grows. How can we get from here to there?
Actually, I’m going to stop this post here. I’ll try to add comments with various ideas for possible directions. Or maybe others will do so.