# Batch vs Server architecture for stripped down RLS

## Links

Part of an ongoing conversation about reconciling RLS and rust-analyzer.
See the [master document](https://hackmd.io/9qrJYdSLTK2MWG4-pbmpWw) which indexes all the various hackmds.

## Goals

Bring critical functionality, which needs precision, from RLS to rust-analyzer:
* correct error highlighting
* find usages/rename

Notes:
* There will be a flag to choose between "native" and "save-analysis based" implementations of these features
* find usages and rename are *rare* features, not every changes triggers them
* both approaches are temporary crutches, until rust-analyzer-like analysis infrastructure matures and we'll be able to *just* run every analysis precisely in an IDE setting

## Approaches

### Stripped down RLS server (filled-in my @matklad, may contain major misunderstandings)

#### Implementation Strategy

First phase: in rust-analyzer, we add ability to spawn RLS process and forward some requests to it.

Second phase: we strip down code in RLS by:
* replacing save-analysis with using compiler's in-memory data structures
* removing code responsible for features other than find usages and rename
* removing code responsible for passing file diffs (?)

nikomatsakis: I'm not sure that it's really a goal to replace save-analysis. That seems like a lot of work which kind of duplicates the effort of building up the analogous structures in rust-analyzer. At the same time, I wouldn't call it *not* a goal. Regarding file diffs, there's a real question there: maybe it's easy enough for rust-analyzer to feed in "open files and diffs" to the "backend RLS" server, which then avoids the problem of forcing "find all usages" to require files be saved? (Can an LSP implementation even force the editor to save files? Would that be something we would have to do in the plugin?)

#### Benefits

* stable interface, not something ad-hoc we have to experiment with
* ability to stay resident means that repeated uses will be faster
* you could still wait to start it (and potentially ask it to quit after some time) to control memory usage
* closer to the existing RLS (basically it would be kind of stripped down)
* can maybe literally start *as* the existing RLS?
* we can remove save-analysis altogether, as nobody is happy with it in its current form (but some people think that some data formant *like* save-analysis is nice to have eventually)
* the approach looks like it moves in the general direction of the end-state we want to see

#### Drawbacks

* we still maintain significant chunks of RLS, in particular:
* code that marries single-crate world of rustc with multi-crate world of Cargo
* code that links to cargo and re-does build logic
* we still have `#[feature(rustc_private)]` in the build, meaning that we tie build process to the build process of rustc itself
* replacing save-analysis with in-memory data structures is work
* overall complexity seems higher, since we need to juggle persistent processes, instead of shelling out to batch processes
* hard to support non-cargo build systems

### "CLI" tool for batch analysis of save-analysis files

#### Implementation Strategy

No code is shared with RLS server. We re-use existing libraries for reading save-analysis data (rls-analysis, rls-span, etc). No changes to rustc or cargo.

For error highlighitng, rust-analyzer runs `cargo check --message-format=json`. For find-usages, rust-analyzer runs `RUSTFLAGS=-Zsave-analysis cargo check`, then reads save-anlysis data. User can override these command-line invocations. We require that client saves all modified documents before issuing these requests.

nikomatsakis: What happens when user is not using nightly? Then `-Zsave-analysis` isn't available.

nikomatsakis: The LSP server itself can't require the client to save all modified documents, right? So this would require all editor plugins to be aware of these changes?

#### Benefits

* no changes to rls/rustc/cargo are required, all bits are already in place
* we don't have to maintain RLS tool anymore (but we might want for some time, to smooth out the transition)
* no component uses `#[feature(rustc_private)]`, no component blocks rustc's CI, everything builds with `cargo build`
* supports all cargo builds out of the box
* supports other build system with some effort
* guaranteed correct build environment, by construction (as we shell out to the build system)

#### Drawbacks

* we need to find a way to use `-Zsave-anlysis` on stable without stabilizing save-analysis. @matklad thinks that just setting `RUST_BOOTSTRAP=1` from rust-analyzer is fine (and can explain it), but this would be a controversial issue, and we might need to invent something more official. A straw-man would be `tools_unstable` for non-language features that exist on stable, can't affect the build in any way, will change with next releases and are targeted for tools which explicitly track revision of compiler.
* nikomatsakis: Just setting RUST_BOOTSTRAP=1 would also allow access to feature gates... I guess that this would only be used for the "find all usages" command, though.
* nikomatsakis: There is a "de facto" dependency between rust-analyzer and the version of rustc in use (i.e., if we change the save-analysis format, it would break rust-analyzer). Unless rust-analyzer is distributed (and versioned) with rustup, this seems like it will be error-prone and difficult to manage. (But we could well distribute rust-analyzer with rustup)
* matklad: there's already a "de facto" dependency. rust-ananlzyer analysis std library from source, and so it has to support nightly features even for stable toolchain. It also hard-codes the set of crates in sysroot (including private ones) and their dependencies. The same applies to IntelliJ Rust.
* not instant performance: the time is that of `cargo check` plus serializing/deserializing save analysis.
* this is explicitly throw away code. By itself, it's not a part of the end-game solution.
* will require editor plugins to be updated to force save before executing those commands (and then, once we have things working, to stop requiring that)

### "CLI" tools distributed with rustup

#### Implementation strategy

Similar to above, except that the tools are executables distributed with rustup as part of distributing the "RLS". They encapsulate the use of save-analysis, simply spitting back results to rust-analyzer in some unspecified format. This is very similar to forwarding requests to the RLS, except it doesn't require maintaining multiple processes, but also comes with the latency and other down-sides of running batch commands. (Internally, these tools could "shell out" to cargo to gather the save-analysis data.)

#### Benefits

* relative to having rust-analyzer directly consume save-analysis, this encapsulates the knowledge of save-analysis into a distinct tool

#### Drawbacks

* this is a new tool with new options; we can specify that it may not continue to exist, but people could come to rely on it
* not sure if there are possible mitigations here
* not instant performance: the time is that of `cargo check` plus serializing/deserializing save analysis.
* this is explicitly throw away code. By itself, it's not a part of the end-game solution.
* will require editor plugins to be updated to force save before executing those commands (and then, once we have things working, to stop requiring that)