This week's triage will be tracked here
first, prepasses to identify P-high issues before I go through the P-high issues themselves...
beta regressions prepass
first: "compiler panic on bad negative bound" #58857
P-high. estebank is on it so assigning them.
next: "Missing right parenthesis panics the compiler" #58856
again, P-high. estebank is on it so assigning them.
last: "Derives on deprecated items generate deprecation warnings" #58822
definitely gotten complaints here
assigning P-high label
no nightly regressions without P-label for us
and there remain three nominated T-compiler issues without P-label
first: "Incorporate RLS bug tracking into compiler team triage" #58858
tagging as P-high, leaving nominated, tagging as
metabug too (though that label's meaning is not 100% clear given the different ways it has been used to this point)
oh, and given that I am both driving triage each week and also trying to get more involved in RLS, I'll just assign this to myself.
(metabug is probably a misnomer... I think the label is primarily used for issues linking to other issues whereas "metabug" is about the way we think/handle/talk about bugs)
right; we could just apply the (new?) C-tracking-issue label to the old uses of
next nominated without P-label: "Rustc 1.33 stable panicked on a closure inside a closure" #58840
(probably; we need some sort of label for "collection-of-issue" to replace it; a good example is: https://github.com/rust-lang/rust/issues/57563)
tagging #58840 as P-high.
last nominated without P-label: "Implement "pipelined" rustc compilation (compiler side)" #58465
leaving #58465 unprioritized, unassigned, and nominated. I don't know how to prioritized this work offhand so I'll leave that to the actual meeting.
as a quick double-check, here is the list of nominated issues across all teams (i.e. ignoring T-labels)
I don't see anything there that needs a
T-compiler added to it. So that seems fine.
so, next step: P-high T-compiler issues
lets try to go quickly given I have 3 minutes until meeting start
(and have someone assigned)
#58840 was also discussed. It has no one assigned but its nominated for discussion so that's fine
(as in, we'll cover it)
likewise "Derives on deprecated items generate deprecation warnings" #58822 has no one assigned but it is nominated so we'll cover it
"Rustc panic when building bobbin-sdk" #58767 has @oli assigned
there's a fix, but nothing is getting merged atm
right okay that has PR #58784
github for some reason doesn't say that the PR will close the issue as I'm used to
shoot meetings about to start so much for getting through the list in three minutes
(everything else has someone assigned so I'll try to go over it and double-check status after the meeting)
by the way I speculatively assigned "Derives on deprecated items generate deprecation warnings" #58822 to @oli based on bisection performed by @nikomatsakis during meeting.