# 2019.11.18: RLS + rust-analyzer integration

See the [main discussion document](https://hackmd.io/9qrJYdSLTK2MWG4-pbmpWw)

## Prep work for next meeting

* See what features RLS has over Rust Analyzer and vice versa
* Understand other save-analysis consumers' needs (when RLS is deprecated)
* Mozilla's searchfox?
* @est31
* nrc's [cargo-src](https://github.com/rust-dev-tools/cargo-src)
* [Issues labeled A-save-analysis](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AA-save-analysis)
* Proposed architectural alternatives (not necessarily mutually exclusive)
* freeze RLS, focus all energy on rust-analyzer
* extend rust-analyzer with ability to consume save-analysis data in some form
* integrate rust-analyzer into RLS as a "racer alternative" (even worth discussing? unclear)
* What are some "quality metrics" we could use to judge when rust-analyzer is "ready"?
* Feature set
* Precision
* Niko proposed identify a set of crates and requiring >90% (or some threshold) precision from type-checker on those crates
* Requires ability to check type-checker against rustc (another possible role for save-analysis)
* Set of crates where features must work?
* Parts of the language that must be covered?
* In our discussion on [2019.11.06], we also covered this some
* Matklad suggested that any "uncovered language features" should be well known and generally require "just work" (no architectural rewrites)
* But procedural macros might be an exception -- and perhaps there are others?

## Notes from meeting

* matklad attempted an experiment to integrate save-analysis into a simple tool
* short script that implements "find all refs" (targeting "rename symbol")
* using save-analysis library
* have to pass `-Zsave-analysis`, which requires "BOOTSTRAP" but...
* takes a line/col. number

##

* First topic: how "ready" is rust-analyzer, how should we advertise it
* Want to avoid calling r-a "beta quality"
* Didn't like the messaging around RLS 1.0 / 2.0
* trying to say that this is ready, but folks would respond not really
* rust-analyzer is not really ready
* can't be ready in a year, maybe two years
* "two years" is effectively infinity
* Igor -- situation is sort of the same with RLS
* What would it take to feel more comfortable?
* matklad: shared code-base for the core analysis with rustc
* I would feel ok if it were separate but complete (no major missing features)
* how conservative will we have to be to avoid breakage etc?
* some kind of release process would be needed
* bug triaging

* See what features RLS has over Rust Analyzer and vice versa

|feature                |rust-analyzer            | rls
| rename                | incomplete              | ✓
| error reporting       | X                       | ✓

| completion            | ✓                       | provided by racer, not precise
| goto definition       | ✓                       | ✓
| goto type definition  | ✓                       | ?
| find references       | incomplete              | ✓
| assists               | ✓, can add more         | X
| typing handlers       | PoC, can add more       | X
| complex refactorings  | incomplete              | X
| running tests         | ✓                       | exists, but imprecise (regex-based) and incomplete
| type hints            | ✓                       | X
| syntax highlighting   | ✓                       | X
| structural search replace   | X                       | X
| interactive macro expansion | X                       | X
| lifetime visualization| X                       | X
| symbol search         | ✓                       | ✓
| single file analysis  | somewhat                | ?
| extend selection      | ✓                       | ?
| foldnig               | ✓                       | ?
|===

Core differentiator at present:

* RLS has precise find-all-references and rename (based on save-analysis)
* rust-analyzer has incomplete, imprecise support
* https://github.com/rust-analyzer/renamer
* error reporting
* rust-analyzer uses `cargo watch`
* RLS does "sort of the same thing"

# Architecture possibility

* Invoke compiler to get save-analysis, errors
* build up native compatibility
* One route that matklad is elaborating on
* build a command-line tool
* rust-analyzer invokes this tool as a subprocess (other consumers could do so as well)
* we can also pack things like `cargo src` into that
* save-analysis is getting re-generated by running `cargo check` with some argument
* preference in rust-analyzer UI ("which rename algorithm to use")
* when checked, rust-analyzer will run this process etc on a regular basis
* also requires user to actually save all documents to disk
* today `cargo watch` is not requiring saving files, giving strange feedback
* If we wanted to avoid saving files, there are alternatives
* But what other problems do we have
* reusing data between invocations
* second rename has to run cargo check from scratch?
* incremental?
* limitation: if there are errors, data is not great
* limitation: custom build plans etc
* but we can permit people to supply their own command

## proposed consensus

* we will integrate "rustc generating save-analysis" code into rust-analyzer to handle
* error reporting
* find all references
* precise rename
* but offer preference(s) to switch to "native" implementations of those 3 features
* (Observation: this also enables us to compare between the two automatically)

## unresolved questions

* will we be using a separate process that is invoked (`cargo rename`) etc?
* or do we want something resident?
* can we migrate save-analysis to LSIF and how should we do that?

# overall plan

* library-ification proceeds
* build a version of rust-analyzer that incorporates save-analysis as above
* ("RLS 2.0")
* advertise it as a "pre-alpha" or "alpha" software
* given sufficient caveats
* "useful"

# what happens to RLS 1.0 then?

* delivered via rustup today
* does RLS 1.0 just remain, frozen, but stable?
* improve "user-first" installation for cargo?
* so you don't have to build from source
* first thing we should strive for: user parity (save-analysis basically does that)
* does this let us gauge how many projects that worked will stop working
* also true, need for a internal format for formal structure?
* but save-analysis is sort of high level
* stage 1:
* existing RLS is in maintenance
* we extract and build up this "command-line tools" or whatever for rust-analyzer
* stage 2, entering a triage/trial period:
* we compare against some set of crates and project
* stage 3:
* ship rust-analyzer as the "new RLS" with rustup
* this *should* work with other editors out of the box
* though RA does have a bit of "extra features" (extensions to the underlying LSP)