I will be doing pre-triage in this channel.
unpri nom 1/9: "
Box is marked as "dereferencable" for the duration of the call" #66600
resolving what to do here does seem P-high to me.
triage: P-high. Leaving nominated tag on because I think this is worth at least touching on in today meeting (hopefully)
unpri nom 2/9: "ICE when rustc failing to write to /dev/null on OSX" #66530
this sounds familiar to me
oh no, I was thinking of something else; this bug is an artifact of how we derive intermediate build products from the requested output file name
does not seem like a terribly high priority thing for us to deal with though.
triage: P-medium, assigning self (because the bug author managed to pique my interest by mentioning "rust code minimization"), removing nomination
unpri nom 3/9: "matches macro conflicts with matches crate" #66518
Not sure why that one is t-compiler
eek, some scary potential changes to macro hygiene hypothesized here
@centril did you read the comments?
I wonder how hard this will be to bisect
anyway its currently a beta-regression. Lets tag it P-high at least until we've managed to better identify the scope of the
bug change in behavior
triage: P-high, leaving nominated for now. Leaving unassigned for now.
Ok so it's a different issue than the expected priority stuff wrt. prelude and whatnot
Let's see what petrochenkov finds then
Assign to them?
its possible someone else could handle the bisection?
I'll leave it nominated for now
Don't see why not
if we don't get a volunteer before or at the meeting, then I'll assign to petrochenkov
unpri nom 4/9: "ICE matching on a non-[u8] const array" #66501
This seems related to your work on structural match.
that assert sounds frankly wrong?
I had a look at it yesterday but I don't understand match checking enough
Anyway, it seems to me like its only tangentially related to the
#[structural_match] work. a slice
&[(); n] should be
#[structural_match] out of the box.
I'll take a look at it
triage: P-high, removing nomination label, self-assigning.
unpri nom 5/9: "ICE 'no entry found for key' in Servo’s style crate" #66487
triage: P-high. Removing nomination (petrochenkov already self-assigned.)
triage: P-medium, removing nomination label.
unpri nom 7/9: "ICE: Can't combine functions in the same CGU that reference both a static and an extern static with the same name" #66464
triage: has PR; P-high, removing nomination
unpri nom 8/9: "Regression in helpful compiler error message when working with lifetimes" #66406
sounds like a QoL issue; not P-high imo
but I'm sure estebank will fix it in due time
triage: P-medium, removing nomination
actually, I agree with @Esteban Küber that this is arguably a dupe of #41343
except that this is tagged as a regression due to other artifacts
well, I'll let it be for now
unpri nom 9/9: "under latest MinGW, cannot link with C code using stdout" #47048
I have no idea what's going on here. There's a pretty big comment thread.
Leaving unprioritized and nominated.
next up: unprioritized beta-regressions
unpri β regr 1/3: "NLL Regressions in 1.40" #66517
I guess this is P-high
I don't know who's going to do the work being requested
seems like @simulacrum is interested
unpri β regr 2/3: "ICE when trying to move from reference in union" #66500
(personally I suspect these are abandonware and not worth our time, which we could use for other things)
seems like simulacrum is interested
maybe, but they did not assign themselves ...
regarding #66500, we don't tag things as regressions if they rely on feature-gates, right?
oh, I see: the ICE doesn't need the feature gate
(I was looking at the next comment that pointed out a slight variation with feature-gate (and
&mut) compiles without ICE'ing; which sounds much much worse.)
unpri β regr 3/3: "
unused_parens triggerts on macro by example code." #66295
re:NLL breakage, I personally feel like if we are introducing breakage of this scale the least we can do is fix everything or atl least make an effort, regardless of abandonware
I myself plan to help out, but do not have time to do all 80
hmm. I would normally consider #66295 not high priority, but without data about how many crates are impacted (its been flagged a regression), making it P-medium is a little hard to swallow.
https://github.com/rust-lang/rust/issues/66295#issuecomment-552799156 does warn on stable and older compilers
@simulacrum I'll nominate #66517 for discussion at the meeting. Maybe we can collectively agree to divvy up the work in some fair manner
@centril that does not jibe with what the bug filer claimed on the bug?
so it seems that #66295 is an issue wrt. types only? (that's the only new thing that we've changed...)
@pnkfelix I believe it's like the improper_ctypes thing... it's old behavior manifesting in new places
"is it a bug" seems like a question which should be answered for all cases (pats, exprs, types) consistently, not just types
but it seems like a design question?
(Personally I'd be inclined to make the lint not fire when its highlighting something inside a macro definition)
it seems reasonable not to complain about parens in macros
lets maybe nominate for a quick straw poll of that idea at the meeting then?
@pnkfelix seems like we are thinking the same then; but since it's a design question & a lint, it should be brought up in T-Lang (as well...)?
okay that's reasonable to me, I'll tag T-lang too
lets call it P-high to answer the question
there are no nightly (ν?) regressions without a P-label
next, I'll skim over the nominated T-compiler issues to try to identify cases of labels that should have been removed last week
(we discussed "improper_ctypes fires for &mut T, &T, *const T and *mut T (when T: Sized)" #66220 in last week's meeting; I am on hook from lang-team duties to address it with T-lang feedback, but I don't think we'll discuss that one today
In any case I'll leave it nominated at least until I post aformentioned T-lang feedback. (Or @centril, would prefer I leave nomination label on even after doing so?)
not sure; it might be good to discuss it briefly as "last week's stuff"
mostly to report back to the team
removed I-nominated from "Enable incremental rustfmt adoption" #65939
we didn't get around to discussing "Some features can no longer be controlled by conditional compilation" #65860 last week despite my best hopes, so I'm leaving that one nominated for today's meeting.
Yikes; then I need to switch to that one and leave feedback now... but I'm in the middle of providing feedback for something else
the thread on that #65860 has become somewhat hard to follow, IMO
anyway, that's all the nominations I feel I need to skim. Unfortunately I only managed to cull one from the current todo list
I'll try to push these along to get us to the nominations faster today
we have 34 open P-high issues
nineteen of which are unassigned
wow there are 8 beta-nominated PR's
five of which are also stable-nominated
might be hard to get through 8 beta-nominations and 11 I-nominated issues
we will see
@pnkfelix did you forget to leave beta approvals from last week?
oh good point!
let me go check
yes yes yes thank goodness
Reminder that I'd like to touch on #53081, if we have the time
But less critical than the regressions
@Esteban Küber yep, its one of the 11 nominated issues. I'll try to put it at the front of the queue
@simulacrum what do you want to do for the abandoned ones (or GH repos which are just tests) ? I'd like to help but the ones I'm looking at rn have either been deprecated, archived on GH, etc
If they're explicitly abandoned then that's fine
Basically - we should put in the time
And not just say "too bad"
There's code out there that is not visible to us, if there are regressions in the open it means there's a non insignificant chance that closed repos will also hit it.
Not even a clean crater run means a safe change, it only gives us _some_ confidence.
@simulacrum sure, I'll add what I saw to #66517
Basically - we should put in the time
(I personally don't agree with this; I think there's also a question of fairness towards all the unpaid FOSS contributors in rust-lang/rust -- I don't think we/they should bear all the cost, especially when crates are largely unused, and when the migration period has been so long)
(of course, if it's important to you then by all means... ^^)