Stream: t-compiler/wg-nll

Topic: weekly meeting May 29


pnkfelix (May 29 2018 at 19:30, on Zulip):

hello everyone!

pnkfelix (May 29 2018 at 19:30, on Zulip):

I don't know about the situation where each of you are, but there is a pretty heavy thunderstorm here in Paris. :)

Santiago Pastorino (May 29 2018 at 19:30, on Zulip):

hi everyone!!!

nikomatsakis (May 29 2018 at 19:32, on Zulip):

o/

pnkfelix (May 29 2018 at 19:33, on Zulip):

so lets see: As you probably know, we just finished up the RustFest impl Days here in Paris

nikomatsakis (May 29 2018 at 19:33, on Zulip):

I'm not sure whether a happy or sad emoji is more appropriate

pnkfelix (May 29 2018 at 19:33, on Zulip):

I was not following along with the Polonius progress of the group there doing that as closely as I would have liked.

pnkfelix (May 29 2018 at 19:33, on Zulip):

so is there anyone present right now who was part of that effort?

nikomatsakis (May 29 2018 at 19:34, on Zulip):

well there is at least a graphviz PR: https://github.com/rust-lang-nursery/polonius/pull/63

pnkfelix (May 29 2018 at 19:34, on Zulip):

I did tell the people there about the meeting tonight. In hindsight, I probably should have tried to get some peoples emails (to invite them to the meeting formally). But a number of them are/were logged into Zulip, so I figured it was worth a shot to ask...

Vytautas Astrauskas (May 29 2018 at 19:35, on Zulip):

so is there anyone present right now who was part of that effort?

I am. But on the very shaky internet connection.

Vytautas Astrauskas (May 29 2018 at 19:36, on Zulip):

Maybe it is worth pinging @everyone ?

pnkfelix (May 29 2018 at 19:36, on Zulip):

Oh @everyone that is a very good idea.

pnkfelix (May 29 2018 at 19:37, on Zulip):

In the meantime: @Vytautas Astrauskas would you be interested in trying to summarize the outcome (or intermediate state) of the various efforts that went on there? Niko's already pointed out the graphviz PR

pnkfelix (May 29 2018 at 19:37, on Zulip):

If you go silent for too long, we'll just assume that you've lost connectivity. :)

nikomatsakis (May 29 2018 at 19:37, on Zulip):

I know there were also some investigations into "compressing the CFG" though I think it didn't really yet yield actionable fruit

Santiago Pastorino (May 29 2018 at 19:38, on Zulip):

Rustc is using AllFacts and Output from polonius-engine

nikomatsakis (May 29 2018 at 19:39, on Zulip):

this is indeed very exciting!

nikomatsakis (May 29 2018 at 19:39, on Zulip):

did that PR land?

Santiago Pastorino (May 29 2018 at 19:39, on Zulip):

there's the compare-mode=polonius, PR not merged yet

Santiago Pastorino (May 29 2018 at 19:39, on Zulip):

yes, it did

nikomatsakis (May 29 2018 at 19:39, on Zulip):

(one thing we noticed with that PR was there are some tests failing)

pnkfelix (May 29 2018 at 19:39, on Zulip):

@Santiago Pastorino that's great. Has the use of AllFacts + Output given us any interesting feedback about whether/where the polonius system is incorrect

pnkfelix (May 29 2018 at 19:39, on Zulip):

?

nikomatsakis (May 29 2018 at 19:39, on Zulip):

it is :)

pnkfelix (May 29 2018 at 19:39, on Zulip):

perhaps the "some tests failing" is that

nikomatsakis (May 29 2018 at 19:40, on Zulip):

so that will take some investigation

Santiago Pastorino (May 29 2018 at 19:40, on Zulip):

yesterday I've pasted a huge output

nikomatsakis (May 29 2018 at 19:40, on Zulip):

the errors looked like errors I had seen before

Santiago Pastorino (May 29 2018 at 19:40, on Zulip):

let me try to find it again

pnkfelix (May 29 2018 at 19:40, on Zulip):

That actually gives me some comfort

nikomatsakis (May 29 2018 at 19:40, on Zulip):

but I didn't take time to investigate deeply

pnkfelix (May 29 2018 at 19:40, on Zulip):

