I will be doing pre-triage in this channel.
first up: unprioritized nominations
unpri nom 1/7: "missing libstdc++-6.dll in beta-x86_64-pc-windows-gnu (1.41.0-beta.1)" #67408
#67408: P-high, removing nomination
also, just so people are aware: PR #67410 (the fix for the aforementioned issue) has already been beta-nominated and insta-beta-accepted (presumably due to release pressure). Thanks @simulacrum !
Uh, not really - just not really any need to consult anyone (Alex and I are fine with backport I believe and only maintainers of bootstrap today)
oh its not release pressure? Isn't there a imminent beta promotion ?
unpri nom 2/7: "const_if_match ICE" #67405
triage: stable-to-beta regression. P-high. Leaving nominated to try to ensure we give it attention at todays meeting.
unpri nom 3/7: "ICE: unexpected ty: [type error]" #67377
I wrote a comment. I think this is only P-medium, because the common issue with the examples is that a syntax error in the source (which is reported in a diagnostic) is somehow causing an ICE downstream after the parser does recovery
unpri nom 4/7: "ICE on unused generic in struct" #67375
wow that one is pretty wild looking
I'm willing to call this P-high, just because there is no diagnostic info apart from the ICE, and its message is not very helpful for a non-rustc dev
#67375: P-high, removing nomination.
unpri nom 5/7: "Performance regression in nightly-2019-12-14" #67331
cannot act on this yet since there is no example code yet for us to work with
I'm going to remove the nomination and ask them to renominate after providing an example we can use
unpri nom 6/7: "Casting or adding type ascription to panic!() triggers unreachable_code" #67227
No beta promotion has already happened
for #67227, I'm not sure whether there is anything we can do here yet. We could investigate trying to make the unreachable_code lint treat coercions/casts specially
in any case, #67227 doesn't seem like a high priority item to address.
I'm going to triage it as P-medium but leave it nominated.
(T-Lang still needs to make a decision)
(attendance was low in prev mtg)
unpri nom: "Replace our fragile safety scheme around erroneous constants" #67191
triage: P-high to resolve desired semantics and implementation strategy here. (I don't know what priority to assign to the actual implementation work yet though...)
leaving #67191 nominated because I think T-lang may need to revisit it when they/we have a proper quorum
that's all the unprioritized nominations
there are no beta-regressions without a P-label
there are no nightly-regressions without a P-label
I'll skim over the nominations, to 1. see if there's cases where I can remove the nomination (e.g. if its alreay been addressed) and 2. to curate the list of nominations I would like to ensure we address today
there are 10 open nominations
I'm going to put "
./x.py check failed if incremental builds enabled" #58633 on the list again for today: @simulacrum and I were musing last night about whether we should just remove the
unused_attributes lint entirely. (I believe it has served its original purpose.)
@mati865 are you around for today's meeting? I'd like someone to advocate for movement on "under latest MinGW, cannot link with C code using stdout" #47048
it sounds like @mati865 is at this point [blocked by issues with the old version of mingw-w64 on Rust's CI. Does that make this a T-infra issue?
@simulacrum @Pietro Albini ^ ?
Someone needs to make the call it we're to upgrade
I'd guess that's compiler team
okay I'll put this on today's agenda too then
whether we should just remove the unused_attributes lint entirely. (I believe it has served its original purpose.)
I'd like to see a list of cases where the lint would could be triggered to evaluate whether the lang team should decide to remove it or not.
I know it would trigger on e.g.
@centril maybe I chose too strong a phrasing
it isn't necessarily that the lint is totally useless
@pnkfelix I don't really have an opinion whether it is or isn't at this point :slight_smile:
(shocking, I know... Centril doesn't have an opinion? ^^)
the problem is that its current architecture, based on updating some global state, has not been updated to work with incremental compilation
mark_used (https://doc.rust-lang.org/nightly/nightly-rustc/syntax/attr/fn.mark_used.html) & friends are pretty ugly from an infra POV
and so we are in this situation where we need to decide whether the lint is providing enough of a benefit that we should invest the effort to make it actually work properly with incremental comp. My brief review o the code last night led me to think that it was not a trivial fix
Right, I can see how that'd be the case that it plays badly with incr.comp -- I'm less sure about the benefit side of things
for example, could T-compiler decide to remove it or disable it across the board, without lang team approval, if we also filed a bug saying "this thing was buggy; T-lang can decide whether its worth reenabling" ?
(@simulacrum did have at least one idea on alternative implementation strategies that might not be too hard to implement, but the proposal, namely a bit of mutable state in the AST itself, scared the bejeeezus out of me.)
I'd say: let's discuss it on T-Lang today; and then we don't need to go back to a t-compiler meeting again, someone can "just" do the removal if we decide to do it
okay, I'm okay with that. I'll remove it from T-compiler agenda for today then
namely a bit of mutable state in the AST itself, scared the bejeeezus out of me.
This will give eddyb a heart attack ;)
(and me also)
(or was your implication that it should nonetheless stay on T-compiler agenda for today ...?)
if you think it's useful
maybe someone comes up with an alternative alternative strategy on the mtg
eh... we might have a lot of stuff to get through
I would not worry about it for today
not that high priority :)
(can we use a side-table via
I think yes -- but the side table presumably doesn't solve the problem of this state not being incremental-ready
mati865 are you around for today's meeting? I'd like someone to advocate for movement on "under latest MinGW, cannot link with C code using stdout" #47048
Sorry, just got the email.
I think it requires T-compiler fix first (I have WIP in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.5BWIP.5D.20Fixing.20MinGW.20link.20errors.20.2347048) and after it's resolved it'll be purely T-infra issue (updating mingw-w64).
FYI I'm removing nomination from "Linking issue with Rust 1.37.0" #64340
I'm preparing newer version to open PR today.
well, I don't consider that a T-infra issue
i.e., we're not updating because we don't know whether it's safe
(i.e., is that a compat break for someone)
I thought you just said T-compiler should make call ?
right, yeah, that's my point
oh oh, right, I see.
but after T-compiler makes the call
then the actual work is T-infra, right?
(I'm not saying that's fair. Just that it reflects reality...)
though I envision the work being pretty simple -- the investigation into whether we want to do it is the hard bit
okay I'm done with my nomination skim
time to put up the beta-noms list
two beta-noms; I'll put them on the hackmd I'm drafting.