I will be doing pre-triage in this channel.
first up, unprioritized nominations
unpri nom 1/10: "internal compiler error: src/librustc/ty/subst.rs:610: type parameter
E/#1 (E/1) out of range when substituting (root type=Some(E)) substs=" #67037
has PR. tagging P-high removing nomination.
feel free to review-steal-drive-by-r+ :P
unpri nom 2/10: "
attempted .def_id() on invalid res: Err in rustdoc for
pub(restricted) struct fields using derive helper macros" #67006
triage: petrochenkov self-assigned. P-high, removing nomination.
unpri nom 3/10: "libarena::TypedArena::alloc_from_iter does not allow for recursive allocations" #67001
If [...], the allocation goes in the fast path. In that case, the allocation for the range and the recursive allocations get interlaced. The returned pointers are wrong, and valid objects get overwritten. This can lead to undropped objects and infinite loops.
(we have a fix in the pipeline, so I think this is p-low at this point -- maybe a performance optimization)
P-low? the fact it sounds like it has soundness issues makes it P-high to me
because https://github.com/rust-lang/rust/pull/67003/ will fix it
(things with fixes in pipeline can and do get P-high all the time. I use P-labels as severity metrics)
but sure, p-high seems fine
(not as "is this getting enough attention metrics")
but arguably this is something that should change. (not today though!)
I-unsound is its own severity metric; basically it's the worst severity ^^
its also a T-libs issue, not a T-compiler one, based on PR #67003
well, libarena isn't t-libs
i.e., it's owned by compiler team
oh .... right
we should check if the crates.io TypedArena has the same problem.
well, libarena isn't t-libs
maybe this is suggesting that we need to change the folder structure to have
cannot trivially tell if crates.io TypedArena does
file an issue for deeper investigation :slight_smile:
does not look like it does
but unclear, it has vecs as backing store vs. raw ptrs
Cc'ed SimonSapin on PR #67003 in any case.
oh yeah, maybe it was a from-scratch impl, I cannot remember now
unpri nom 4/10: "ICE on rustc 1.41.0-nightly (25d8a9494 2019-11-29) running on x86_64-apple-darwin" #66958
triage: has PR. P-high, removing nomination.
unpri nom 5/10: "internal compiler error: our vector went away? in proc macro expansion" #66922
triage: @estebank has been cc'ed (tho' not yet assigned). P-high, removing nomination.
unpri nom 6/10: "Emscripten builds broken on nightly? (Linking errors in fresh "hello world" crate)" #66916
needs reduction to MCVE
@centril should we rename the label
E-needs-reduction-to-mcve? I am not sure if enough people know the MCVE acronym at a glance.
I suppose in some cases E-needs-mcve is given when we don't even have anything to start a reduction from ...?
doesn't the label have a description?
(though I think in practice we usually only use the label when we actually do have something to start with)
label has description, yes
but I am musing about whether that is enough
I'm not opposed but meh :slight_smile:
its just a thought
seems like this is something we should track down
triage #66916 : P-high, removing nomination.
triage: P-medium, removing nomination.
unpri nom 8/10: "ICE on closure typeck" #66868
not clear if this is a regression or a long-standing bug
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
unpri nom 9/10: "ICE when
cargo doc on
lexical-core: attempted .def_id() on invalid res: Err" #64705
duplicate of #67006, or perhaps this was reduced down to that?
ah comment says #67006 is similar but newer regression
triage: P-high, removing nomination
unpri nom 10/10: "Linking issue with Rust 1.37.0" #64340
cue Sideshow Bob gif of stepping on rakes
seems like PR #59752 was nominated for discussion for a potential revert to fix this and other issues
I need to double check if our meeting agenda links include nominated merged PR's
nope, currently it does not
I'll add this one manually and later try to look into whether we can fix that (so that even closed can be nominated)
anyway, triage #64340: P-high. Leaving nomination label
next list, unprioritized beta-regressions ... there aren't any.
next list, unprioritized nightly regressions ... there aren't any
next list: nominated issues, trying to find cases that do not need to remain nominated.
I'm going retag "floating point to integer casts can cause undefined behaviour" #10184 as solely T-lang: I think the issues to be resolved there are semantic choices about what
float as int means
(i.e. whether we are willing to let it have a panicking semantics or not, whether we are willing to let it have a
freeze-based underspecification or not, etc)
these are questions better aimed at the T-lang team, not T-compiler, at least for the initial discussion, IMO
I thought we were going with saturation
and only the implementation remained
the dialogue on the issue does not make that clear to me
guess we need a clearer decision then?
I hate github's handling of long comment threads so much
like: why does "load more ..." not load from both directions ???
if I want to see more of the recent discussion, I have to repeatedly unfold everything from the beginning? Really? Really?
i know right
I would love a "show me every comment, I really mean it"-button
issue "under latest MinGW, cannot link with C code using stdout" #47048 remains nominated. Despite my effort to draw attention to it last week, I'm not sure I can remove the nomination label yet, given the radio silence that resulted then.
(or is it something that requires attention from both T-compiler and T-infra ?)
likewise for "COPYRIGHT file is wildly out of date" #63232
@centril is issue #65860 a T-lang thing or a T-compiler thing at this point? The PR that caused problems for RalfJ was reverted; does that mean we can un-nominate
#63232 #65860 from T-compiler issues?
I added T-infra to address the first part in the issue: "We package these files in "rust-mingw" component instead of current "rust-std" component in win-gnu builds."
I think someone mentioned that this is done now?
@pnkfelix what's the relation btw those PRs?
shoot that was a typo
the conditional compilation thing is waiting for me to do a write-up
I meant to reference #65860 in both cases
you can un-nominate and I'll renominate when I'm ready
sounds great, thanks
I think I will do the same for "improper_ctypes fires for &mut T, &T, *const T and *mut T (when T: Sized)" #66220
(a similar situation where we have done an eager revert and now await follow-up work for a more nuanced fix
I hope to get to that after next week.
you can un-nominate and I'll renominate when I'm ready
do you want me to assign you to the issue so that it does not get lost?
(and to represent the idea that you have pending work that you intend to do on it)
@davidtwco could I interest you in review-stealing https://github.com/rust-lang/rust/pull/67044 so it's ready before we discuss beta noms? :P
@centril I’ll do my best, on a train so internet isn’t guaranteed.
aight, I'll take it :slight_smile:
Boarding PR review FTW
Regarding this nomination: "Regression in Error conversion from Infallible" #66757, the most relevant comment is here: https://github.com/rust-lang/rust/issues/66757#issuecomment-559771169
(re. never type, I'm inclined towards 1. right now)
why not 7 ?
that would be the second time we've reverted
that ... sounds like some sort of sunk cost fallacy to me ?
I think the feature is fine as-is, never_type_fallback could make it better in the future, and the regressions are allowed under RFC 1122
@pnkfelix I think @nikomatsakis is up to speed on the context, and I'll be present
he's happy with landing half of those changes, which means we can probably spend a lot more time thinking about the "skip unnecessary work in WF" part (which is scarier soundness-wise)
@centril "Const generic ICE: constant in type had an ignored error: TooGeneric" #66962 is nominated and tagged P-medium ?
what do you want T-compiler to discuss for nomination?
someone should fix it
P-medium is my suggestion
isn't that the case for all bugs? (that someone should fix it)
yes, well, we should find someone to fix it like we do
I'll go ahead and advertise it on the channel.
but then remove the nomination label
because ... I don't think there's anything to actually discuss there?
well maybe you think it should be P-high :slight_smile:
that's up for discussion :P