with something like this

pnkfelix (May 29 2018 at 19:40, on Zulip):

if it works right out of the box

pnkfelix (May 29 2018 at 19:40, on Zulip):

when its a big huge change

pnkfelix (May 29 2018 at 19:40, on Zulip):

my immediate suspicion is "that isn't really integrated..."

pnkfelix (May 29 2018 at 19:40, on Zulip):

:)

pnkfelix (May 29 2018 at 19:41, on Zulip):

Okay so that makes me pretty happy

Santiago Pastorino (May 29 2018 at 19:41, on Zulip):

https://gist.github.com/spastorino/ed32ad31bb3f094aa86d103f5d9cc507

pnkfelix (May 29 2018 at 19:42, on Zulip):

that .. could be much much worse!

nikomatsakis (May 29 2018 at 19:42, on Zulip):

so — in terms of the upcoming week — i guess that as far as polonius goes, isolating some of those failures is an obvious "to do" item

nikomatsakis (May 29 2018 at 19:42, on Zulip):

I believe many of them have a common cause, as I said; it's a set of failures I saw before

pnkfelix (May 29 2018 at 19:43, on Zulip):

I assume that the people who were doing integration are the obvious people to spearhead investigation there

pnkfelix (May 29 2018 at 19:43, on Zulip):

does that sound correct to others?

nikomatsakis (May 29 2018 at 19:43, on Zulip):

could be, doesn't have to be

pnkfelix (May 29 2018 at 19:43, on Zulip):

this was joint effort between @Santiago Pastorino and @qmx , right?

nikomatsakis (May 29 2018 at 19:43, on Zulip):

my feeling is that overall the highest priority thing is probably still to improve the rustc diagnostics

nikomatsakis (May 29 2018 at 19:44, on Zulip):

(as we said this morning)

pnkfelix (May 29 2018 at 19:44, on Zulip):

(I suppose I could just go look at the listed of landed PR's)

pnkfelix (May 29 2018 at 19:44, on Zulip):

so yeah, okay, so lets talk about that, and about prioriization in general

pnkfelix (May 29 2018 at 19:44, on Zulip):

So @nikomatsakis and @pnkfelix are obvious very excited about Polonius integration

pnkfelix (May 29 2018 at 19:45, on Zulip):

but at the same time, we cannot depend on that actually working soon enough for the timeline that we have in mind for deploying NLL

pnkfelix (May 29 2018 at 19:45, on Zulip):

so the plan of record was and continues to be: We want to initially deploy using the current mir-borrowck NLL code. It won't be as precise an analysis as we want. But it will fix a lot of bugs

pnkfelix (May 29 2018 at 19:46, on Zulip):

and such a deploying will be a good starting point for finding out cases where people were depending on the existing unsoundness/weakness in the AST borrow-checker.

pnkfelix (May 29 2018 at 19:46, on Zulip):

Thus, we've got this priority scheme for how to address issues

Santiago Pastorino (May 29 2018 at 19:47, on Zulip):

so the plan of record was and continues to be: We want to initially deploy using the current mir-borrowck NLL code. It won't be as precise an analysis as we want. But it will fix a lot of bugs

when you say deploy, what do you refer to exactly?

pnkfelix (May 29 2018 at 19:47, on Zulip):

@Santiago Pastorino good question

Santiago Pastorino (May 29 2018 at 19:47, on Zulip):

remove the feature flag and be the default thing?

Santiago Pastorino (May 29 2018 at 19:47, on Zulip):

is this for 2018 edition?

pnkfelix (May 29 2018 at 19:47, on Zulip):

@Santiago Pastorino that's close to the idea

nikomatsakis (May 29 2018 at 19:47, on Zulip):

no

nikomatsakis (May 29 2018 at 19:47, on Zulip):

or, specifically I meant: no this is not specific to the edition

nikomatsakis (May 29 2018 at 19:48, on Zulip):

(that is, whatever we do would hopefully apply to all code)

pnkfelix (May 29 2018 at 19:48, on Zulip):

@Santiago Pastorino To be clear, our plan is not just to turn on #![feature(nll)] by default and hope for the best

Santiago Pastorino (May 29 2018 at 19:48, on Zulip):

yeah, it makes sense to no be specific to edition because working code will continue working

nikomatsakis (May 29 2018 at 19:49, on Zulip):

/me has no desire to maintain two borrow checkers :)

