Stream: t-compiler/wg-nll

Topic: weekly meeting 2019.02.27


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

hi @WG-compiler-nll ; we'll be having our meeting in this stream topic in about ... seven hours.

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

as discussed last week, the weekly meeting is going to shift to more of a synchronized office hours of sorts. But I still want to take care of pre-triage before the meeting; I've dedicated a separate topic to that task.

pnkfelix (Feb 27 2019 at 16:17, on Zulip):

pre-triage is done. The outcome is five nominated issues/prs to discuss at tonight's meeting.

lqd (Feb 27 2019 at 16:52, on Zulip):

does "synchronized office hours of sorts" mean "we'll generally talk about issues, ask questions, think about how to solve them ?"

pnkfelix (Feb 27 2019 at 20:25, on Zulip):

seems reasonable to me

pnkfelix (Feb 27 2019 at 20:26, on Zulip):

okay @WG-compiler-nll , you got your seven hour warning, now this is your five minute warning. :)

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

Currently compiling what I hope is a fix for #58776

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

Hi everyone

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

as noted above, pre-triage yielded five nominated issues

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

I'm hoping we can get through them relatively quickly and then leave the remaining time to free discussion

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

the nominated issues are these five

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

first is "NLL migrate mode erroneously downgrades error with nested closures, yielding use-after-free" #58776, which sounds like its hopefully under control

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

in any case its clear that @Matthew Jasper is on the case

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

so I'm just going to remove the nominated tag; if anyone has Q's about it, lets maybe have those after we go through the other nominations

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

going slightly out of order, next is "Include bounds from promoted constants in NLL" #57202

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

I nominated this after reviewing it today

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

because I just wanted to point out that this change is going to change our handling of a particular test case

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

as i commented here in my review

lqd (Feb 27 2019 at 20:34, on Zulip):

seems like it ICEd in some tests ?

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

so the test in question is from issue #48697

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

seems like it ICEd in some tests ?

hmm clearly we'll have to look into that too

pnkfelix (Feb 27 2019 at 20:36, on Zulip):
[00:26:48] thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', /checkout/src/libcore/slice/mod.rs:2539:10
[00:26:48] note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[00:26:48]
[00:26:48] error: internal compiler error: unexpected panic
[00:26:48]
[00:26:48] note: the compiler unexpectedly panicked. this is a bug.
pnkfelix (Feb 27 2019 at 20:36, on Zulip):

lack of a stack trace there is unfortunate

Matthew Jasper (Feb 27 2019 at 20:36, on Zulip):

Yes, that's from a rebase. I'll have a look soon.

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

any way I personally am okay with the shift in behavior in the test

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

though it might good to validate the hypothesis I posted as to why its not compiling now

Matthew Jasper (Feb 27 2019 at 20:37, on Zulip):

The test was to check that we didn't ICE

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

right. and we don't ICE

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

but still, it is a change in the static semantics. Its probably a bug fix

lqd (Feb 27 2019 at 20:38, on Zulip):

though it might good to validate the hypothesis I posted as to why its not compiling now

it is compiling now ?

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

tell you what, I'll just give myself an action item to double-check why its behavior changed

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

@lqd issue-48697.rs compiles on current master. After this PR, it gets rejected with a static error

lqd (Feb 27 2019 at 20:38, on Zulip):

ah understood

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

or ... well the commit I had commented on may have dissapeared

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

but I assuem that it an artifact of rebasing

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

maybe this is stable diff link ?

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

anyway. I'll work on satisfying my own curiosity here

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

I'm not so concerned about this one as to try to push for a warning cycle or whatnot

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

(this case was already being rejected by AST-borrowck)

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

next nominated issue: "user type annotations are captured post normalization" #54940

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

I nominated this in the hopes that niko might be able to report what the plan is for lazy normalization

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

which he has said is blocking this from being fixed

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

but I don't think @nikomatsakis is here right now

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

I can just leave this nominated but we can move along

nikomatsakis (Feb 27 2019 at 20:42, on Zulip):

I sort of am

nikomatsakis (Feb 27 2019 at 20:42, on Zulip):

I've not been following along (sorry)

lqd (Feb 27 2019 at 20:42, on Zulip):

they were recently looking for examples of things needing lazy norm

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

its sort of a cross-cutting issue at this point

