Stream: t-compiler

Topic: design meeting 2019-12-06


pnkfelix (Dec 06 2019 at 14:24, on Zulip):

Hey @T-compiler/meeting , we'll be starting this week's design meeting in about 36 minutes

pnkfelix (Dec 06 2019 at 14:26, on Zulip):

today's topic is "migrate rustc_interface queries", compiler-team#175

pnkfelix (Dec 06 2019 at 14:26, on Zulip):

(a little pre-meeting discussion has been going on in another zulip topic)

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

Here is a hackmd where I'll try to take notes etc, it has a collection of links to start

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

ugh, hackmd deals really poorly with being tiled

Zoxc (Dec 06 2019 at 14:56, on Zulip):

So did you want to talk about what high-level strategy we should take to make the earlier parts of the compiler incremental too?

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

I'm not sure I understand the question

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

I guess maybe you're saying -- should we talk about e.g. what to do to parsing in praticular?

nikomatsakis (Dec 06 2019 at 15:00, on Zulip):

(or some other component)

nikomatsakis (Dec 06 2019 at 15:00, on Zulip):

Hey @T-compiler/meeting -- design meeting starting now!

nikomatsakis (Dec 06 2019 at 15:00, on Zulip):

today's topic is "migrate rustc_interface queries", compiler-team#175

nikomatsakis (Dec 06 2019 at 15:00, on Zulip):

Here is a hackmd where I'll try to take notes etc, it has a collection of links to start

nikomatsakis (Dec 06 2019 at 15:00, on Zulip):

Announcements

Zoxc (Dec 06 2019 at 15:02, on Zulip):

No, I just wasn't sure what exactly you meant by what high-level strategy we take.

nikomatsakis (Dec 06 2019 at 15:05, on Zulip):

Yeah a fair question :) I guess we'll get into it. I think what I meant was probably multiple things.

One of them is this: I think that these PRs endeavor to push the "query system" back all the way to the parser, but in some cases they do they by kind of working around the query system (this is particularly true in the HIR PR, maybe less so in the others). It might be nicer to just look at (e.g.) how to make HIR lowering incremental first, but try to do it in a way that either leverages query system or -- if it's not sufficient as is -- extends it first.

Zoxc (Dec 06 2019 at 15:05, on Zulip):

Our options would be to 1) extend the query system further back, 2) use some other incremental system before the existing system, 3) some combination of the above, 4) do nothing yet

nikomatsakis (Dec 06 2019 at 15:06, on Zulip):

But I think there's also the question (to me) of how end-to-end query refactoring should fit in with things like library-ification and rust-analyzer -- we can only be changing and moving so many at a time.

nikomatsakis (Dec 06 2019 at 15:06, on Zulip):

Anyway, I haven't seen any announcements yet, I guess we could get started?

nikomatsakis (Dec 06 2019 at 15:07, on Zulip):

