Stream: t-compiler

Topic: pre-meeting triage 2019-03-28 #54818


pnkfelix (Mar 28 2019 at 12:56, on Zulip):

This week's triage will be tracked here.

pnkfelix (Mar 28 2019 at 13:01, on Zulip):

first up, unprioritized nominated T-compiler issues

pnkfelix (Mar 28 2019 at 13:02, on Zulip):

we have "miri no longer builds after rust-lang/rust#59471" #594747; it sounds like a fix is being worked on at the miri end in https://github.com/rust-lang/miri/pull/668

pnkfelix (Mar 28 2019 at 13:03, on Zulip):

I don't know how to prioritize these miri build bugs in general. I'm going to assume for now that they should default to P-high, but that's based on assumption about their importance to rustc that may be incorrect. @oli or @RalfJ, are these issues indeed P-high in general?

pnkfelix (Mar 28 2019 at 13:06, on Zulip):

anyway I'll tagging that specific one as P-high since its getting worked on anyway so I figure its not going to hurt to give it high priority.

pnkfelix (Mar 28 2019 at 13:07, on Zulip):

Next up: "ripgrep fails to build with MUSL on Linux since the nightly release on 2019-03-15" #59411

pnkfelix (Mar 28 2019 at 13:11, on Zulip):

marking as P-high. (It has a PR up that looks safe to me; it just enables PIC across the board for MUSL, which sounds as good as any other option I can think of offhand.)

pnkfelix (Mar 28 2019 at 13:12, on Zulip):

next: "Implement "pipelined" rustc compilation (compiler side)" #58465

pnkfelix (Mar 28 2019 at 13:13, on Zulip):

I keep leaving this nominated and just hope that it will get eventually addressed in a steering committee meeting. But maybe today we can actually discuss this, try to assign a priority to it? Wishful thinking I suppose.

pnkfelix (Mar 28 2019 at 13:16, on Zulip):

Okay, that's all the unprioritized nominated T-compiler issues

pnkfelix (Mar 28 2019 at 13:16, on Zulip):

there are currently zero unprioritized nominated issues with no team assigned

pnkfelix (Mar 28 2019 at 13:17, on Zulip):

next prepass: unprioritized beta regressions

pnkfelix (Mar 28 2019 at 13:17, on Zulip):

there's just one: "Wrapping simd call results in compiler panic (nightly)" #59469

pnkfelix (Mar 28 2019 at 13:18, on Zulip):

marking P-high

pnkfelix (Mar 28 2019 at 13:22, on Zulip):

there are currently zero unprioritized stable-to-nightly regressions

pnkfelix (Mar 28 2019 at 13:22, on Zulip):

that's all the pre-passes.

pnkfelix (Mar 28 2019 at 13:22, on Zulip):

now the real triage starts.

pnkfelix (Mar 28 2019 at 13:22, on Zulip):

we have 21 p-high T-compiler issues

pnkfelix (Mar 28 2019 at 13:23, on Zulip):

lets start at the bottom

pnkfelix (Mar 28 2019 at 13:23, on Zulip):

"Future-incompatible warnings should always print a warning, even if lints are allowed" #34596

pnkfelix (Mar 28 2019 at 13:23, on Zulip):

ah this is an oldie, from July 2016

pnkfelix (Mar 28 2019 at 13:23, on Zulip):

I prioritized as P-high two weeks ago, and then nominated it a week ago

pnkfelix (Mar 28 2019 at 13:24, on Zulip):

we want a volunteer to try to attack this. I'll post it in the main meeting topic area.

centril (Mar 28 2019 at 13:24, on Zulip):

@pnkfelix I can give it a try; but no promises

RalfJ (Mar 28 2019 at 13:24, on Zulip):

I don't know how to prioritize these miri build bugs in general. I'm going to assume for now that they should default to P-high, but that's based on assumption about their importance to rustc that may be incorrect. oli or RalfJ, are these issues indeed P-high in general?

