owned this note
owned this note
Published
Linked with GitHub
# RLS unification options
[Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rls.20.2F.20rust-analyzer.20planing)
## Problems and goals
We have two separate code-bases: rust-analyzer and RLS:
* we need more resources to maintain the two
* users are confused which one should they use
* even if users pick one, some features will be better in the other
save-analysis approach of RLS is hard to support, we need to move to queries anywa (@Xanewok, this is what I understood at the begining of the discussion, could you clarify this problem?)
save-analysis is slowly becoming dated and predates the query infra, basically reimplements the analysis step
it might be more worthwhile to skip the extra step and query rustc directly
We also want to maintain "experimental" nature of rust-analyzer, which prioritizes trying things out over the final user epxerience.
## Proposed approaches
### Extend rust-analyzer with cargo-check for error reporting
Idea: run cargo check to uncover errors from rust-analyzer, use rust-analyzer for everything else
Advantages:
- error reporting is correct (which is the most important thing for it)
- completion is fast (which is the most important thing for it as well)
- very easy to implement and support, as `cargo check` interface is stable
Disadvantages:
- error reporting not as snappy as we would like (but that can be improved)
- no support for find-all-uses or other features that RLS supports but rust-analyzer doesn't yet have
- supporting non-cargo build systems would be tricky (but doable, if build-system can run equivalent of `cargo check --message-format=json`)
- obviously, will duplicate work, so higher peak memory usage + CPU time
Questions:
- if rust-analyzer is our only codebase, does that hinder experimentation?
- how do we solve distribution problem? (rls comes from rustup)
### Add rust-analyzer to RLS as a "racer alternative"
Idea: users can opt for rust-analyzer to handle completions and jump-to-def
Advantages:
- "RLS" is the go to thing, rust-analyzer is now a "RLS add-on"
- Users get rustc's jump-to-def, errors when it's ready, but otherwise they can get rust-analyzer for faster results
- No feature regression versus existing RLS
Disadvantages:
- more complex, more code
- rust-analyzer is a memory hog, and that would be additive to what RLS already uses
- if we use "external process" model, we probably lose some perf
- if we use in-process model, we make changing ra's internal APIs harder
Questions:
- How would RLS bridge to rust-analyzer, anyway?
- Idea: "forward" the LSP protocol requests to another process
- Idea: bring it in process somehow and unify the "VFS" implementations
### Maintain status quo (two separate projects)
Advantages:
- rust-analyzer can go wild with experementation
- we don't disrupt existing users' workflows
Disadvantages:
- obviously doesn't help with two codebases problem
Question:
- if we move rls to queries, will it meaningfully improve observable user experience?