Stream: t-compiler/wg-nll

Topic: weekly meeting 2019.02.13


pnkfelix (Feb 13 2019 at 20:30, on Zulip):

hi @WG-compiler-nll

Santiago Pastorino (Feb 13 2019 at 20:30, on Zulip):

hi @pnkfelix, hi everyone!

pnkfelix (Feb 13 2019 at 20:31, on Zulip):

as usual, here is the NLL Triage Paper

pnkfelix (Feb 13 2019 at 20:31, on Zulip):

i didn't get a chance today to do the normal pre-triage, sorry

pnkfelix (Feb 13 2019 at 20:32, on Zulip):

it appears like there are no unprioritized issues, so that is good (probably)

pnkfelix (Feb 13 2019 at 20:32, on Zulip):

that, or there are things that need A-NLL tagging

Santiago Pastorino (Feb 13 2019 at 20:33, on Zulip):

want to start being a bit more aware about what's going on in these meetings :)

Santiago Pastorino (Feb 13 2019 at 20:33, on Zulip):

is there a place where these links are explained?

pnkfelix (Feb 13 2019 at 20:33, on Zulip):

the two most immediate things on my mind are #57804 and #57895

Santiago Pastorino (Feb 13 2019 at 20:33, on Zulip):

I mean, what's each category exactly for

Santiago Pastorino (Feb 13 2019 at 20:33, on Zulip):

anyway, don't want to derail the meeting

pnkfelix (Feb 13 2019 at 20:33, on Zulip):

@Santiago Pastorino which links, the ones on the NLL Triage Paper ?

Santiago Pastorino (Feb 13 2019 at 20:34, on Zulip):

sorry I meant, the categories

Santiago Pastorino (Feb 13 2019 at 20:34, on Zulip):

what each one means

Santiago Pastorino (Feb 13 2019 at 20:34, on Zulip):

P-High is obvious :)

pnkfelix (Feb 13 2019 at 20:34, on Zulip):

so you mean NLL-complete, NLL-sound, NLL-diagnostics ?

pnkfelix (Feb 13 2019 at 20:35, on Zulip):

oh you mean all the labels in rust-lang/rust ?

Santiago Pastorino (Feb 13 2019 at 20:35, on Zulip):

yeah a lot are obvious

Santiago Pastorino (Feb 13 2019 at 20:35, on Zulip):

no all

Santiago Pastorino (Feb 13 2019 at 20:35, on Zulip):

ours

pnkfelix (Feb 13 2019 at 20:35, on Zulip):

well

pnkfelix (Feb 13 2019 at 20:35, on Zulip):

heh, "ours"

Santiago Pastorino (Feb 13 2019 at 20:35, on Zulip):

hehe, nll :P

Santiago Pastorino (Feb 13 2019 at 20:35, on Zulip):

NLL-complete unsure what means

pnkfelix (Feb 13 2019 at 20:35, on Zulip):

many are shared between teams and I get the impression that some have different semantics

pnkfelix (Feb 13 2019 at 20:35, on Zulip):

depending on which team is looking at it

Santiago Pastorino (Feb 13 2019 at 20:35, on Zulip):

a lot are self-explanatory

Santiago Pastorino (Feb 13 2019 at 20:35, on Zulip):

anyway don't worry I guess I can ask specifically when something shows up

Santiago Pastorino (Feb 13 2019 at 20:36, on Zulip):

don't want to derail the meeting, sorry

pnkfelix (Feb 13 2019 at 20:36, on Zulip):

No its not a problem

pnkfelix (Feb 13 2019 at 20:36, on Zulip):

I figure if one person has the drive to ask the question, then other people probably have the same Quesiton

pnkfelix (Feb 13 2019 at 20:37, on Zulip):

NLL-complete is meant to collect bugs around examples of code that is meant to be accepted by NLL. Usually such bugs are either ICE'ing or being erroneously rejected by NLL

pnkfelix (Feb 13 2019 at 20:37, on Zulip):

NLL-sound is meant to collect bugs around examples of code that is meant to be rejected by NLL. Usually such bugs are either ICE'ing or being erroneously accepted by NLL.