I don't think they need to be P-high. They are not very relevant for rustc, only the stand-alone miri interpreter is affected.

RalfJ (Mar 28 2019 at 13:25, on Zulip):

but I also dont know how you guys use priorities, I am an outsider to the compiler team^^

pnkfelix (Mar 28 2019 at 13:25, on Zulip):

pnkfelix I can give it a try; but no promises

okay; I'm still going to post it in the main area to give it visibiliity, but I'll note that you said you'd take a shot

pnkfelix (Mar 28 2019 at 13:25, on Zulip):

but I also dont know how you guys use priorities, I am an outsider to the compiler team^^

This is useful. I will probably default to P-medium for these miri things rather than P-hihg in the future, then.

centril (Mar 28 2019 at 13:27, on Zulip):

@pnkfelix question for you... should all I-ICEs be T-compiler + I-nominated ?

pnkfelix (Mar 28 2019 at 13:27, on Zulip):

T-compiler, yes

pnkfelix (Mar 28 2019 at 13:27, on Zulip):

I-nominated, i'd say only if they haven't already been triaged with a P-label?

pnkfelix (Mar 28 2019 at 13:28, on Zulip):

next P-high bug: "match arm bindings have weird lifetimes" #46525

centril (Mar 28 2019 at 13:28, on Zulip):

@pnkfelix right; -- I'll take this back to T-release's procedures then

pnkfelix (Mar 28 2019 at 13:28, on Zulip):

I'm embarrassed to admit that I haven't done much with #46525 recently

pnkfelix (Mar 28 2019 at 13:29, on Zulip):

but I'm happy to note that @Matthew Jasper seems to have assigned themself to it 15 hours ago. :)

pnkfelix (Mar 28 2019 at 13:29, on Zulip):

