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:
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).
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 https://github.com/rust-lang/rust/issues/34481).
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 https://github.com/rust-lang/rust/issues/1998).
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?
You might want to also chat with @nrc, who has been working on the RLS by building up rustw (https://github.com/nrc/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 GitHub - rust-dev-tools/cargo-src: Semantic code navigation for Rust 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.