lqd (Feb 13 2019 at 20:37, on Zulip):

(IIRC there's a tiny bit of explanation on the GH tags, eg "valid code works", "invalid code doesn't work")

pnkfelix (Feb 13 2019 at 20:37, on Zulip):

NLL-sound things tend to be higher priority than NLL-complete things, at least at the moment.

pnkfelix (Feb 13 2019 at 20:38, on Zulip):

NLL-diagnostics is for cases where the diagnostics emitted by NLL specifcally needs improvement. Usually it is/was used for cases where NLL is a regresion w.r.t diagnostics when compared to AST-borrowck

pnkfelix (Feb 13 2019 at 20:38, on Zulip):

(but at this point its really more of a catch-all for any diagnostic issue originating from the NLL code base)

Santiago Pastorino (Feb 13 2019 at 20:38, on Zulip):

(IIRC there's a tiny bit of explanation on the GH tags, eg "valid code works", "invalid code doesn't work")

oh that's cool

Santiago Pastorino (Feb 13 2019 at 20:39, on Zulip):

maybe given that Felix took the time to explain some we can add better description to the ones he explained

pnkfelix (Feb 13 2019 at 20:39, on Zulip):

NLL-polonius is bugs related to the Polinus subproject

Santiago Pastorino (Feb 13 2019 at 20:39, on Zulip):

unsure if I have the rights to do so

Santiago Pastorino (Feb 13 2019 at 20:39, on Zulip):

can try

lqd (Feb 13 2019 at 20:39, on Zulip):

I think we do have rights yeah

Santiago Pastorino (Feb 13 2019 at 20:39, on Zulip):

https://github.com/rust-lang/rust/labels

pnkfelix (Feb 13 2019 at 20:39, on Zulip):

NLL-performant is cases where NLL is causing slow slow slow compile times

Matthew Jasper (Feb 13 2019 at 20:40, on Zulip):

NLL-polonius usually means NLL-complete but fixed by polonius

pnkfelix (Feb 13 2019 at 20:40, on Zulip):

NLL-fixed-by-NLL is for bugs that are problems solely with the AST-borrowck -- they are bugs that we intend to close once everyone migrates over to NLL

Matthew Jasper (Feb 13 2019 at 20:40, on Zulip):

for now

Santiago Pastorino (Feb 13 2019 at 20:40, on Zulip):

shoud I override with Felix explanations?

pnkfelix (Feb 13 2019 at 20:41, on Zulip):

I dunno, sometimes my explanations are wordy

lqd (Feb 13 2019 at 20:41, on Zulip):

or at least in the Paper doc

pnkfelix (Feb 13 2019 at 20:41, on Zulip):

paper doc would be fine I think

pnkfelix (Feb 13 2019 at 20:41, on Zulip):

Oh there's some NLL-reference label that I'm not familiar with

pnkfelix (Feb 13 2019 at 20:42, on Zulip):

I would guess that's about ongoing work to specify/document NLL

pnkfelix (Feb 13 2019 at 20:42, on Zulip):

yeah, its about bugs like "two-phase borrows need a spec" (#46901)

pnkfelix (Feb 13 2019 at 20:42, on Zulip):

I think that's all of them

pnkfelix (Feb 13 2019 at 20:43, on Zulip):

anyway, I was saying that my most immediate concerns/interests are about migration, both of the 2015-edition to use NLL=migrate (#57804), and of the complete transition from migrate to full NLL (#57895)

pnkfelix (Feb 13 2019 at 20:43, on Zulip):

@Matthew Jasper , can you summarize where we are at w.r.t. #57804 ?

pnkfelix (Feb 13 2019 at 20:44, on Zulip):

(I literally ask because I'm assuming its more on the tip of your tongue than it is on my own)

pnkfelix (Feb 13 2019 at 20:44, on Zulip):

Note that not everyone was at the All-Hands last week

pnkfelix (Feb 13 2019 at 20:44, on Zulip):

...

pnkfelix (Feb 13 2019 at 20:44, on Zulip):

oh

pnkfelix (Feb 13 2019 at 20:44, on Zulip):

hey everyone, there was an all hands last week

lqd (Feb 13 2019 at 20:45, on Zulip):

there was an NLL meeting ? or maybe was it for 2PB ?

Matthew Jasper (Feb 13 2019 at 20:46, on Zulip):

The issue is pretty much up to date. We're waiting on #58347 being merged, #57202 being reviewed (I'm not sure if @nikomatsakis would rather have someone else review it) and finally we need to decide on two-phase borrows. #57609 (which is a prerequisite is) also ready for review and currently assigned to Niko.

pnkfelix (Feb 13 2019 at 20:46, on Zulip):

there were a couple meetings that tied into with NLL

pnkfelix (Feb 13 2019 at 20:46, on Zulip):

here is the notes for NLL: Migration and Retrospective

lqd (Feb 13 2019 at 20:47, on Zulip):

thanks for the link

pnkfelix (Feb 13 2019 at 20:47, on Zulip):

Okay. I know niko is trying to reduce his reviewing work load

pnkfelix (Feb 13 2019 at 20:48, on Zulip):

so let me check in with him about whether he wants me to take over on those two PR's.

pnkfelix (Feb 13 2019 at 20:48, on Zulip):

I've already looked a bit at #57609 and could probably go over it more carefully without too much trouble.

pnkfelix (Feb 13 2019 at 20:49, on Zulip):

(the other meeting from last week's All-Hands that was potentially relevant was RalfJung's Stacked Borrows meeting ... but I don't think there was that much there that we didn't already "know" or at least were informed of within our team...)

pnkfelix (Feb 13 2019 at 20:50, on Zulip):

Okay, so beyond the work for the 2015 edition

pnkfelix (Feb 13 2019 at 20:50, on Zulip):

are there other burning issues that we should talk about now? The performance bug maybe #58178 ?

pnkfelix (Feb 13 2019 at 20:51, on Zulip):

I know @Matthew Jasper has already done work to help reduce the performance impact for that test case

Matthew Jasper (Feb 13 2019 at 20:52, on Zulip):

#58347 gets the performance to an acceptable point. But I would like for it to be run on perf.rlo once that is merged, and I think that we should at least check where the rest of the slowness of NLL is coming from.

pnkfelix (Feb 13 2019 at 20:52, on Zulip):

I guess since @Matthew Jasper self-assigned it, they are planning to own it for the time being? Matthew, You should feel free to ask others to dive in once your PR #58347 lands, or even unassign yourself at that point.

lqd (Feb 13 2019 at 20:52, on Zulip):

it's probably a bit late but we could try+rust-timer it (but our current benchmarks probably don't exercize the perf problem that much)

pnkfelix (Feb 13 2019 at 20:53, on Zulip):

what I was wondering about

pnkfelix (Feb 13 2019 at 20:53, on Zulip):

the info we are building there, is it solely for making a nice diagnostic?

pnkfelix (Feb 13 2019 at 20:54, on Zulip):

or is that just an artifact of the tooling reports, and that something else nearby would get blamed if we managed to build that particular diagnostic in a more lazy fashion?

Jake Goulding (Feb 13 2019 at 20:54, on Zulip):

other [...] issues that we should talk about

In Stack Overflow land, there have been a few "NLL-solved-by-polonius" questions recently, so I'm every hopeful for work there to proceed.

pnkfelix (Feb 13 2019 at 20:54, on Zulip):

(I'm specifcally talking about find_outlives_blame_span here, since that came up in the discussion)

lqd (Feb 13 2019 at 20:56, on Zulip):

it seems it's used for propagating outlives constraints in non-diagnostics code but the function itself is usually for diagnostics ?

Matthew Jasper (Feb 13 2019 at 20:56, on Zulip):

find_outlives_blame_span is just for diagnostics, and it should be calculated lazily. But we throw away the information needed to compute it once we finish borrow checking the closure, and don't know whether it's needed until we borrow check the containing function.

pnkfelix (Feb 13 2019 at 20:57, on Zulip):

In Stack Overflow land, there have been a few "NLL-solved-by-polonius" questions recently, so I'm every hopeful for work there to proceed.

Regarding Polonius, my understanding is we are going to try fork off the Polonius work separately. Basically, I want to tie a bow on the current NLL system and move on to a different project, but certainly others are working on Polonius and I believe @nikomatsakis intends to either steer that ship themself or find someone else to pilot it in. Its our current best hope for getting NLL to its idealized state.

pnkfelix (Feb 13 2019 at 20:58, on Zulip):

But we throw away the information needed to compute it once we finish borrow checking the closure

Ah I see, I didn't know this.

pnkfelix (Feb 13 2019 at 20:58, on Zulip):

Back in the day @nikomatsakis and I had spoke of trying to have some dataflow passes run lazily

pnkfelix (Feb 13 2019 at 20:59, on Zulip):

i.e. you'd use a coarse dataflow for the soundness checks, and then run a more precise one after you got an error to get more specific info about which moves caused the problem

pnkfelix (Feb 13 2019 at 21:00, on Zulip):

I would think such an architecture could be better suited for addressing this problem. But I'm guessing that alone might not suffice

pnkfelix (Feb 13 2019 at 21:01, on Zulip):

okay well it sounds like we'll just look to gather more info about #58178 once PR #58347 lands.

Matthew Jasper (Feb 13 2019 at 21:01, on Zulip):

Lazier diagnostics are certainly something we can try to do. It's a pain in this case because the MIR that's used for borrow checking is consumed by the optimization passes.

lqd (Feb 13 2019 at 21:02, on Zulip):

@pnkfelix in order to not annoy niko, I'd love a bit of guidance on #57374 if you happen to have a spare moment next week (that is, it's looking like a similar case of "some information present earlier might not be available here anymore" like the previous issue we talked about)

pnkfelix (Feb 13 2019 at 21:02, on Zulip):

well that's 30 minute and I've once again managed to monopolize all of the time

pnkfelix (Feb 13 2019 at 21:03, on Zulip):

@lqd sure I will try to carve out some time for that. Don't be afraid to ping me, my schedule is not as constrained as niko's w.r.t. meetings and what not.

lqd (Feb 13 2019 at 21:03, on Zulip):

sweet, thanks, and will do

pnkfelix (Feb 13 2019 at 21:04, on Zulip):

One topic we may want to talk about next week is the meta-question of how this meeting is run

pnkfelix (Feb 13 2019 at 21:04, on Zulip):

There were notes in the retrospective paper and I haven't reviewed them (I was writing them on the whiteboard at the time)

pnkfelix (Feb 13 2019 at 21:05, on Zulip):

but the point is that the value of these triage meetings is at best unclear

pnkfelix (Feb 13 2019 at 21:05, on Zulip):

I would prefer to either 1. figure out how to make them valuable, or 2. figure out how to not have them at all.

lqd (Feb 13 2019 at 21:05, on Zulip):

oh interesting

pnkfelix (Feb 13 2019 at 21:05, on Zulip):

e..g we could make them more like an office hour, for example, where anyone can just ask Q's.

pnkfelix (Feb 13 2019 at 21:05, on Zulip):

or talk

pnkfelix (Feb 13 2019 at 21:06, on Zulip):

where the intention is more that we just are agreeing to be in one place at once to have a coding jam session

pnkfelix (Feb 13 2019 at 21:07, on Zulip):

anyway that is food for thought for next week. In fact i will put it on next weeks' agenda right now.

lqd (Feb 13 2019 at 21:08, on Zulip):

did we want to talk about other topics or are we done ?

lqd (Feb 13 2019 at 21:09, on Zulip):

guessing the latter, and if so, thanks everyone :) :wave:

pnkfelix (Feb 13 2019 at 21:14, on Zulip):

oh yeah, sorry, bye all!

Santiago Pastorino (Feb 15 2019 at 22:17, on Zulip):

have added @pnkfelix label explanations to the paper doc

Last update: Nov 21 2019 at 13:15UTC