RLS 2.0 Draft Roadmap

Possible “deliverables”

  • Reviewing the rust-analyzer design
  • propagating the knowledge about it

Notes on what is happening

  • How to represent syntax trees
  • Name resolution and macro expansion
  • Type checking
  • borrow checking etc to produce all the errors
  • Trait resolution
  • Error tolerance

Today

  • rust-analyzer
  • syntax trees
  • some form of name resolution
  • code which does macro expansion but don’t run it
  • some form of type checker

End-to-end vs complete

  • Two things in parallel:
  • End-to-end
  • what code do we expect to work?
  • can we try to specify a set of features?
  • challenge:
  • small corner cases in the parser?
  • on the other side, error tolerance may mean that we can gracefully degrade
  • type-checker:
  • trait resolution: chalk
  • Specifying and reference impl
  • name resolution + macro expansion
  • Relationship to rustc
  • can we e.g. lower to HIR?
  • not on the initial set of goals, but a good goal at some point
  • Q: do we need to plan for separation of “correct but maybe slow” vs “fast but maybe imprecise” code paths
  • A: lets try not to. If we need it (e.g. because some proc-macros will inherently yield high-latency expansion), then we might consider pushing on revisions to the proc-macro API to address that (e.g. provide an alternate fast-path solely for name-resolution info)

Initial goal proposal:
  • End-to-end for a defined subset
  • Based on: simple name resolution (assuming only “well-behaved” macros for now)
  • We probably still need to do some expansion
  • Might be worth revisiting what “well-behaved” actually means
  • Type-checking
  • Chalk 
  • Name resolution + macro expansion library
  • Separate WG
  • Type-checking extraction
  • Full project is unrealistic at this moment
  • But rust-analyzer building up its own code is fine, and we can revisit
  • But there is code that we can share with chalk:
  • Representation of types