pnkfelix (May 29 2018 at 19:49, on Zulip):

The deployment plan, at least as I understand it

pnkfelix (May 29 2018 at 19:49, on Zulip):

(again Niko may have revised his attitude about this idea, maybe)

pnkfelix (May 29 2018 at 19:49, on Zulip):

is/was to initially keep AST-borrowck as well as MIR-borrowck

pnkfelix (May 29 2018 at 19:49, on Zulip):

(not forever and ever)

pnkfelix (May 29 2018 at 19:50, on Zulip):

we'd get rid of #![feature(nll)]

pnkfelix (May 29 2018 at 19:50, on Zulip):

instead, we'd run both AST-borrowck and MIR-borrowck.

pnkfelix (May 29 2018 at 19:50, on Zulip):

If MIR-borrowck accepts your code, then your code is accepted.

Santiago Pastorino (May 29 2018 at 19:50, on Zulip):

I'd say if one borrowck accepts the code is accepted, no?

pnkfelix (May 29 2018 at 19:50, on Zulip):

If MIR-borrowck rejects your code, then we consult the output of AST-borrowck. If AST-borrowck accepts it, then we issue a warning

pnkfelix (May 29 2018 at 19:50, on Zulip):

Well, not quite

Santiago Pastorino (May 29 2018 at 19:50, on Zulip):

if AST-borrowck accepts and MIR-borrowck rejects I'd accept the code and file an issue to rustc :P

pnkfelix (May 29 2018 at 19:51, on Zulip):

We want to warn someone that their code will be rejected in the future

nikomatsakis (May 29 2018 at 19:51, on Zulip):

hmm that's not qutie whatI had in mind

pnkfelix (May 29 2018 at 19:51, on Zulip):

when we eventually turn off AST-borrowck and rely solely on MIR-borrowck (or some variant implementation of NLL)

nikomatsakis (May 29 2018 at 19:51, on Zulip):

I had in mind "run the AST checker — if it reports no errors, run MIR borrowck"

pnkfelix (May 29 2018 at 19:51, on Zulip):

Ah, see, this is why its good to review these things

Santiago Pastorino (May 29 2018 at 19:51, on Zulip):

but are there cases where that happens not being a bug?

nikomatsakis (May 29 2018 at 19:51, on Zulip):

this means you don't enjoy the (full) benefits of NLL though, just see warnings about the bugs we're gonna fix

nikomatsakis (May 29 2018 at 19:52, on Zulip):

the @pnkfelix plan also makes sense, modulo some complications around region inference

pnkfelix (May 29 2018 at 19:52, on Zulip):

My plan is documented at: https://github.com/rust-lang/rust/issues/46908

nikomatsakis (May 29 2018 at 19:52, on Zulip):

(that is, there are some errors reported in today's regionck that NLL would ultimately accept, and I'm not sure how best to deal with that)

pnkfelix (May 29 2018 at 19:53, on Zulip):

@nikomatsakis I want to try to clarify whether you are talking about a difference in implementation strategy, or a difference in user experience

nikomatsakis (May 29 2018 at 19:53, on Zulip):

I guess I didn't read that issue carefully enough :)

pnkfelix (May 29 2018 at 19:53, on Zulip):

the issue I linked to shows the "truth table" of what results I expect from each combination of runs

nikomatsakis (May 29 2018 at 19:53, on Zulip):

different in implementation strategy, or a difference in user experience

both? :)

nikomatsakis (May 29 2018 at 19:54, on Zulip):

in particular, if we just run the AST first, and run MIR only when it succeeds, then this case operates differently:

If AST-borrowck rejects the code and MIR-borrowck accepts, then accept. (Indeed, this is the point of NLL, to start accepting a broader swath of code.)

nikomatsakis (May 29 2018 at 19:54, on Zulip):

but it's very easy to do :)

pnkfelix (May 29 2018 at 19:54, on Zulip):

Okay then I am indeed confused

nikomatsakis (May 29 2018 at 19:54, on Zulip):

