Stream: t-compiler

Topic: pre-design meeting 2019-12-05


nikomatsakis (Dec 05 2019 at 16:20, on Zulip):

Hey @Zoxc --

So @mw and I were talking about the meeting tomorrow (on end-to-end queries) and trying to plan what we ought to be talking about. We were thinking that probably the first question we should be asking is:

Do we expect to land these PRs in rebased form at some point in the near future (or ever)?

nikomatsakis (Dec 05 2019 at 16:21, on Zulip):

I'm sorry to say it, but right now, mw and I were leaning towards "no". This is a combination of a few things:

The last point seems particularly important.

nikomatsakis (Dec 05 2019 at 16:21, on Zulip):

So we figured we'd start the meeting on that question, probably. We were then thinking, presuming the answer does wind up being "no", what else we might discuss. Two thoughts:

OK, that's it. I wanted to give you a heads up and get your reaction, and/or any thoughts on good things to discuss specifically tomorrow.

nikomatsakis (Dec 05 2019 at 16:21, on Zulip):

(also cc @pnkfelix :point_up: )

Zoxc (Dec 05 2019 at 16:40, on Zulip):

These PRs basically does the minimal thing required to move the "incremental barrier" further back without regressing performance. They constrain the "end design" to use a single query / incremental system without much constraints on how that query system is used. An approach in another direction from these PRs would be to use multiple query systems where the later system have some invariant (no parsing errors for example) that has to hold.

Does rust-analyzer use Salsa end-to-end? If so and assuming Salsa is pretty much equivalent to the query system in rustc, that should be very compatible with these PRs.

Zoxc (Dec 05 2019 at 16:41, on Zulip):

I'll also suggest https://internals.rust-lang.org/t/migrating-rustc-interface-queries-to-proper-librustc-queries/10433 as reading material ;)

Zoxc (Dec 05 2019 at 16:51, on Zulip):

The summary section highlights the problematic parts of the PRs.

Zoxc (Dec 05 2019 at 16:56, on Zulip):

The first PR which moves the "incremental barrier" back to (but not including) HIR lowering doesn't suffer from the problematic parts though. Landing that would allow us to replace the HIR map structure with its (probably broken in some way) custom incremental dependency tracking with proper queries. I do expect that moving to queries will come with a performance cost though.

nikomatsakis (Dec 06 2019 at 14:34, on Zulip):

I certainly read the internals thread :)

nikomatsakis (Dec 06 2019 at 14:34, on Zulip):

Anyway, it seems like it would be a good use of time then to cover the "big picture"

nikomatsakis (Dec 06 2019 at 14:40, on Zulip):

I was just discussing with @pnkfelix a bit

nikomatsakis (Dec 06 2019 at 14:41, on Zulip):

Despite how the message above might read, I want to emphasize that I don't want the meeting to have a foregone conclusion, but I did want to warn you where I personally lean beforehand

nikomatsakis (Dec 06 2019 at 14:41, on Zulip):

These PRs basically does the minimal thing required to move the "incremental barrier" further back without regressing performance.

I guess we should discuss this part -- I think the most fruitful thing would be to talk about what high-level strategy we take

nikomatsakis (Dec 06 2019 at 14:42, on Zulip):

I'm trying to think how to frame the agenda, in other words

Last update: Jan 21 2020 at 09:40UTC