Roadmap to RLS


Currently, the implementation of the Rust Language Server (RLS) is blocked by the lack of incremental compilation. However, I think there are some issues that could be addressed right now, without waiting for incremental compilation to land:

  1. Enhancing the compiler to be more tolerant to invalid programs. This would in turn allow the RLS to provide analysis information even though a program doesn’t compile (this seems especially interesting for the code completion use case).
  2. Improving save-analysis, since it will be the base upon the RLS is built. Currently, one of the biggest shortcomings of save-analysis is its unreliability given the lack of tests (see
  3. Figure out a way to handle conditional compilation in save-analysis. Otherwise, the RLS will be unable to provide information about part of the conditionally compiled code (see

Are there other items that can be addressed right now in order to pave the way for the RLS? Would it make sense to file an issue to lay out a roadmap for RLS-related improvements?


FYI, 1 is partially implemented behind -Z continue-parse-after-error.


@sanxiyn Awesome! Is that documented somewhere?


You might want to also chat with @nrc, who has been working on the RLS by building up rustw ( I’m not sure what the status is of specific features, but he’d know.

IIRC, he’s also who built in some of the error tolerance in the compiler.


I agree there is lots to do that is independent of incr. comp. When talking with @nrc we’ve generally viewed incr. comp. as effectively a kind of optimization. That is, results are available more promptly, but otherwise the basic interaction is the same.

In general, @nrc has been working on as a kind of prototype for the RLS. That is, rustw has a backend that takes save data and collates it, to some extent. But I’m not sure of the exact status. (In any case I know he has in mind some of the things you listed, as @jntrnr said.)


One CRUCIAL feature is secure communication. Locally, that means Unix domain sockets (Unix-like systems) and/or named pipes (with cryptographic authentication of the server AND secure setting of ACLs on the named pipe – the default setting is insecure). Remotely, that means tunneling over SSH.