I will be doing pre-triage in this channel.
happy new year @centril
thank goodness, we only (?) have 13 nominated unpriroiritzed issues
Happy new year @pnkfelix
looks like it has a fix; just waiting for submodule to be updated. Anyway, I think #67793 is P-medium.
do you have the link handy for the list of issues?
nom unpri 2/13: "
Internal compiler error: building dynamic library is unsupported on Emscripten" #67782
I'll back paste it.
(Also, Its I think the first link from "Pre-triage Process" in #54818 )
emscripten isn't a high prio target I think
speaking of which, I probably should port that (the weekly meeting protocol) to the compiler-team website proper. Probsably.
or maybe forge?
/me looks briefly at https://github.com/rust-lang/compiler-team/issues/204
it's probably a good idea to paste whatever the link is each meeting; I wouldn't remember where it was anyways :P
oh the link is in the topic
I had always thought that was obvious
but I can understand that its not
indeed, the ability to succinctly put the link in the topic is basically the only motivation for why the agenda lives there.
but I digress. Heavily≥
back to prioritization of #67782
yeah I think so
feels kind of yucky to prioritize any ICE as P-low, though
it depends on what aspect of the bug is under discussion
anyway I'll call it P-med for now
https://github.com/rust-lang/rust/issues/67778 <-- p-high?
nom unpri 3/13 "async fn ICEs in macro on stable" #67778
do I leave it nominated though
I think I won't.
I managed to cc petrochenkov again
(I was thinking "clones" but I suppose that emoji doesn't necessarily mean that...)
nom unpri 4/13 "Nightly 2019-12-29 causes
reached the type-length limit error in previously working code " #67757
not really a bug, but also ungreat
(and related to a perf regression on the side)
wasn't #65244 going to be reverted ... ?
or am I thiiniking of something else
we bisected a big perf regression to that PR
by perfbotting a revert PR
yeah @Wesley Wiser was looking into whether reverting it resolved the perf issue
but we haven't decided to revert
where was the decision made?
to land the PR or to unland the PR?
(just so I can link to it from the relevant points)
oh I misunderstood
or rather I misread
thought you said "we decided not to revert". . . swapped words around
Since the IntoFuture PR caused two distinct forms of regressions it seems wise to discuss landing a revert in the full mtg
#67706 is nominated
(Although T-lang and T-libs FCPed it, but I think we did not intend for these regressions...)
let me create a hackmd.io page for today's meeting
so I can make sure we cover this in nominations
Speaking of... do we have t-lang mtg today? (or is it on the 6th?)
that would be exciting
I had forgotten we were going to change things up there
we're having an extra meeting; thursdays are still on
lets ask somewhere in #t-lang
nom unpri 5/13: "
test/run-make-fulldeps/pgo-branch-weights fails occasionally on CI" #67746
seems @mw is on it
let's say p-high cause CI problems
yeah. Intermittent CI failures I do indeed consider P-high
especially if it can be addressed in short term by just disabling a test
(and really, the form of the soluition should not affect the prirority, at least not until one has shown that a solution is truly monstrous relative to the severity of the problem.)
nom unpri 6/13 -- Recent nightly doesn't support array length from indirectly referenced trait constant #67743
(also removed nomination label from #67746)
#67743 sounds P-high to me
lazy normalization issue?
#67743: triage P-high, removing nomination
triage P-medium removing nomination.
nom unpri 8/13: "Major async/await compiler performance regression" #67706
we already discussed this briefly
triage: P-high, leaving nomination label.
nom unpri 9/13 "internal compiler error: src/librustc_traits/normalize_erasing_regions.rs:42 #67684
let's ignore the off-topic remark in the issue...
maybe @Matthew Jasper would be suitable
though we don't even have a backtrace
well, anyone should indeed be able to try to reproduce locally
to make more progress, even in terms of getting a backtrace, as you note
oh, yeah, right, forgot
the filer does not seem terribly interested in collaborating in such a fashion
lets call it P-high for at least learning more about the bug itself
but removing nomination
nom unpri 10/13: "rustdoc does not verify feature gates" #67647
do .... do we care ?
I guess its up to
rustdoc team to decide priority
guess they don't really have triage
nom unpri 11/13 " illegal instruction on x86_64-linux-android since 1.40.0 " #67582
quite a stack of systems
i cannot even tell, is it qemu that's hitting the illegal instruction there?
x86 android seems exotic :P
maybe it JIT's to native code or something.
not sure what tier this target is
@Pietro Albini @simulacrum is x86 android Tier-2 ?
lets call #67582 P-medium for now.
x86 or x86_64?
triage: P-medium based on this being a tier-2 platform. Removing nomination.
nom unpri 12/13: "ICE on invalid syntax in proc macro attr" #67567
@pnkfelix maybe it would be useful to have ICE messages tell people to run a command that de-macro-ifies
hmm, I was assuming a macro was necessary for repro here
the DistinctSources part made me think that, at least.
oh it's some span issue?
sounds like @Esteban Küber should take a look when they are back ^^
I guess the separate
mod file must be part of it too, though.
you do currently get useful diagnostics
so I'm inclined to call this P-medium
nom unpri 13/13 "[ICE] with recursive impl trait and Iterator.by_ref()" #67552
and that's an example of an ICE without a useful diagnostic.
triage: P-high. Don't think there's anything worth discussing at meeting about it though, so removing nomination
okay, next up, unprioritized beta regressions
there are 2
unpri beta regr 1/2: "failed to evaluate constant" #67612
assigning to @oli
unpri beta regr 2/2: "not Send due to await retainment" #67611
I guess this is P-high too. I'll nominate it
unpri nightly regr 1/1: "Fn traits with array args no longer work with const_generics enabled" #67753
p-medium or low I think
commenters claim this is expected fallout of #66883.
it's not an issue yet
you mean because this is a known buggy feature anyway ?
also known buggy...
I'll call it P-medium and move on
next: prepass over nominations
we did discuss #47048 two weeks ago
yeah we basically "decided" then to ask @mati865 to move forward with experimentation here.
https://github.com/rust-lang/rust/pull/67429 waits for the review
yeah I'm going to remove nomination from #47048
and also I'm going to assign the issue to @mati865
I'll add PR #67429 to nominations for today
made a reduction to https://github.com/rust-lang/rust/issues/67552#issuecomment-570227908 meanwhile :D
okay, I've gone through the chat log from last meeting. There are no other issues in the currennt nominnation list that deserve to be un-nominated based on that log.
lets make a formal list of the beta-nominations on the hackmd
okay I've finished fleshing out the hackmd
pretty proud of myself for even getting the backport emojis ready ahead of time.
@centril provisionally assigned the issue you mentioned me in for when I get back, but I don't know if we might have to escalate and have petrochenkov take a look at it too.