Main theme for the meeting was to brainstorm what the“deliverables” for the RLS 2.0 might be, what the current challenges with existing design are and how we should tackle them in the short-to-mid-term.
At first we discussed whether we should aim for an end-to-end language server or for extracting and refactoring specific bits of compiler’s pipeline. There was a consensus that we should aim to do both in parallel but with the end-to-end solutionbeing aprimarytarget for this working group for now.
The former would focus on separating and abstracting away the current model of name resolution and macro expansion. While it makes sense to think of the boundaries for the purposes of refining further design work, abstracting away a library that could be additionally shared by the compiler is something we won’t focus on now or might be a better target for a separate working group altogether.
In order to work towards the end-to-end solution, we agreed to initially limit the scope of correctly supported language features inside an IDE.
Scope
(TODO: Something about the syntax here? It wasn’t discussed during that call specifically)
Macro expansion
One particular thorny area is macro expansion.
We don’t know ahead of time what kind of items might be produced by a macro or how it might affect name resolution during the process, so for now we assume that macros are“well-defined”. More concretely, anything that can influence name resolution(e.g. macros generating named items and/or shadowing) will not be guaranteed to be correctly supported at first. However, at minimum we need to support macros generating impls.
Procedural macros are also tricky to get right. In addition to also not being able to tell about their output kind, these are procedural(who would’ve thought?) and that brings along its own set of problems. These are basically a rustc-specific“programs” that take and produce a structural token stream, which means these are inherently tied to the internal compiler ABI and could potentially be side-effectful.
For now we will ignore potential side-effects but still need to figure out how to possibly solve the ABI issues. One idea is to provide a shim that would translate between the internal rustc_private and some form of“public” token API.
Type inference
Another area we’d like to focus on is the type system.
Currently, Rust Analyzer, on which we build our effort, ships its own type checker and inference engine that is capable of inferring the 80% of the types inside Rust Analyzer itself[1].
While it is unrealistic to extract the full type-inference engine from the compiler and share it, it might make sense to work towards integrating with Chalk - the standalone trait engine that is aimed to be integrated eventually with rustc.
Summary
In short, we decided to primarily work towards an end-to-end effort, which aims to correctly support a subset of the language features in the short term. However, as time goes, we plan on achieving feature parity with the compiler in the long run and merge the resulting code upstream.
Scope
Summary