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)
P1 problems
NOTES