I will (or hope to) be doing pre-triage in this channel. (I have movers packing around in my apt, so its a little hectic here.)
first up: unprioritized nominated issues; there are nine
unpri nom 1/9: " ICE:
no name for expr || " #67252
I'll aim to look into that as soon as, someone else can grab it if they have time before I do though.
okay. As I'm sure you're aware, its been bisected to PR #65345. (just letting public know.)
triage: P-high. Removing nomination tag.
unpri nom 2/9: "Casting or adding type ascription to panic!() triggers unreachable_code" #67227
assigned @davidtwco to the issue
looks like #67227 is largely nominated as a lang-team concern.
(and its not clear whether its a bug, which is why its a lang team issue)
yep; for now
Debating about whether this deserves a P-label
If I were to give it any P-label, it would probably be P-medium
nah; if t-lang decides a change is necessary we can triage next week
unpri nom 3/9: "Replace our fragile safety scheme around erroneous constants" #67191
also lang team, but possibly also for compiler for discussion of impl
yeah okay. lets leave that for next week too
unpri nom 4/9: "thread 'rustc' panicked at 'index out of bounds: the len is 168 but the index is 171'" #67165
ugh sounds like a hard-to-reproduce incremental compilation issue.
sometimes I think the compiler should check point a copy of the source in
target/ on each non -ICE'ing incremental compile. And then when an ICE'ing one occurs, auto-file the bug.
@pnkfelix that makes sense to me actually; sometimes when I get incremental ICEs or inconsistencies I just do
./x.py clean without filing a bug
(or rather, provide an easy way for the user to confirm that the ICE can be replicated in two steps: a clean build of the checkpointed state, and the incremental build off of that cached state)
triage: P-medium (unfortunately); until we can get a more readily reproducible scenario, we cannot readily act on this
removing nomination label
unpri nom 5/9: "cdylib fails to link with incremental compilation after panic -> no panic transition" #67118
this is also an incr comp issue, but this one sounds like it has a MCVE!
hmm I wonder if this is actually fixed by my recent PR #67020
anyway, I'm so excited by an incr comp bug with a reproducible test (hopefully)
triage: P-high, removing nomination. Assigning to self to see if I can replicate, and if so, how it behaves with respect to PR #67020
unpri nom 6/9: "ICE while compiling async/await code" #67087
removing nomination until we get more info on how to reproduce.
unpri nom 7/9: "Usage of errorneous constant can be omitted on nightly and beta" #67083
this is a duplicate of #67191, .... right?
(or at least strongly related)
but this is also a downright regression
yeah strongly related
oh but we have a PR to fix it (and it just needs to land, and be backported to beta)
triage: P-high, removing nomination, assigning to @oli (well, already was)
unpri 8/9: " Compiler panic playing with "Err" and lifetimes" #67072
minification shows this is actually about a mismatch between enum types
triage: P-high, removing nomination
unpri 9/9: "
./x.py check failed if incremental builds enabled" #58633
@centril merged PR #67101, which says it papers over this problem
oh, yes, that is quite a big hammer:
#[allow(unused_attributes)] // FIXME(#58633): do a principled fix instead. (in src/libcore/convert/mod.rs)
okay, leaving nominated. Maybe we'll talk about it this week, though I personally know I won't be much use at today's meeting
@pnkfelix what do you think of that branch name? ;)
heh. are ostriches the only birds that put their heads in the sand?
no idea, but they are one of them ^^
there are no unprioritized beta-regressions
nor any unpriroritized nightly regressions
looking over the nominations now to see if anything was already discussed last week and should be unnominated. Also, I guess I'll try to build up a queue to discuss for today, using this hackmd
last week's discussion, from zulip archive
and I think it concluded here
this also sounds familiar: "Necromancing (putting back some removed error codes explanations)" #66836. I'll write a note
this also sounds familiar: "Regression in Error conversion from Infallible" #66757
ah right, T-compiler and T-lang discussed. Revert for short-term seemed prudent.
does this need to still be nominated? I don't think it doees.
I think you're right
okay so lets see if I can put together the agenda of nominated issues for today