2019.11.18: RLS + rust-analyzer integration

See the main discussion document

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)
  • 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)
  • 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)
Select a repo