(In fact I'm going to remove myself based on that action from @Matthew Jasper )

pnkfelix (Mar 28 2019 at 13:30, on Zulip):

@Matthew Jasper , if you disagree about the prioritization of that issue, or if you think it should e.g. block the deployment of NLL migration mode to the 2015 edition, let me/us know.

pnkfelix (Mar 28 2019 at 13:30, on Zulip):

(probably as a comment on that ticket (#46525).)

pnkfelix (Mar 28 2019 at 13:31, on Zulip):

next up is "two-phase-borrows need a specification" #46901, where I again have no progress to report.

pnkfelix (Mar 28 2019 at 13:32, on Zulip):

although I do think some of the work here has been done as a side-effect of resolving issues related to PR #58739.

centril (Mar 28 2019 at 13:32, on Zulip):

next P-high bug: "match arm bindings have weird lifetimes" #46525

Feels like something good to discuss on T-Lang's mtg today wrt. what we want to do?

pnkfelix (Mar 28 2019 at 13:32, on Zulip):

anyway I'll leave #46901 as P-high for now

pnkfelix (Mar 28 2019 at 13:32, on Zulip):

@centril in terms of how it ties into NLL and the 2015 edition? I suppose so.

pnkfelix (Mar 28 2019 at 13:33, on Zulip):

though I'd definitely want a little bit of advance warning if it does get thrown into the mix

centril (Mar 28 2019 at 13:33, on Zulip):

@pnkfelix no, the semantic question

centril (Mar 28 2019 at 13:33, on Zulip):

but sure, NLL and 2015 also, why not

pnkfelix (Mar 28 2019 at 13:34, on Zulip):

one potential problem is that @Ariel Ben-Yehuda has phrased #46525 in terms of pretty low-level operations like the issuing of storage-deads. So it can be harder to make illustrative test cases than some of the other bugs we sometimes discuss

pnkfelix (Mar 28 2019 at 13:35, on Zulip):

I'm not saying that makes it impossible to discuss. Just that its not the same as code you can throw into the playpen and say "now look at the output."

centril (Mar 28 2019 at 13:36, on Zulip):

@pnkfelix should be able to illustrate using Drop impls and unit structs, no?

pnkfelix (Mar 28 2019 at 13:36, on Zulip):

no I don't think so

pnkfelix (Mar 28 2019 at 13:36, on Zulip):

At least, I posted a comment saying that would not suffice to observe the bug here

pnkfelix (Mar 28 2019 at 13:36, on Zulip):

see https://github.com/rust-lang/rust/issues/46525#issuecomment-466427086

centril (Mar 28 2019 at 13:37, on Zulip):

@pnkfelix even with bind_by_move_pattern_guards enabled?

pnkfelix (Mar 28 2019 at 13:37, on Zulip):

Maybe I'm wrong, feel free to prove me wrong

centril (Mar 28 2019 at 13:37, on Zulip):

:+1:

pnkfelix (Mar 28 2019 at 13:38, on Zulip):

Just trying to say, in that comment I was being pretty deliberately ambiguous about how hard it might be to observe the bug

pnkfelix (Mar 28 2019 at 13:38, on Zulip):

(namely in the "And even then ..." part)

pnkfelix (Mar 28 2019 at 13:38, on Zulip):

my guess is you might have to jump actually peeking at raw addresses

pnkfelix (Mar 28 2019 at 13:39, on Zulip):

but again, I might be wrong. And some of that stuff I do not think is guaranteed to be stable

centril (Mar 28 2019 at 13:39, on Zulip):

I'll have a look later, let's move on

pnkfelix (Mar 28 2019 at 13:40, on Zulip):

next: "Function pointer docs may need updating" #46989

pnkfelix (Mar 28 2019 at 13:41, on Zulip):

This remains P-high, but I'm going to assume that @Aaron Turon is continuing to look at it

pnkfelix (Mar 28 2019 at 13:41, on Zulip):

next: "[nll] change how MIR represents places" #52708

pnkfelix (Mar 28 2019 at 13:42, on Zulip):

there's been activity here, spear-headed by @Santiago Pastorino

pnkfelix (Mar 28 2019 at 13:44, on Zulip):

@Santiago Pastorino : if you have time, it might be nice to get an update as what work items remain here. You can post it to the issue (#52708) itself. (I may also say "any announcements?" at the start of the meeting, depending on how the rest of this triage goes, so you can feel free to chime in with a short summary then as well, if you like.)

pnkfelix (Mar 28 2019 at 13:44, on Zulip):

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

pnkfelix (Mar 28 2019 at 13:45, on Zulip):

this remains important, but @nikomatsakis is in transit right now so I don't expect an immediate update from them.

pnkfelix (Mar 28 2019 at 13:46, on Zulip):

much like the pipelining issue, maybe we need to first create an issue dedicated to lazy-normalization, and then prioritize it, and then attempt to find a volunteer to take it on? I just worry about so many things resting on niko's shoulders...

pnkfelix (Mar 28 2019 at 13:46, on Zulip):

next: "[NLL] prohibit "two-phase borrows" with existing borrows?" #56254

pnkfelix (Mar 28 2019 at 13:47, on Zulip):

This, I'm happy to say, seems like its actually getting resolved.

pnkfelix (Mar 28 2019 at 13:48, on Zulip):

(the easiest point of reference for it is probably the new "Tracking issue for mutable_borrow_reservation_conflict compatibility lint" #59159 )

pnkfelix (Mar 28 2019 at 13:48, on Zulip):

( of course the credit for the code here goes to @Matthew Jasper )

pnkfelix (Mar 28 2019 at 13:48, on Zulip):

next: "[NLL] Bad higher ranked subtype error" #57374

pnkfelix (Mar 28 2019 at 13:49, on Zulip):

hmm.

centril (Mar 28 2019 at 13:49, on Zulip):

I just worry about so many things resting on niko's shoulders...

I'm trying to take away r?s from Niko at least.

pnkfelix (Mar 28 2019 at 13:49, on Zulip):

The whole deal with this bug (#57374) is that it stopped being a high priority in both my mind and in @lqd's mind once the leak-check was re-introduced.

pnkfelix (Mar 28 2019 at 13:50, on Zulip):

the leak-check itself is only intended to be a temporary measure

pnkfelix (Mar 28 2019 at 13:50, on Zulip):

but while it is in place, it is probably better for issues like this to reflect their actual priority and be marked as P-medium.

pnkfelix (Mar 28 2019 at 13:50, on Zulip):

The only question I have is whether there is an issue open for turning the leak-check back off ...?

nikomatsakis (Mar 28 2019 at 13:51, on Zulip):

(not that I know of, would be good to make one)

nikomatsakis (Mar 28 2019 at 13:51, on Zulip):

it's been on my mind but not actually tracked that I know of

centril (Mar 28 2019 at 13:51, on Zulip):

maybe check with Aaron?

nikomatsakis (Mar 28 2019 at 13:51, on Zulip):

and I'd like to work out what the dependencies are

pnkfelix (Mar 28 2019 at 13:51, on Zulip):

PR #58592 is the one that re-added the leak check

pnkfelix (Mar 28 2019 at 13:51, on Zulip):

and I don't see an issues listed in it as cross-referencing it

nikomatsakis (Mar 28 2019 at 13:51, on Zulip):

(following up with #57374 is also on my to-do list, but I confess i've been putting it off)

pnkfelix (Mar 28 2019 at 13:51, on Zulip):

which leads me to think that either there is no issue, or if there is such an issue, its description was very poorly written.

pnkfelix (Mar 28 2019 at 13:52, on Zulip):

So I'll first create such an issue now

pnkfelix (Mar 28 2019 at 13:52, on Zulip):

and then downgrade priority on things that are no longer P-high, but would block re-removal of the leak check (or become P-high again if the leak check were removed)

pnkfelix (Mar 28 2019 at 13:54, on Zulip):

filed: "eventual goal: re-remove leak-check from compiler" #59490

pnkfelix (Mar 28 2019 at 13:55, on Zulip):

downgraded #57374 to P-medium.

pnkfelix (Mar 28 2019 at 13:56, on Zulip):

next: "Nightly rustc crashes with "unexpected region in query response"" #57464

pnkfelix (Mar 28 2019 at 13:56, on Zulip):

I was going to resume working on this 56 minutes ago. THen I decided I really should do some triage. And here we are now.

pnkfelix (Mar 28 2019 at 13:57, on Zulip):

(I do think there are a lot of bugs that may have the same root cause that are related to this one...)

pnkfelix (Mar 28 2019 at 13:57, on Zulip):

anyway no progress but its on my mind

pnkfelix (Mar 28 2019 at 13:57, on Zulip):

next: "beta 1.33 seems to break tarpaulin on multithreading" #58104

pnkfelix (Mar 28 2019 at 13:58, on Zulip):

I nominated this four weeks ago, noting that I was predisposed to close as nonactionable. I'll point it out in the main meeting topic as well now.

pnkfelix (Mar 28 2019 at 13:59, on Zulip):

next: ""Cannot create local mono-item" ICE building cortex-m code on nightly" #58323

pnkfelix (Mar 28 2019 at 13:59, on Zulip):

did this fix for this land? I see lots of references from rollups...

pnkfelix (Mar 28 2019 at 13:59, on Zulip):

but PR #58605 is not closed...

pnkfelix (Mar 28 2019 at 14:00, on Zulip):

oh I see, @nagisa has been busy but that PR has gotten recent attention.

pnkfelix (Mar 28 2019 at 14:00, on Zulip):

so I'll assume it is under control for now

pnkfelix (Mar 28 2019 at 14:00, on Zulip):

ten P-high issues left! Lets start the meeting, I won't worry about those right now.

pnkfelix (Mar 28 2019 at 14:01, on Zulip):

(though I will double check about the unassigned ones at the meeting itself.)

nagisa (Mar 28 2019 at 14:02, on Zulip):

I think I fixed that PR yesterday, but the queue is putting rollups in front of my PR all the time :slight_smile:

Last update: Nov 20 2019 at 01:35UTC