I will be doing pre-triage in this channel.
first up: we have 11 unprioritized I-nominated T-compiler issues
2 soundness holes in a week... nice..
somehow I got distracted and lost 30 minutes just now
anyway, first up
nominated unprioritized: "Hangs on derive macro invoked by format string macro" #44692
This stable-to-stable regression is spawned off a bug that was originally thought to not be a rustc bug. But this narrower test case seems to be more definitively our problem. Looks P-high to me. I'll assign to petrochenkov and myself for initial investigation, and remove the nomination.
(my hope is that some eventually revision to my pre-triage process will lead me to actually looking at all the P-high bugs, not just nominated or unassigned ones, which would then lead to me not assigning myself to these tickets.)
next nominated unprioritized: "Static cyclic references not compiled in current nightly rust version" #62189
This stable-to-nightly (soon to be beta) regression has been bisected to PR #58351 and identified as a const-eval issue. @oli stated that they would investigate, so I am assigning to them.
As a note: My current thinking is that when I assign a (previously unassigned) bug to somehow who has already seemed to have "claimed" it (by e.g. saying they would take it, or chiming in on the ticket in a semi-authoritative manner), then I will just assign that one person. If that person has not claimed it, then I will assign myself as well to try to keep track of those cases.
anyway: #62189, P-high, removing nomination, assign to @oli
next nominated unprioritized: "Internal compiler error anonymous bound region BrAnon(0) in binding but not trait ref" #62200
occurs on stable. checking if its always been present in some form, or if its a stable-to-stable regression
(maybe we should have an actual label for bugs that have been present ever since their code could have been expressed?)
fwiw master->beta promotion happened last night, and first beta should be published in about 2-3 hours
oh okay thanks @simulacrum !
(and 1.36 release just kicked off)
regarding #62200, did some further investigation. Seems like a very very old bug. Going to call it P-medium for now. (and remove nomination and assign to self).
next: "ICE on HRTB" #62203
description claims bug occurs in stable+beta+nightly, but code to reproduce relies on
feature(unboxed_closures). Did issue filer use RUSTC_BOOTSTRAP, or go back to nightlies that correspond to stable+beta, or ...?
I think the features aren't really being used?
Maybe for the FnMut<T> vs. FnMut(T)
the ICE occurs even after you get the warning about the features
so never mind
ICE is from librustc/infer/lexical_region_resolve.rs
I wounder if full blown NLL would fix it
nightly appears to have same ICE with feature(nll)
ICE appears to have been injected between 1.32 and 1.33
#62203: P-high, removing nomination. Assigning to self for now.
next nominated unprioritized: "Nightly compiler panic on using Self with associated type in type alias" #62305
#62305: P-high, needs-bisect, removing nomination, assigning to self. (It would be good to have an "owner" for each category like A-associated-items who could be delegated to for further delegation. Perhaps something to discuss at the triage/maintenance meeting, whenever that happens...)
next nominated unprioritized: "Future compat warning with
was already self-assigned by matthew-jasper. Given status of async-await as "important feature for near-term", I'll give this P-high status, and removing nominatin.
(thanks @Matthew Jasper !)
already automatically assigned by rust-highfive. Has PR thanks to @matthiaskrgr . Going to add them to the assignee list, and mark as P-medium.
ah cannot add @matthiaskrgr . I need to double check, there's some other work flow we have in place for this, right? to delegate a bug or something? Or is that only for delegation of reviewing PR's?
You can claim issues; idk if you can delegate; cc @simulacrum
@rustbot assign @gh-user
hm, that ended up clearing everyone
ah that removes previous assignees too. I see, and then assigns rustbot.
what does that mean then?
see first comment -- it has "@matthiaskrgr is assigned in [this comment]"
I assume we have a separate web page I go to in order to see who's been assigned in this manner?
This issue has been assigned to @matthiaskrgr via this comment.
that'll work well enough, since rustbot is assigned and that will show up in the github issue list etc, thanks.
next nominated unprioritized: "FFI broken with many parameters" #62350
already assigned to @eddyb
#62350: P-high, removing nomination.
next nominated unprioritized: "ICE:
rustc crashes in a
chroot sandbox" #62353
this is arising from
rustc::session::filesearch::get_or_default_sysroot, on this line
hmm. At first I was thinking "can we do anything about this", but surely we could let our users specify a sysroot if they are running in an environment where they cannot rely on
It seems like an interesting bug to tackle, but not a high priority one.
#62353: P-medium, leaving nominated to discuss at meeting (to see if anyone wants to take it or mentor someone else on how to address it).
next nominated unprioritized: "ICE on self-referential typedef" #62364
recent regression, about to hit beta (or already hit beta, depending on POV as noted earlier).
#62364: P-high, removing nomination. Assigning to @Alexander Regueiro and self to ensure follow-up.
okay, that is all the nominated unprioritized T-compiler issues.
there are zero nominated with no team assigned
which is "ICE "not a type parameter" on nightly (regression)" #62263
we have 44 P-high T-compiler issues
8 of those are unassigned
I'm going to go afk for hopefully a short time, and hopefully return in time to try to assign these 8 issues to people that may or may not include me.
unassigned P-high: "Running cargo test with proc macro that uses main fails" #62127
@Vadim Petrochenkov has been pretty involved with dialogue on this one. (They also have stated that the bug, or some variant of it, may be hard to fix. Not sure what the final status is.)
#62127: assigning to @Vadim Petrochenkov
next unassigned P-high: "Rustdoc recursion limit issue" #62059
ah I said last week I was assigning this to @nagisa and then failed to do so.
but @nagisa did note that they were unlikely to have time to address it soon
so I'll assign it now to @nagisa and myself.
next unassigned P-high: "ICE when running kcov with proptest as dev-dependency" #60372
#60372: assigning to self
next unassigned P-high: "Compiler panic at Box<Any>" #60363
there's been some dialogue on ticket
#60363: assigning to @oli and mysefl.
lets take care of one more, to get everything from this yeasr assigned:
P-high unassigned: "Stable rustc always panics on arm/musl" #60297
actually I'll just nominate it and see if someone at the meeting is willingto take it.