( cc @eddyb, @matklad, two people I think might have relevant thoughts that I didn't see in the :wave: list above )

nikomatsakis (Dec 06 2019 at 15:07, on Zulip):

OK, well, the idea is to talk about end-to-end queries and especially the PR series that @Zoxc described in this internals thread

nikomatsakis (Dec 06 2019 at 15:08, on Zulip):

First question perhaps, do people feel like they know what "end-to-end queries" means?

nikomatsakis (Dec 06 2019 at 15:09, on Zulip):

In short, right now, the "query system" -- and hence incremental compilation -- starts only once HIR is constructed. We always parse the entire crate, do macro expansion and name resolution, and create the full HIR.

nikomatsakis (Dec 06 2019 at 15:09, on Zulip):

This can be a performance problem for incremental compilation

nikomatsakis (Dec 06 2019 at 15:09, on Zulip):

Since it's kind of a "minimum bar" of work we always do

nikomatsakis (Dec 06 2019 at 15:09, on Zulip):

It's also just non-uniform

nikomatsakis (Dec 06 2019 at 15:09, on Zulip):

Anyway, I'm presuming that's mostly familiar

nikomatsakis (Dec 06 2019 at 15:10, on Zulip):

I'm debating what foot to start on :) I feel like we should talk a bit about the PRs under discussion and what they do?

pnkfelix (Dec 06 2019 at 15:11, on Zulip):

in the pre-discussion, there was a claim

pnkfelix (Dec 06 2019 at 15:12, on Zulip):

that these PR's, or at least some of them, aim to do the simplest possible thing to get to end-to-end queries

pnkfelix (Dec 06 2019 at 15:12, on Zulip):

if we could explain them in that light, it would be helpful

pnkfelix (Dec 06 2019 at 15:12, on Zulip):

in the sense of trying to tease out what they do, and why/whether that is truly the minimal/simplest thing possible

nikomatsakis (Dec 06 2019 at 15:13, on Zulip):

Makes sense. @Zoxc if you want to jump in, obviously, feel free, I can try to give my take, based primarily on the internals thread.

nikomatsakis (Dec 06 2019 at 15:13, on Zulip):

Basically the PRs kind of go phase by phase, to some extent

matklad (Dec 06 2019 at 15:13, on Zulip):

:wave:

nikomatsakis (Dec 06 2019 at 15:13, on Zulip):

e.g., right now we construct this "HIR map" that indexes all the HIR, and that is passed to the tcx constructor I believe as a value

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

But #59064 tries to move that into a query method

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

This is a kind of "global query" in that there is only really one hir map

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

so the key is basically () (I guess?)

pnkfelix (Dec 06 2019 at 15:15, on Zulip):

the internals doc makes some side comment about potentially in the future trying to move away from a single global hir_map

nikomatsakis (Dec 06 2019 at 15:15, on Zulip):

there is various bits of special treatment

nikomatsakis (Dec 06 2019 at 15:15, on Zulip):

Yeah, I think is a key point

Zoxc (Dec 06 2019 at 15:15, on Zulip):

The key is a CrateNum, but it's basically global since we only compile one crate at a time now

nikomatsakis (Dec 06 2019 at 15:16, on Zulip):

I think right now the hir_map query is rather special and not treated as a normal incremental value -- otherwise basically everything would be dirty

nikomatsakis (Dec 06 2019 at 15:16, on Zulip):

sorry, this is actually true in "master"

nikomatsakis (Dec 06 2019 at 15:16, on Zulip):

but it's also true in that PR

nikomatsakis (Dec 06 2019 at 15:16, on Zulip):

i.e., by "right now" I meant after the PR lands

nikomatsakis (Dec 06 2019 at 15:16, on Zulip):

when you e.g. request a bit of HIR from the map, there is special logic that adds the appropate dependencies

nikomatsakis (Dec 06 2019 at 15:17, on Zulip):

this is definitely one of the things that @mw and I were concerned about -- that right now, we'd prefer to be moving towards a system with fewer special cases

mw (Dec 06 2019 at 15:18, on Zulip):

that would be one of the main advantages of end-to-end queries

nikomatsakis (Dec 06 2019 at 15:18, on Zulip):

this comment from the internals thread sounds closer to the kind of thing I am thinking of:

I imagine we’ll replace the hir_map and hir function and cache with a query which takes an item and returns a smaller map for just the ItemLocalIds for that item. Another krate query can replace the whole crate API’s in the HIR map. I’m not sure how well this scheme will perform. In particular we may want a method to avoid hashing the HIR twice. Having krate be a no_hash query might suffice here.

Zoxc (Dec 06 2019 at 15:18, on Zulip):

After landing that PR, we could replace the HIR map with its special logic with queries instead, and rely on queries for correctness

Zoxc (Dec 06 2019 at 15:19, on Zulip):

A goal for the PRs was really to allow every pass to be turned into queries in parallel (and not just a step at a time)

mw (Dec 06 2019 at 15:19, on Zulip):

I would prefer if we did the fully queried version of HIR indexing to begin with

nikomatsakis (Dec 06 2019 at 15:20, on Zulip):

Right, so there's a kind of "high-level strategy" question of whether to first get everything into the query system (with suitable special cases) and then slowly clean it up, or to try and clean it up as we go and push the boundary back

nikomatsakis (Dec 06 2019 at 15:20, on Zulip):

I'm curious, btw, @mw -- you mentioned measurements of compilation time that would benefit, I think you said something like 40% of compilation time came before HIR, do you have more specific numbers?

nikomatsakis (Dec 06 2019 at 15:20, on Zulip):

I guess maybe we can find that on perf

nikomatsakis (Dec 06 2019 at 15:21, on Zulip):

In particular, I was wondering whether parsing, macro expansion, or HIR lowering represented an "outsized" chunk of it

mw (Dec 06 2019 at 15:21, on Zulip):

that was a clean webrender check build of a recent nightly

nikomatsakis (Dec 06 2019 at 15:21, on Zulip):

I would prefer if we did the fully queried version of HIR indexing to begin with

I think I would prefer this too; I can imagine that moving "hir map" to a query is a good first step, but that's not obvious. I would think we can convert the hir map methods to queries first, and come to (more and more) rely on the standard red-green hashing

mw (Dec 06 2019 at 15:22, on Zulip):

https://perf.rust-lang.org/detailed-query.html?commit=d0126e8ed3cc0d6fcb9dd44c36a46f9ce65010a0&benchmark=webrender-check&run_name=clean%20incremental

pnkfelix (Dec 06 2019 at 15:22, on Zulip):

I'm trying to understand: Is "fully queried version of HIR indexing" anywhere in the PR series we're discussing?

Zoxc (Dec 06 2019 at 15:23, on Zulip):

The PR is a prerequisite to move any part of HIR indexing into queries though.

pnkfelix (Dec 06 2019 at 15:23, on Zulip):

I don't see it in the internals thread, at least not from what I can see

nikomatsakis (Dec 06 2019 at 15:23, on Zulip):

I'm trying to understand: Is "fully queried version of HIR indexing" anywhere in the PR series we're discussing?

I don't thnk so

Zoxc (Dec 06 2019 at 15:23, on Zulip):

It is not.

mw (Dec 06 2019 at 15:23, on Zulip):

for reference, a non-incremental check build spends more like 10% before incremental kicks in: https://perf.rust-lang.org/detailed-query.html?commit=d0126e8ed3cc0d6fcb9dd44c36a46f9ce65010a0&benchmark=webrender-check&run_name=clean

nikomatsakis (Dec 06 2019 at 15:24, on Zulip):

so in those numbers, build_hir_map (for example) is about 9.17%, parsing is 9%, macro expansion 9%, and resolve 10%

pnkfelix (Dec 06 2019 at 15:24, on Zulip):

The PR is a prerequisite to move any part of HIR indexing into queries though.

"The PR" being #59064, right?

nikomatsakis (Dec 06 2019 at 15:24, on Zulip):

pretty clean distribution :)

