# RLS unification options
## 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
- 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
- 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
- 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
- "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
- 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
- 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)
- rust-analyzer can go wild with experementation
- we don't disrupt existing users' workflows
- obviously doesn't help with two codebases problem
- if we move rls to queries, will it meaningfully improve observable user experience?