nikomatsakis (Feb 27 2019 at 20:42, on Zulip):

Ah, lazy norm -- well, answer is that I am currently in an "investigative" phase -- and that's it's a high priority of traits WG

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

between WG-nll and WG-traits

nikomatsakis (Feb 27 2019 at 20:43, on Zulip):

but still haven't formed concrete plan of what we will do

nikomatsakis (Feb 27 2019 at 20:43, on Zulip):

but "progress is being made"

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

so maybe Ill just leave it nominated and we can maybe hope to discuss tomorrow at T-compiler meeting?

nikomatsakis (Feb 27 2019 at 20:43, on Zulip):

seems ok; I probaly won't have a lot more to say by then, but maybe I can pester some folks :)

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

okay, i can't ask for more than that

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

next nomination: "fix "bivariant wf" bug in the NLL subtyping code" #54105

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

I nominated this to see if I could entice a victim volunteer to try to search for a test case

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

with the warning that niko had already put K units of effort (for unspecified K and unspecified work unit) into trying to find said test

pnkfelix (Feb 27 2019 at 20:45, on Zulip):

this might be a better candidate for the free discussion period...

pnkfelix (Feb 27 2019 at 20:45, on Zulip):

in fact

pnkfelix (Feb 27 2019 at 20:45, on Zulip):

I regret bringing it up now;

pnkfelix (Feb 27 2019 at 20:45, on Zulip):

I'd rather raise the last nominated issue first

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

are we sure there is such a bug ? that is, can we find this test case ?

pnkfelix (Feb 27 2019 at 20:45, on Zulip):

are we sure there is such a bug ? that is, can we find this test case ?

that's basically the problem. :smile:

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

our hope was to find a test case; at least for me, that would help assign a prioritization

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

I think @nikomatsakis thinks that there is a bug, but doesn't know if it affects any code.

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

without a test case, its hard for me to give a serious priority label to this, which means I'd be tempted to just tag it as P-low

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