tbh I hadn't really thought about the alternative you are proposing here, it's not the usual way we do things

nikomatsakis (May 29 2018 at 19:54, on Zulip):

but I see the advantage

pnkfelix (May 29 2018 at 19:55, on Zulip):

because I had thought that part of the idea of the deployment was to let us advertise the advantage of NLL very soon

nikomatsakis (May 29 2018 at 19:55, on Zulip):

usually we run the old code (which has bugs); if it errors, great. If not, we run the new, stricter check. If it errors, we issue a warning.

pnkfelix (May 29 2018 at 19:55, on Zulip):

/me had thought that we had actually gone over the options in this truth table pretty carefully in some 1:1

nikomatsakis (May 29 2018 at 19:55, on Zulip):

well, specifically I wanted us to hvae two-phase borrows

nikomatsakis (May 29 2018 at 19:55, on Zulip):

so as to mitigate the impact

nikomatsakis (May 29 2018 at 19:55, on Zulip):

that is, if there is an unsoundness that would ultimately be accepted because NLL, you still don't get an error

nikomatsakis (May 29 2018 at 19:56, on Zulip):

but you don't get to use NLL otherwise (this is the downside of the approach)

pnkfelix (May 29 2018 at 19:56, on Zulip):

that is, if there is an unsoundness that would ultimately be accepted because NLL, you still don't get an error

I don't understand the scenario you outline here

pnkfelix (May 29 2018 at 19:56, on Zulip):

are you assuming there is some bug in NLL in that scenario?

nikomatsakis (May 29 2018 at 19:56, on Zulip):

to repeat though I'm not saying what I had in mind is better :) it's just the usual way we've done these sorts of transitions. But in those cases, I suspect the new analysis was always strictly stricter (that is, it only produced new errors)

nikomatsakis (May 29 2018 at 19:57, on Zulip):

are you assuming there is some bug in NLL in that scenario?

no, I'm not

nikomatsakis (May 29 2018 at 19:57, on Zulip):

I can give you a real example but I'll give you a fake one first

nikomatsakis (May 29 2018 at 19:57, on Zulip):

let's say you had

pnkfelix (May 29 2018 at 19:57, on Zulip):

then what do you mean "if there is an unsoundness that would ultimately be accepted because NLL, you still don't get an error"

nikomatsakis (May 29 2018 at 19:58, on Zulip):
{
  let mut x;
  let p = &x;
  use(p); // last use of `p`

  ignored_write(&mut x); // for some reason, AST borrowck ignores this write
}
nikomatsakis (May 29 2018 at 19:58, on Zulip):

under lexical borrowck, that should be an error — but the AST-based borrowck is not reporting it

nikomatsakis (May 29 2018 at 19:58, on Zulip):

under NLL, we no longer ignore the "ignored write", but otoh the borrow ends at use(p), so no future-compat warning is issued

nikomatsakis (May 29 2018 at 19:59, on Zulip):

I remember that there was a specific case where 2-phase borrows helped a lot in this way

pnkfelix (May 29 2018 at 19:59, on Zulip):

I'm sorry I still keep needing clarification

pnkfelix (May 29 2018 at 19:59, on Zulip):

"We're not reporting it"

pnkfelix (May 29 2018 at 20:00, on Zulip):

you mean today, without NLL?

nikomatsakis (May 29 2018 at 20:00, on Zulip):

rephrased slightly: "under lexical borrowck, that should be an error — but the AST-based borrowck is not reporting it"

pnkfelix (May 29 2018 at 20:00, on Zulip):

So then that would fall into the category of "AST-borrowck accepts + MIR-borrowck accepts ... " .... ?

Santiago Pastorino (May 29 2018 at 20:00, on Zulip):

I am surprised that this is not reported by AST-based

nikomatsakis (May 29 2018 at 20:00, on Zulip):

@Santiago Pastorino it is this is a hypothetical example

pnkfelix (May 29 2018 at 20:00, on Zulip):

/me is feeling like he must be missing something really deep here

Santiago Pastorino (May 29 2018 at 20:01, on Zulip):

ahh ok ok

nikomatsakis (May 29 2018 at 20:01, on Zulip):

So then that would fall into the category of "AST-borrowck accepts + MIR-borrowck accepts ... " .... ?

