RLS and IDE integration
Audience
compiler team + RLS hackers
Key People
probably just about everyone on compiler team
When
Monday, 11:00-13:00
Where
Gainsboro
Meeting Style
Discussion
Deliverables
  • Design sketch for the key questions listed below
Homework to do before meeting
  • Participants should have watched and consumed:
Agenda
  • the goal is to try and sketch out what we think the design of RLS/rustc integration should be
  • there is general consensus around the “lazy, on-demand” approach, but many details to figure out still
  • some key questions to try and answer:
  • what are the "base inputs" to the analysis?
  • how will we represent source text of input files?
  • how to reason about crates?
  • what is relationship to cargo?
  • what do our syntax trees look like
  • how do we handle things from crates.io? (edit: added later)
  • how do we maintain links between IRs, map back to source text?
  • how to manage name resolution, macro expansion
  • how to find impls and manage trait resolution
  • where are the distinct processes and how long do they live
  • and how do we manage resources for longer-lived processes?
  • >e.g., interning pools and so forth
  • what is the state that is stored by long-lived process
  • how granular is incremental compilation?
  • some key IDE operations to consider
  • completion, first and foremost
  • go to def
  • find all uses
  • ..?
  • the hope is that once we have some picture of the technical approach we want, it will help us to come up with a plan regarding how to get there
  • e.g., incrementally improve RLS? adopt rust-analyzer? something in between?

P1 problems

  • Compilation time, responsiveness
  • Technical debt: hard to do things
  • Organizational challenges --
  • finding people to do things
  • discussing the things that we do
  • growing design + leadership

NOTES

Niko’s opinion is that the compiler and IDE teams should not be separate teams; we have the same goals. (And to his knowledge people generally agree with this)
Example of tech debt: We have two region solvers, will/would have three if we merge polonius. (arielb points out related example of multiple borrow-checkers arising from having a “feature we don’t want to support”, there are several other “features we don’t want to support” e.g. 2 macro systems)