(which is sort of how we've been treating that bug anyway...)

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

anyway I've satisfied my desire to at least publicly state "hey this bug exists"

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

so now the last nominated topic, which may be so dumb as to not be worth discussing, is "Does the MIR generated for match still build in order-deps visible to MIR-borrowck?" #58646

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

so this one I think requires a little bit of explanation; you can find an attempt at an explanation on the bug description

lqd (Feb 27 2019 at 20:50, on Zulip):

(about the prior issue: maybe we can look for such a case in a relaxed/exploratory manner ? that is, I'm not opposed to looking for such a thing myself but if Niko didn't find it easily after some K units of time I'm not particularly hopeful about my chances :)

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

but the heart of #58646 is: we have some amount of safe-guards against accidental order-dependence in our code-generation for match. That is, we don't want to couple ourselves too tightly to the particular control-flow graph that we happen to generate

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

and yet to my eye there are relatively simple variants that one might argue are coupled to the control-flow graph

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

reading over the test now, I admit that the intent of the fn all_previous_tests_may_be_done may have been more about the order in which the components of the tuple are matched

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

rather than the order of the match arms, which is what the text of #58646 is talking about

Matthew Jasper (Feb 27 2019 at 20:55, on Zulip):

That's what the test was for. I don't mind the example that you posted too much since it amounts to us guaranteeing that we don't preemptively test patterns.

pnkfelix (Feb 27 2019 at 20:55, on Zulip):

I don't know how to interpret "don't mind the example",

pnkfelix (Feb 27 2019 at 20:56, on Zulip):

that could mean "it would be fine for the compiler to accept it"

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

There are some more subtle cases around guards where we expose the fact that we sometimes "remember" the result of a test across a guard.

pnkfelix (Feb 27 2019 at 20:56, on Zulip):

or it could mean "it would be fine for us to start rejecting it"

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

that could mean "it would be fine for the compiler to accept it"

I mean this

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

okay

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

I also don't mind if we accept that code

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

but I do think it might lead to some interesting question marks when it comes time to attempt formal specification

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

and it might be an interesting experiment to just try adding backwards fake edges?

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

or maybe that's bonkers

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

anyway, that's everything I wanted to get out in the open

Matthew Jasper (Feb 27 2019 at 20:59, on Zulip):

I really don't want a cyclic cfg for match. It interacts pretty badly with guards.

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

I really don't want a cyclic cfg for match. It interacts pretty badly with guards.

yeah I was worried about that. The only alternative I could image would involve having duplicate code paths

Matthew Jasper (Feb 27 2019 at 21:00, on Zulip):

I think more fake reads would be the better approach to this.

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

and duplicate code paths, if you nest matches, could have bad (code size) blow up (at least in the abstract representation, not the actual machine code)

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

oh interesting ... like add fake reads of future patterns, sort of modelling speculative execution

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

the other simple reality is that if we actually wanted to make changes to the match code gen, it would probably have to be tied to an edition or something

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

at least that's my guess as to how we could best limit any negative impact.

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

if we're done with nominated issues I have a couple questions

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

I'm done with the nominations

lqd (Feb 27 2019 at 21:06, on Zulip):

the first is related to universes and the temporary return of the leak check: I was working on #57374 but the leak check's return has brought it back to pre-Universes levels of diagnostics. I feel I needed some help from Felix to advance

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

hmm

lqd (Feb 27 2019 at 21:07, on Zulip):

(there's a dedicated topic, where I posted my level of progress, which was somewhat at this point "we need to look at the mir and reimplement basic errors" so that felt wrong-ish)

pnkfelix (Feb 27 2019 at 21:08, on Zulip):

@nikomatsakis is there a -Z flag to remove the leak check?

Matthew Jasper (Feb 27 2019 at 21:08, on Zulip):

-Zno-leak-check

pnkfelix (Feb 27 2019 at 21:08, on Zulip):

@lqd could that help you at least have something to run with?

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

thanks Matthew

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

it's also related to other issues (another ICE, etc) so I was wondering when do we think the leak check will be removed again ?

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

(some of these were closed by the PR but we might need to keep an eye on them for when it's removed again)

pnkfelix (Feb 27 2019 at 21:12, on Zulip):

/me is trying to figure out how we missing #46989 at last week's T-compiler meeting...

lqd (Feb 27 2019 at 21:12, on Zulip):

but yeah -Zno-leak-check will help in at least being able to work on #57374, albeit I'm still unsure on what to do. My last update on it being this

pnkfelix (Feb 27 2019 at 21:15, on Zulip):

okay I'll see if I can spend some time assisting with #57374 tomorrow or friday

pnkfelix (Feb 27 2019 at 21:15, on Zulip):

sorry its been a month of radio silence there

pnkfelix (Feb 27 2019 at 21:16, on Zulip):

but while we're here: Are there other Q's?

lqd (Feb 27 2019 at 21:19, on Zulip):

no need to apologize I was working on another universe issue (which was also fixed temporarily by the leak check return :)

lqd (Feb 27 2019 at 21:19, on Zulip):

the other Q I had was about the bivariant wf bug, if you had pointers on to look for such a test case ?

pnkfelix (Feb 27 2019 at 21:20, on Zulip):

hmm nothing at the moment

lqd (Feb 27 2019 at 21:20, on Zulip):

(esp as we're not sure we can trigger it in code)

lqd (Feb 27 2019 at 21:20, on Zulip):

oh ok

lqd (Feb 27 2019 at 21:21, on Zulip):

and that's all I personally had

pnkfelix (Feb 27 2019 at 21:23, on Zulip):

okay. I'm going to remove the I-nominated tag from #54105

lqd (Feb 27 2019 at 21:23, on Zulip):

do we need a P- ?

pnkfelix (Feb 27 2019 at 21:24, on Zulip):

I'm not going to put one on quite yet

pnkfelix (Feb 27 2019 at 21:25, on Zulip):

I want another chance to think about this, and I'll hopefully look at it again next week when I again look at the pile of unprioritized issues.

lqd (Feb 27 2019 at 21:25, on Zulip):

I can try looking at it a bit as well

pnkfelix (Feb 27 2019 at 21:28, on Zulip):

thanks!

pnkfelix (Feb 27 2019 at 21:28, on Zulip):

okay bye everyone

lqd (Feb 27 2019 at 21:28, on Zulip):

good afternoon/evening everyone :wave:

lqd (Feb 27 2019 at 21:35, on Zulip):

also: :tada: for #58788 @Matthew Jasper :)

Last update: Nov 22 2019 at 00:35UTC