yes

pnkfelix (May 29 2018 at 20:01, on Zulip):

...... which is handled the same way in either deployment strategy under discussion, surely ... ?

nikomatsakis (May 29 2018 at 20:03, on Zulip):

so there are two ways to do this:

nikomatsakis (May 29 2018 at 20:04, on Zulip):

@pnkfelix does that sound correct? (or at least equivalent)

nikomatsakis (May 29 2018 at 20:04, on Zulip):

I see pros/cons to the "felix plan"

pnkfelix (May 29 2018 at 20:04, on Zulip):

There's a reason I tried to present this as a truth table rather than an algorithm...

nikomatsakis (May 29 2018 at 20:04, on Zulip):

ok, hold up :)

pnkfelix (May 29 2018 at 20:05, on Zulip):

(I understand that the issue I linked did mix in algorithmic details about e.g. cancelling errors)

nikomatsakis (May 29 2018 at 20:06, on Zulip):

truth table:

borrowck=compare plan:

MIR got no errors MIR got errors
AST got no errors no error reported future-compat warnings reported
AST got errors no error reported AST errors reported
pnkfelix (May 29 2018 at 20:06, on Zulip):

Ah okay

nikomatsakis (May 29 2018 at 20:06, on Zulip):

plan Niko was expecting:

MIR got no errors MIR got errors
AST got no errors no error reported future-compat warnings reported
AST got errors AST errors reported AST errors reported
pnkfelix (May 29 2018 at 20:06, on Zulip):

so that is focusing on user experience

pnkfelix (May 29 2018 at 20:06, on Zulip):

note this comment in the issue I linked: https://github.com/rust-lang/rust/issues/46908#issuecomment-353359157

nikomatsakis (May 29 2018 at 20:07, on Zulip):

I see pros/cons for user experience

nikomatsakis (May 29 2018 at 20:07, on Zulip):

pro: you experience NLL faster

pnkfelix (May 29 2018 at 20:07, on Zulip):

so in fact I think there's a third table that was my intention

nikomatsakis (May 29 2018 at 20:07, on Zulip):

con: there is some "unevenness" in the errors

pnkfelix (May 29 2018 at 20:07, on Zulip):

(or at least my most recent intention)

nikomatsakis (May 29 2018 at 20:07, on Zulip):

I see

pnkfelix (May 29 2018 at 20:07, on Zulip):

Hmm I don't think I know how to create a table here. :)

nikomatsakis (May 29 2018 at 20:07, on Zulip):

truth table:

borrowck=compare plan:

MIR got no errors MIR got errors
AST got no errors no error reported future-compat warnings reported
AST got errors no error reported MIR errors reported
pnkfelix (May 29 2018 at 20:08, on Zulip):

Yes, that looks like what I wanted

nikomatsakis (May 29 2018 at 20:08, on Zulip):

I think that does resolve some of my concerns

pnkfelix (May 29 2018 at 20:08, on Zulip):

(deleted)

nikomatsakis (May 29 2018 at 20:08, on Zulip):

in particular, we only ever show the user mir-based errors

nikomatsakis (May 29 2018 at 20:08, on Zulip):

however, it ups the ante on getting borrowck error quality improved :)

pnkfelix (May 29 2018 at 20:08, on Zulip):

yes

pnkfelix (May 29 2018 at 20:08, on Zulip):

which perhaps segues nicely into the priority list i had mentioned earlier. :) :) :)

nikomatsakis (May 29 2018 at 20:08, on Zulip):

ok, I'm on board with the 3rd plan :) though there is still the complication of regionck errors

nikomatsakis (May 29 2018 at 20:09, on Zulip):

but yes, carry on :)

pnkfelix (May 29 2018 at 20:09, on Zulip):

Okay... so

pnkfelix (May 29 2018 at 20:09, on Zulip):

Clearly the question of how to actually deploy hasn't been hammered out

pnkfelix (May 29 2018 at 20:09, on Zulip):

:)

pnkfelix (May 29 2018 at 20:09, on Zulip):

But you can all see how there are a lot of options with various tradeoffs

nikomatsakis (May 29 2018 at 20:09, on Zulip):

probably we didn't need to get into the weeds on that, but I'm glad we sorted it out :)