nikomatsakis (Dec 06 2019 at 15:24, on Zulip):

I guess @Zoxc (a) I'm not sure that the PR is a pre-req but also (b) I'd rather talk about the end-state we are trying to build first

nikomatsakis (Dec 06 2019 at 15:24, on Zulip):

and then figure out the steps we take to get there

nikomatsakis (Dec 06 2019 at 15:24, on Zulip):

then start with the steps

nikomatsakis (Dec 06 2019 at 15:24, on Zulip):

and I still don't quite see that design

nikomatsakis (Dec 06 2019 at 15:24, on Zulip):

(though I suspect we have similar things in mind)

nikomatsakis (Dec 06 2019 at 15:25, on Zulip):

I think for example I would expect to ultimately have any HIR map at all

nikomatsakis (Dec 06 2019 at 15:25, on Zulip):

there would probably just be "base queries" that extract out the HIR for a given item, and rely on red-green hashing

nikomatsakis (Dec 06 2019 at 15:25, on Zulip):

those queries would do the lowering on demand

nikomatsakis (Dec 06 2019 at 15:26, on Zulip):

(this is partly why I pinged @matklad, since I thiink that rust-analyzer has been carving out a path much like this; I know it's what we were doing experimentally when building Lark too)

matklad (Dec 06 2019 at 15:27, on Zulip):

Yeah, in rust-analyzer we build a map of top-level items, and each body is a separate map/query

Zoxc (Dec 06 2019 at 15:28, on Zulip):

I'd expect a similar fate for the HIR map. I do worry about the performance of that (for clean builds), but hopefully we can make any regression small.

pnkfelix (Dec 06 2019 at 15:29, on Zulip):

so is the question if a step like #59064 is not worth taking, compared to trying to work towards a design where there are per-item queries?

nikomatsakis (Dec 06 2019 at 15:30, on Zulip):

I thnk there are two questions -- one is whether that's a useful step, and the other is whether we should kind of do a "component at a time"

nikomatsakis (Dec 06 2019 at 15:30, on Zulip):

well maybe 3

nikomatsakis (Dec 06 2019 at 15:30, on Zulip):

or rather, I tink the first question of "is it a step worth taking" is hard to answer without knowing the next steps (for the HIR map specifically) or the destination

nikomatsakis (Dec 06 2019 at 15:31, on Zulip):

I guess I'm nervous about accumulating more tech debt

nikomatsakis (Dec 06 2019 at 15:31, on Zulip):

vs trying to clean up

nikomatsakis (Dec 06 2019 at 15:31, on Zulip):

for example, when it comes to HIR, we still have (afaik) a kind of unresolved effort around the transition to HirId

eddyb (Dec 06 2019 at 15:31, on Zulip):

I expect to see something like tcx.hir(def_id) giving you a view of def_id and nothing more

nikomatsakis (Dec 06 2019 at 15:32, on Zulip):

That I think is a good thing to be shooting for

eddyb (Dec 06 2019 at 15:32, on Zulip):

with no incremental tracking inside any of the map methods on the result of thst

nikomatsakis (Dec 06 2019 at 15:32, on Zulip):

Right

eddyb (Dec 06 2019 at 15:32, on Zulip):

so I expect it to be a perf win

nikomatsakis (Dec 06 2019 at 15:32, on Zulip):

well, maybe not right

mw (Dec 06 2019 at 15:33, on Zulip):

it's unlikely that it is a win

nikomatsakis (Dec 06 2019 at 15:33, on Zulip):

I think you're saying -- we wouldn't bother to hash the results of various methods that extract bits of info from that?

eddyb (Dec 06 2019 at 15:33, on Zulip):

and we can try to move to that API independently of querification

Zoxc (Dec 06 2019 at 15:33, on Zulip):

It seems like we agreed on the end state of the HIR indexing. I don't think that end state will be hard to reach either, so I'm not too worried about the path there.

nikomatsakis (Dec 06 2019 at 15:33, on Zulip):

I guess I thikn that's a somewhat separate question, but I would imagine we can tune that

mw (Dec 06 2019 at 15:33, on Zulip):

but getting rid of lots of complicated special casing worth a bit of a regression, I think

eddyb (Dec 06 2019 at 15:33, on Zulip):

right now every method has to register a read

eddyb (Dec 06 2019 at 15:34, on Zulip):

on the DepNode that's effectively Hir(def_id)

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

It seems like we agreed on the end state of the HIR indexing. I don't think that end state will be hard to reach either, so I'm not too worried about the path there.

I am maybe a bit more worried :) not about the path, but about describing the end-state. As I said, I sort of feel like we haven't fully paid down our "tech debt" from the first dive into incremental, and I want us to be in a mode where we're decreasing the total by working towards a documented, uniform design (that we've actually written out)

eddyb (Dec 06 2019 at 15:35, on Zulip):

ideally anything like a visitor would keep a tcx.hir(def_id) around

nikomatsakis (Dec 06 2019 at 15:35, on Zulip):

yeah I thnk you're just saying that

eddyb (Dec 06 2019 at 15:35, on Zulip):

reducing N trips to the dep graph to 1

nikomatsakis (Dec 06 2019 at 15:35, on Zulip):

there are queriies that (e.g.) take a single input and do some transformation on it

nikomatsakis (Dec 06 2019 at 15:35, on Zulip):

and it's not necessarily worth even caching them

nikomatsakis (Dec 06 2019 at 15:35, on Zulip):

much less hashing their results

nikomatsakis (Dec 06 2019 at 15:35, on Zulip):

they can be considered dirty if their input is dirty

eddyb (Dec 06 2019 at 15:35, on Zulip):

not sure what you are talking about

eddyb (Dec 06 2019 at 15:36, on Zulip):

were we ever going to querify HIR map methods?

nikomatsakis (Dec 06 2019 at 15:36, on Zulip):

I don't know :) I think that's what we're talking about

eddyb (Dec 06 2019 at 15:36, on Zulip):

that is like querifying inherent methods on HIR patterns or MIR places, to me

nikomatsakis (Dec 06 2019 at 15:37, on Zulip):

I guess you are saying tcx.hir(def_id) would return something with methods itself, that are not queries

nikomatsakis (Dec 06 2019 at 15:37, on Zulip):

that extract bits of info about the HIR for that def-id

eddyb (Dec 06 2019 at 15:37, on Zulip):

yes

nikomatsakis (Dec 06 2019 at 15:37, on Zulip):

yes, ok, that's roughly equivalent to what I am talking about

eddyb (Dec 06 2019 at 15:37, on Zulip):

the data is already stored per-HIR owner/root, mostly

eddyb (Dec 06 2019 at 15:38, on Zulip):

so it could literally be a self-contained object

Zoxc (Dec 06 2019 at 15:38, on Zulip):

@mw I agree that we can take a bit of a performance regression for moving HIR indexing to queries. There's probably bug fixes to be had by doing that and possibly incremental wins in the future (by no longer creating the whole HIR map)

nikomatsakis (Dec 06 2019 at 15:38, on Zulip):

So let me float an idea: instead of moving aggressively to end-to-end queries, I could imagine focusing just on the "hir" part of this design

nikomatsakis (Dec 06 2019 at 15:38, on Zulip):

with the goal of pushing the 'incremental barrier' back over hir lowering

nikomatsakis (Dec 06 2019 at 15:38, on Zulip):

so that we don't have to lower the entire HIR

eddyb (Dec 06 2019 at 15:39, on Zulip):

as to remaining steps around HirId, I'm sorry I dropped the ball on that, I had a plan to streamline and make several things cheaper

mw (Dec 06 2019 at 15:40, on Zulip):

I think it is good to move slowly here because step opens design questions

eddyb (Dec 06 2019 at 15:40, on Zulip):

had to spend a few weeks on other things

eddyb (Dec 06 2019 at 15:40, on Zulip):

I was trying to move in the direction of an unified tcx.hir(def_id)

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

I don't think this falls on "your shoulders"

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

But I do think it'd be great to write out the design somewhat

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

I feel like even in this conversation we hit on some confusion -- e.g., the question of what should be a query etc

eddyb (Dec 06 2019 at 15:41, on Zulip):

by introducing an Item|ImplItem|TraitItem enum and uniformizing everything that has triplicate logic for each of those

eddyb (Dec 06 2019 at 15:42, on Zulip):

yeah I just mean I was going to drop a few PRs but then had to pause that work

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

(I guess that one thing I can also see is that we can't necessarily know what the design is, because it takes exploration, but I feel like we can take a stab at wrting out the "sense" we are shooting for, and then have updates when we discover parts of it that didn't work)

eddyb (Dec 06 2019 at 15:43, on Zulip):

kind of like filling in a map

pnkfelix (Dec 06 2019 at 15:43, on Zulip):

So let me float an idea: instead of moving aggressively to end-to-end queries, I could imagine focusing just on the "hir" part of this design

can we talk more about this? Or at least confirm what direction we're talking about going in ?

eddyb (Dec 06 2019 at 15:43, on Zulip):

I wish we had a platform that made it easy tbh

nikomatsakis (Dec 06 2019 at 15:43, on Zulip):

I think that'd be useful

mw (Dec 06 2019 at 15:43, on Zulip):

// at some point in this meeting I also want to discuss how to prioritize this effort with respect to other things that are already ongoing (like parallelization, the dep-graph refactoring, hir-id related refactorings, etc)

nikomatsakis (Dec 06 2019 at 15:43, on Zulip):

Yeah, so, time-check, we're at 45 minutes

Zoxc (Dec 06 2019 at 15:44, on Zulip):

I think pushing back before HIR lowering makes sense. We don't have to deal with parsing errors at that point. We would also have to hash the AST at that point. The big problem there is DefIds though. The query system wants to treat these as DefPaths, but they're not. DefId are indices to a table produced by HIR lowering, which means that query system need to use this table to convert DefIds to DefPaths. So if we move HIR lowering into a queries the query system itself will depend on queries.

pnkfelix (Dec 06 2019 at 15:44, on Zulip):

my reading of the PR that querifies HIR lowering (#59205) is that it lowers the whole HIR at once

pnkfelix (Dec 06 2019 at 15:44, on Zulip):

while the proposal of @nikomatsakis up above was to not do that. Right?

nikomatsakis (Dec 06 2019 at 15:44, on Zulip):

correct

eddyb (Dec 06 2019 at 15:44, on Zulip):

I think we need to co-evolve HirId and any new HIR map designs

mw (Dec 06 2019 at 15:45, on Zulip):

I think pushing back before HIR lowering makes sense. We don't have to deal with parsing errors at that point. We would also have to hash the AST at that point. The big problem there is DefIds though. The query system wants to treat these as DefPaths, but they're not. DefId are indices to a table produced by HIR lowering, which means that query system need to use this table to convert DefIds to DefPaths. So if we move HIR lowering into a queries the query system itself will depend on queries.

I really want to avoid making the query system itself depending on queries. that is a lot of added conceptual complexity.

eddyb (Dec 06 2019 at 15:45, on Zulip):

@Zoxc I thought DefPaths exist before lowering

mw (Dec 06 2019 at 15:45, on Zulip):

I think @Vadim Petrochenkov had ideas on how to create DefPaths already during parsing

eddyb (Dec 06 2019 at 15:45, on Zulip):

it's just that lowering also creates them

mw (Dec 06 2019 at 15:46, on Zulip):

and adding more during macro expansion

nikomatsakis (Dec 06 2019 at 15:46, on Zulip):

I don't .. quite know whta it means for the query system to depend on queries

nikomatsakis (Dec 06 2019 at 15:46, on Zulip):

But I think this seems like a point to note down as something to dig into

pnkfelix (Dec 06 2019 at 15:46, on Zulip):

I don't .. quite know whta it means for the query system to depend on queries

nor do i, but I'm hoping i wont have to know

nikomatsakis (Dec 06 2019 at 15:46, on Zulip):

(Side note: salsa has a built-in notion of "interning queries", which seems relevant, but i'm not sure it's what I would suggest for rustc, I don't love it yet)

Zoxc (Dec 06 2019 at 15:46, on Zulip):

The solution is quite simple though. "Just" make DefId interned DefPaths.

nikomatsakis (Dec 06 2019 at 15:47, on Zulip):

Yes, that is what I was going to mention

eddyb (Dec 06 2019 at 15:47, on Zulip):

they are though?

nikomatsakis (Dec 06 2019 at 15:47, on Zulip):

But I'd like to ask that we put a cap on technical "deep dive"

mw (Dec 06 2019 at 15:47, on Zulip):

The solution is quite simple though. "Just" make DefId interned DefPaths.

does that imply making the query system depend on queries itself?

nikomatsakis (Dec 06 2019 at 15:47, on Zulip):

And address the prioritization questions that mw was raising

pnkfelix (Dec 06 2019 at 15:47, on Zulip):

they are though?

maybe the point here is about how the intern-table is built ?

nikomatsakis (Dec 06 2019 at 15:47, on Zulip):

// at some point in this meeting I also want to discuss how to prioritize this effort with respect to other things that are already ongoing (like parallelization, the dep-graph refactoring, hir-id related refactorings, etc)

nikomatsakis (Dec 06 2019 at 15:48, on Zulip):

(also, I give up on the hackmd, I'm going to have to do my best to skim this meeting afterwards :)

Zoxc (Dec 06 2019 at 15:48, on Zulip):

@mw No, that would avoid that by basically making DefId and DefPath the same thing.

nikomatsakis (Dec 06 2019 at 15:48, on Zulip):

but maybe @pnkfelix or others, you have more "point of information" sort of questions on the "vague proposal" to focus on HIR?

eddyb (Dec 06 2019 at 15:48, on Zulip):

I am confused, I thought nothing assigned DefId's without constructing a DefPath

mw (Dec 06 2019 at 15:49, on Zulip):

@Zoxc that sounds like a good idea to me, generally speaking

nikomatsakis (Dec 06 2019 at 15:49, on Zulip):

I think @eddyb that @Zoxc means that a DefId would be a &'tcx DefPath

eddyb (Dec 06 2019 at 15:49, on Zulip):

it's not like a map is constructed later

nikomatsakis (Dec 06 2019 at 15:49, on Zulip):

though I could be wrong :)

eddyb (Dec 06 2019 at 15:49, on Zulip):

@nikomatsakis seems incredibly disruptive

Zoxc (Dec 06 2019 at 15:49, on Zulip):

Probably a u32 into a Vec<DefPath>

nikomatsakis (Dec 06 2019 at 15:50, on Zulip):

ok -- enough on this :) I do want to talk about prioritization

eddyb (Dec 06 2019 at 15:50, on Zulip):

but it's already that!

nikomatsakis (Dec 06 2019 at 15:50, on Zulip):

basically what we're doing now is starting already in on the idea of

nikomatsakis (Dec 06 2019 at 15:50, on Zulip):

let's try to design what HIR "ought to" look like

nikomatsakis (Dec 06 2019 at 15:50, on Zulip):

is that an effort we want to be embarking on now? how are we going to manage it, time-wise?

pnkfelix (Dec 06 2019 at 15:51, on Zulip):

If we are going to do it, maybe we can ask some of the participants here to carve out time to collaborate on a design doc?

pnkfelix (Dec 06 2019 at 15:51, on Zulip):

(And if we aren't going to do it, what does that mean about the proposed PR series?)

nikomatsakis (Dec 06 2019 at 15:51, on Zulip):

speaking personally, I really want to carve out time for chalk and for type library-ification efforts, for example, and if I had more time than that, it'd probably go into parallelization or just bug-fixing -- who is going to be the person with the time to be drviing on this designa nd building that design doc?

eddyb (Dec 06 2019 at 15:51, on Zulip):

@Zoxc there is an AST visitor in rustc::hir::map::def_collector that interns DefPath nodes to get DefIndex's

nikomatsakis (Dec 06 2019 at 15:51, on Zulip):

If we are going to do it, maybe we can ask some of the participants here to carve out time to collaborate on a design doc?

yes

nikomatsakis (Dec 06 2019 at 15:51, on Zulip):

(And if we aren't going to do it, what does that mean about the proposed PR series?)

same question if we are, right?

mw (Dec 06 2019 at 15:51, on Zulip):

from a high-level I prefer finishing as many ongoing projects as possible before starting new ones

matklad (Dec 06 2019 at 15:51, on Zulip):

I would personally loved to participate in such design, to learn how hir should look like in rust-analyzer :)

nikomatsakis (Dec 06 2019 at 15:52, on Zulip):

that was another question -- I feel like rust-analyzer is DOING this experiment

nikomatsakis (Dec 06 2019 at 15:52, on Zulip):

but without the backwards compatbility constriants and so forth

pnkfelix (Dec 06 2019 at 15:52, on Zulip):

(And if we aren't going to do it, what does that mean about the proposed PR series?)

same question if we are, right?

if we are going to redesign HIR, I would think we would likely close the PR series?

nikomatsakis (Dec 06 2019 at 15:52, on Zulip):

ok, just wanted that to be clearly stated

eddyb (Dec 06 2019 at 15:52, on Zulip):

I don't see why we wouldn't land any Zoxc PRs tbh

nikomatsakis (Dec 06 2019 at 15:53, on Zulip):

that was another question -- I feel like rust-analyzer is DOING this experiment

so like maybe a place to start is to look at rust-analyzer's design and consider trying to mock things up in that context?

pnkfelix (Dec 06 2019 at 15:53, on Zulip):

I don't see why we wouldn't land any Zoxc PRs tbh

I think the idea would be: If they are introducing complexity and aren't moving us towards the end goal, then why add that tech debt?

pnkfelix (Dec 06 2019 at 15:54, on Zulip):

but I welcome counter arguments

Vadim Petrochenkov (Dec 06 2019 at 15:54, on Zulip):

@mw

I think @Vadim Petrochenkov had ideas on how to create DefPaths already during parsing

"create DefPaths already during parsing" -> "create DefPaths for macro expansion IDs" (https://github.com/rust-lang/rust/issues/49300#issuecomment-525531109)
(Can't believe I made it to the meeting while it's still going.)

nikomatsakis (Dec 06 2019 at 15:54, on Zulip):

(slash, we haven't really even defined the end-goal yet)

mw (Dec 06 2019 at 15:54, on Zulip):

I'm against landing the PRs. They introduce technical debt and make decision that have not been discussed, like making the query system depend on queries.

pnkfelix (Dec 06 2019 at 15:54, on Zulip):

e.g. if they are moving us towards the end-goal (just maybe in a slightly round-about fashion), then we can talk about landing them in parallel with the design of HIR-next.

nikomatsakis (Dec 06 2019 at 15:55, on Zulip):

OK, 5 minutes remaining. I have a relatively hard stop today.

nikomatsakis (Dec 06 2019 at 15:55, on Zulip):

It seems like we're not at a consensus one way or the other, but maybe we can at least summarize the state of things we talked about?

nikomatsakis (Dec 06 2019 at 15:55, on Zulip):

I'm going to try to drop some notes in the hackmd

nikomatsakis (Dec 06 2019 at 15:56, on Zulip):

but I welcome counter arguments

but I think this would be a good thing to hear about

eddyb (Dec 06 2019 at 15:56, on Zulip):

I guess I can go back to the HIR owner/root stuff and try to come up with an informed plan

eddyb (Dec 06 2019 at 15:56, on Zulip):

for what the HIR's coarse-grained hierarchy could look like

pnkfelix (Dec 06 2019 at 15:56, on Zulip):

@eddyb I'd love for you and @Zoxc to resolve your debate about what interned DefId means

eddyb (Dec 06 2019 at 15:56, on Zulip):

including the map and all the tables

pnkfelix (Dec 06 2019 at 15:56, on Zulip):

not necessarily in this topic

eddyb (Dec 06 2019 at 15:58, on Zulip):

maybe @Vadim Petrochenkov can chime in on that too

pnkfelix (Dec 06 2019 at 15:59, on Zulip):

Okay well I have a hard out today too

eddyb (Dec 06 2019 at 15:59, on Zulip):

the only problem with the current setup vs &'tcx interning is ordering dependence (e.g. if you were to skip some work via incremental) but if you use an index you still have that

pnkfelix (Dec 06 2019 at 15:59, on Zulip):

and it seems like we've sort of hit the edge of the discussion for this meeting

nikomatsakis (Dec 06 2019 at 15:59, on Zulip):

here is my summary :

nikomatsakis (Dec 06 2019 at 15:59, on Zulip):
nikomatsakis (Dec 06 2019 at 16:00, on Zulip):

uh, zulip sucks at bullet lists :( :( :(

nikomatsakis (Dec 06 2019 at 16:00, on Zulip):

better to read the hackmd I guess

pnkfelix (Dec 06 2019 at 16:00, on Zulip):

Heading

Heading

nikomatsakis (Dec 06 2019 at 16:00, on Zulip):

but though I tried to be "inclusive" that is obviously colored by my understading and viewpoint

eddyb (Dec 06 2019 at 16:00, on Zulip):

Zulip just corrupted its own rendering.... how is this app so bad

nikomatsakis (Dec 06 2019 at 16:00, on Zulip):

so please feel free to add things I missed or point out "biased" language

nikomatsakis (Dec 06 2019 at 16:01, on Zulip):

uh, zulip sucks at bullet lists :( :( :(

what's most annoying is that it used to handle them well :(

pnkfelix (Dec 06 2019 at 16:01, on Zulip):

(who needs tree structured data!?!)

nikomatsakis (Dec 06 2019 at 16:02, on Zulip):

Zulip just corrupted its own rendering.... how is this app so bad

how dare you talk ill of Zulip. Join us, the kool-aid is delicious.

pnkfelix (Dec 06 2019 at 16:02, on Zulip):

okay thanks for attending everyone!

eddyb (Dec 06 2019 at 16:02, on Zulip):

@nikomatsakis btw remember my "def layer" diagrams? I might need to finally write up that proposal now :P

nikomatsakis (Dec 06 2019 at 16:03, on Zulip):

Yes, thanks all :heart:, this was (I think) productive, though I don't think we reached a final point -- I guess we can decide if we want to have a follow-up meeting and on what exact topic.

eddyb (Dec 06 2019 at 16:03, on Zulip):

but we can start with the "HIR owners" we have today and go from there

eddyb (Dec 06 2019 at 16:03, on Zulip):

/me leaves at 3% battery

Last update: Jan 21 2020 at 08:40UTC