IDE and library-ification strategy, part 2

[nikomatsakis]

Meeting proposal info

• Title: IDE and library-ification strategy, part 2
• Type: technical

Summary

@matklad, @Xanewok, @pnkfelix and I have been spending some time iterating on a plan around library-ification. This is not to say we've been planning out the concrete libraries, but rather that we've been considering the various approaches we might take to incorporating the lessons from the "rust-analyzer experiment" in the big picture. It seems like we're beginning to approach a consensus.

Likely we are not quite ready for the design meeting, but I am opening this issue regardless to "hold the place" -- I say not quite ready because I think the next step is for us to pull our notes together a bit and construct a more concrete proposal that can be discussed.

To outline what we've discussed thus far:

• how to achieve a query-based IDE setup
  • Option 1 ("library-ification") is to keep both projects active, but actively work at extracting shared code.
  • Option 2 is to pause rust-analyzer and try to "port" the ideas to rustc, building up a new, query-based IDE that is working from a unified codebase from the start.
  • We settled on Option 1 for several reasons. The ones I personally find most convincing:
    • it exists today, and users are deriving benefit from it
    • it means we can "mock up" some parts of the engine -- as rust-analyzer is already doing -- to ensure that users benefit, even if we are cutting some corners. This in turn allows us to extract libraries in any order. For example, we can focus on chalk, while having both rustc and rust-analyzer have independent type-checkers that are not quite the same. If we were to try and build a "fully query-based engine" from the start, it'd be a long delay before we got far enough for chalk integration to be "exposed" to IDE users.
• How to reconcile the existing save-analysis based RLS + rust-analyzer?
  • We discussed a few options here but seem to be leaning towards extending rust-analyzer with some save-analysis-based features on a temporary basis. One way to go about this might be to create command-line utilities that rust-analyzer can execute (but also other tools).
  • We would shoot for "feature parity" with the existing RLS and then deprecate and replace it, and instead ship rust-analyzer (perhaps with a new name) as the recommended option.
  • This would be for things like Find All References or Rename.
  • There would be "native" implementations as well that could be enabled via a preference; once they are mature, they would become the default.

About this issue

This issue corresponds to a meeting proposal for the compiler team
steering meeting. It corresponds to a possible topic of
discussion. You can read more about the steering meeting procedure
here.

Comment policy

These issues are meant to be used as an "announcements channel"
regarding the proposal, and not as a place to discuss the technical
details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision.
In the meantime, if you have questions or ideas, ping the proposers
on Zulip (or elsewhere).

[nikomatsakis]

We've scheduled this meeting for Dec 13, 2019

[matklad]

@nikomatsakis do we have notes for this meeting? Should I retroactively write them? Was it me who volunteered to make notes and forgot 😨 ?

[nikomatsakis]

@matklad I was just going over these lists, I don't think we have any notes, but of course there is the zulip stream. I don't think it's worth writing them at this point -- the Zulip archive is here.