pnkfelix (May 29 2018 at 20:10, on Zulip):

The main thing is, we would like to turn on NLL in some fashion

pnkfelix (May 29 2018 at 20:10, on Zulip):

I personally had been thinking of it as something we want to do in time for the 2018 edition

pnkfelix (May 29 2018 at 20:10, on Zulip):

it would still be applied to the 2015 edition

pnkfelix (May 29 2018 at 20:10, on Zulip):

(I assume/hope)

pnkfelix (May 29 2018 at 20:10, on Zulip):

but in terms of marketing push

pnkfelix (May 29 2018 at 20:10, on Zulip):

and/or getting people to deal with writing their code to conform to the rules imposed by the NLL system

pnkfelix (May 29 2018 at 20:11, on Zulip):

(namely, there are soundness fixes, especially around match, that we are deploying as part of NLL)

pnkfelix (May 29 2018 at 20:11, on Zulip):

it just seemed to me like a good idea if we could get something out the door

nikomatsakis (May 29 2018 at 20:11, on Zulip):

(I'm gonna have to drop off soon)

pnkfelix (May 29 2018 at 20:11, on Zulip):

If it turns out that we cannot get anything ready in time, that's not the end of the world

pnkfelix (May 29 2018 at 20:12, on Zulip):

NLL could hypothetically be deployed in a future version of rustc (I think); it doesn't have to be released as part of the 2018 edition

nikomatsakis (May 29 2018 at 20:12, on Zulip):

(I would say though @pnkfelix that going with MIR errors as the things we display means though that getting all the suggetions right and so forth is higher in priority than I thought)

nikomatsakis (May 29 2018 at 20:12, on Zulip):

NLL could hypothetically be deployed in a future version of rustc (I think); it doesn't have to be released as part of the 2018 edition

well, true, but we should not think this way :)

pnkfelix (May 29 2018 at 20:12, on Zulip):

Yes of course

pnkfelix (May 29 2018 at 20:13, on Zulip):

I'm just trying to say that the work here wouldn't block the 2018 edition.

pnkfelix (May 29 2018 at 20:13, on Zulip):

I assume you agree with that?

nikomatsakis (May 29 2018 at 20:13, on Zulip):

I do not

pnkfelix (May 29 2018 at 20:13, on Zulip):

Okay

nikomatsakis (May 29 2018 at 20:13, on Zulip):

I mean I think it is true in a technical sense

pnkfelix (May 29 2018 at 20:13, on Zulip):

that's a topic you and I can chat about later

nikomatsakis (May 29 2018 at 20:13, on Zulip):

I just think that NLL is major feature

pnkfelix (May 29 2018 at 20:13, on Zulip):

:)

nikomatsakis (May 29 2018 at 20:13, on Zulip):

but yeah :)

nikomatsakis (May 29 2018 at 20:13, on Zulip):

TL;DR it's super important we get the diagnostics working I guess :)

pnkfelix (May 29 2018 at 20:13, on Zulip):

Right right

pnkfelix (May 29 2018 at 20:13, on Zulip):

SO

pnkfelix (May 29 2018 at 20:13, on Zulip):

the whole point

pnkfelix (May 29 2018 at 20:14, on Zulip):

since we do want NLL as part of the 2018 edition

pnkfelix (May 29 2018 at 20:14, on Zulip):

the current strategy we are planning on

pnkfelix (May 29 2018 at 20:14, on Zulip):

is to deploy the current MIR-borrowck based NLL

pnkfelix (May 29 2018 at 20:15, on Zulip):

and thus this yields the following way to prioritize bugs

pnkfelix (May 29 2018 at 20:15, on Zulip):

1. NLL-sound takes top priority

pnkfelix (May 29 2018 at 20:15, on Zulip):

This is especially important in a world where if "AST-borrowck got errors and MIR-borrowck didn't get errors" implies code is accepted

pnkfelix (May 29 2018 at 20:16, on Zulip):

then its absolutely top priority to address NLL-soundness issues

pnkfelix (May 29 2018 at 20:16, on Zulip):

now as you can see from the above, Niko may have been thinking of a world where we wouldn't do that

pnkfelix (May 29 2018 at 20:17, on Zulip):

(i.e. where AST-borrowck rejecting the code would mean that we would report the AST borrowck errors, even if MIR-borrowck accepted with no errors)

pnkfelix (May 29 2018 at 20:17, on Zulip):

in that world ... maybe the prioritiy scheme I've been assuming is wrong

pnkfelix (May 29 2018 at 20:17, on Zulip):

But in the end, in the long term

pnkfelix (May 29 2018 at 20:17, on Zulip):

NLL-soundness issues simply have to get fixed

pnkfelix (May 29 2018 at 20:17, on Zulip):

Luckily

pnkfelix (May 29 2018 at 20:17, on Zulip):

we're really close to fixing all of them, I think.

pnkfelix (May 29 2018 at 20:18, on Zulip):

okay, so, next up

pnkfelix (May 29 2018 at 20:18, on Zulip):

2. NLL-diagnostic bugs

pnkfelix (May 29 2018 at 20:18, on Zulip):

these are second highest priority. And you can see from the above conversation that they may be even more important than Niko had already thought they were

pnkfelix (May 29 2018 at 20:19, on Zulip):

In particular, NLL-diagnostics bugs are higher priority than getting polonius into shape

pnkfelix (May 29 2018 at 20:19, on Zulip):

(because, as noted above, we are currently planning for MIR-borrowck to be the basis for the initial NLL deployment. Not polonius.)

pnkfelix (May 29 2018 at 20:19, on Zulip):

There a lot of NLL-diagnostic bugs currently open

pnkfelix (May 29 2018 at 20:20, on Zulip):

but it is not clear how many of them are dupes of each other or end up having the same root cause

pnkfelix (May 29 2018 at 20:20, on Zulip):

Niko did say he would have to drop off

qmx (May 29 2018 at 20:20, on Zulip):

/me realizes now what the two-pronged approach really meant

pnkfelix (May 29 2018 at 20:20, on Zulip):

which is a shame because I think he had some things to say here

pnkfelix (May 29 2018 at 20:20, on Zulip):

in terms of pointing out some good starter bugs to attack

nikomatsakis (May 29 2018 at 20:21, on Zulip):

I posted a few links in the paper

nikomatsakis (May 29 2018 at 20:21, on Zulip):

I will try to post some more later

pnkfelix (May 29 2018 at 20:21, on Zulip):

@qmx to be clear, we want development on polonius to continue

nikomatsakis (May 29 2018 at 20:21, on Zulip):

/me afk-ish

pnkfelix (May 29 2018 at 20:21, on Zulip):

obviously people are going to choose what they want to work on

pnkfelix (May 29 2018 at 20:21, on Zulip):

but, perhaps even more importantly

pnkfelix (May 29 2018 at 20:21, on Zulip):

Polonius is a crucial part of our long-term straetegy

pnkfelix (May 29 2018 at 20:22, on Zulip):

because there is a third category of NLL bug I did not mention in this prioritization scheme

pnkfelix (May 29 2018 at 20:22, on Zulip):

and that is NLL-complete(ness) bugs

pnkfelix (May 29 2018 at 20:22, on Zulip):

i.e. the examples of source inputs that we believe NLL should accept

pnkfelix (May 29 2018 at 20:22, on Zulip):

but for some reason MIR-borrowck does not today accept

pnkfelix (May 29 2018 at 20:23, on Zulip):

We are banking on Polonius to be our long term way to address NLL-complete bugs

pnkfelix (May 29 2018 at 20:23, on Zulip):

as in, at some point in the future, assuming we get the diagnostic issues and performance issues with Polonius all resolved

pnkfelix (May 29 2018 at 20:24, on Zulip):

we will switch to it, and magically NLL will just become smarter

pnkfelix (May 29 2018 at 20:24, on Zulip):

and accept more code than before

pnkfelix (May 29 2018 at 20:24, on Zulip):

(deleted)

pnkfelix (May 29 2018 at 20:24, on Zulip):

So, because we are treating Polonius as our secret weapon for dealing with NLL-completeness in the long term

pnkfelix (May 29 2018 at 20:25, on Zulip):

that gives us some freedom to downgrade the priority on NLL-complete bugs that have been filed against MIR-borrowck.

pnkfelix (May 29 2018 at 20:26, on Zulip):

Now, to be clear: Source code that was accepted by AST-borrowck and is supposed to be accepted by NLL, obviously those cases have to keep working

pnkfelix (May 29 2018 at 20:26, on Zulip):

we cannot let those slide

pnkfelix (May 29 2018 at 20:27, on Zulip):

But the cases where AST-borrowck rejects the code and NLL should accept it ... those are ones where, if MIR-borrowck is rejecting it today, we figure we are better off putting effort into other tasks.

pnkfelix (May 29 2018 at 20:27, on Zulip):

rather than trying to make MIR-borrowck smarter

pnkfelix (May 29 2018 at 20:28, on Zulip):

(where those "other tasks" are either 1. NLL-soundness issues with MIR-borrowck, 2. NLL-diagnostics with MIR-borrowck, or 3. Getting Polonius into shape.)

pnkfelix (May 29 2018 at 20:28, on Zulip):

Does this all make sense to the people reading along?

pnkfelix (May 29 2018 at 20:28, on Zulip):

we are coming close to an hour for this half-hour meeting...

pnkfelix (May 29 2018 at 20:29, on Zulip):

/me just realized he never posted a status update in the triage doc, either

pnkfelix (May 29 2018 at 20:30, on Zulip):

Okay well I guess the point of all this is

pnkfelix (May 29 2018 at 20:30, on Zulip):

If you are happily working on polonius currently, and want to continue doing so, please do continue doing so

pnkfelix (May 29 2018 at 20:30, on Zulip):

But if you are looking for something to do, either because you're just getting started, or if you feel like getting your feet wet elsewhere

pnkfelix (May 29 2018 at 20:31, on Zulip):

then please do look at the "diagnostic issues worth tackling" that Niko links in https://paper.dropbox.com/doc/Non-lexical-lifetimes-NLL-Triage-Em2cJrvxQMMFWLE7lE5Be

qmx (May 29 2018 at 20:52, on Zulip):

even if we didn't cover everything, the whole conversation was very useful and made things clearer. Thanks!

pnkfelix (May 29 2018 at 21:39, on Zulip):

however, [the plan to only show mir-based errors] ups the ante on getting borrowck error quality improved :)

continuing my review of the NLL-stderr-diagnostic-deviations, I have to admit that recreating all of the suggestions that have been implemented for AST-borrowck does seem like quite a daunting task.

pnkfelix (May 29 2018 at 21:40, on Zulip):

and thus perhaps @nikomatsakis has a good point in arguing that the initial deployment of NLL should still issue all errors signaled by AST-borrowck.

nikomatsakis (May 29 2018 at 21:40, on Zulip):

I have a feeling if we focus on it it would go faster than expected

nikomatsakis (May 29 2018 at 21:40, on Zulip):

but I guess we can test that hypothesis :)

pnkfelix (May 29 2018 at 21:40, on Zulip):

However, I fear that if we do that (and thus reject all code that AST-borrowck rejects), NLL stops looking like much of a feature.

pnkfelix (May 29 2018 at 21:41, on Zulip):

(and more of a burden)

pnkfelix (May 29 2018 at 21:41, on Zulip):

Of course that would only be a relatively short term status...

pnkfelix (May 29 2018 at 21:42, on Zulip):

but I guess we can test that hypothesis :)

All those AST-borrowck diagnostics were, at least in part, the result of a massive distributed effort by various volunteers, right? We can probably recreate that. :)

nikomatsakis (May 29 2018 at 21:42, on Zulip):

I'm sort of persuaded to your plan fwiw :)

nikomatsakis (May 29 2018 at 21:42, on Zulip):

I was worried about "mixing" AST and MIR-based diagnostics

nikomatsakis (May 29 2018 at 21:42, on Zulip):

but I hadn't thought of the "Third Way"

nikomatsakis (May 29 2018 at 21:43, on Zulip):

(reporting MIR errors as hard errors)

pnkfelix (May 29 2018 at 21:44, on Zulip):

well, semi-hard errors

nikomatsakis (May 29 2018 at 21:44, on Zulip):

right, hard errors if AST borrowck failed

Last update: Nov 22 2019 at 00:45UTC