just a heads up to @T-compiler that we'll be starting our weekly meeting in about 28 minutes
in the meeting, can you first approve stable backports? there is a PR up for 1.29.2
@Pietro Albini tell you what, I'll have a go at moving the list of beta-nominated issues up in our weekly agenda
this week there are also stable backports though :P
apparently we needed to add a link for that to the agenda anyway, so I'll just put it next to the beta nominations
what's the situation with etherpad?
it'd be nice if you could create gists owned by organisations, but that doesn't appear possible
I've wondered if we should just make a github issue with the agenda, and lock it so it won't get comments.
Then As a true hack, we could put the issue number of the agenda into the title of the weekly meeting
Could make a
t-compiler repo similar to how some working groups have repos to organize in.
maybe the pre-existing https://github.com/rust-lang/meeting-minutes could be repurposed...
FYI I'm taking the liberty of approving "incr.comp.: Don't automatically enable -Zshare-generics for incr. comp. builds." #54557 for beta backport
I'm tempted to do the same for "do not normalize all non-scalar constants to a ConstValue::ScalarPair" #54693, which looks very mechanical
(or we could ask @RalfJ to make the variant that does not get rid of
ScalarMaybeUndef that they suggested...)
Okay @T-compiler lets get started!
@pnkfelix I have already made that variant...
First we have the list of P-high issues
first P-high: "std-using paths work just fine in 2018 edition #![no_std]" #53166
Regarding #53166, I left a comment at the bottom, but basically its waiting on a question that I believe will be resolved at the T-lang meeting tonight
in any case its assigned to me so I'll follow up on it after the T-lang meeting
next up: "ICE: librustc/traits/codegen/mod.rs:68: Encountered error
how did this get P-high?
I assigned this P-high today. Its an ICE. I suspect its something with normalizing higher-ranked types
isn't this an old issue?
its old but I didn't see any one commenting on it besides earthengine (the person who filed it)
hi, my first time attending the meeting. Nice to meet everyone.
I think that this OutputTypeParameterMismatch issue had been reported a lot of times
good news is that i'm working on the universe stuff that I think will finally fix it :) I was hoping to look into it
I think https://github.com/rust-lang/rust/issues/29997 is the first time, from 2015
Okay. I'm happy to downgrade it. Is there a bug I can reference it being a duplicate of?
not sure it deserves P-high, but maybe just because it's a long standing annoyance
okay I'll leave a note
In principle, I don't like removing P-high unless we're explicitly retagging as P-medium
is that what we're doing?
fix when lazy normalization comes in I think
or rather, I'll tag #29997 as P-medium and close this as duplicate of that
or maybe it can be done without lazy normalization
@pnkfelix maybe also copy the minimized version from that issue
in case they have a slightly different root cause?
over to #29997 you mean? okay
I done that myself
next P-high: "Regression in #[allow(deprecated)] for
impl Trait return type" #54045
Looks like @Oli is on top of this
jup, PR is r+ed
next P-high: "Compiler panic using 'static_assertions'" #54327
so, on this one: a week ago we discussed this and determined that it was mistagged as a regression
so I removed the corresponding regression label, but left the P-high
I think this is the case where @eddyb said the ICE is "correct"
it's just a diagnostics ICE imo
in the sense that we can't handle this scenario elegantly
but we can't (without lazy norm) find a nice way to rule it out?
The question is how to prioritize doing a controlled error exit here
I still don't really fully understand that
but @eddyb and I were supposed to follow up and did not :)
Maybe I can assign this to you and @eddyb so that one of you will remember to follow up with the other to resolve that question then?
and give either of you carte blanche to remove P-high at your whim?
(of course, @Oli now says it's a diagnostic case...)
but yes feel free to assign to me
I will investigate to my satisfaction :)
I'd like to do so anyway
last P-high: "trait permitting extra members" #54665
@pnkfelix sure this can't be implemented without lazy normalization or terrible hacks
that amount to doing lazy normalization in some cases
#54665 sounds like it has been reduced to a pretty minimal test case that relies on features in edition 2018
which means it actually is high priority to resolve, right?
seems pretty high to me!
looks like it
@pnkfelix assign to me if you like
@nikomatsakis do you want to keep it for now? I can take it if you want or we can try to find another volunteer
I'm going to do some bug fixing today
Okay I'll leave @nikomatsakis assigned for now
this looks like a resolve problem, so I would ask one of the resolve people
Okay, next: At the request of @Pietro Albini we're going to go through the list of backport nominations before we go through the other stuff
aka @Vadim Petrochenkov
(but this seems like a good idea in general so I've just changed the agenda permanently to reflect this delta)
I'll dig in a bit and cc them with whatever I find; it does seem related to resolve
so beta-nominated issues ((for everyone, not just T-compiler; I'll try to remember to filter as we go...))
I mentioned right before the meeting started that I beta-accepted #54557. Feel free to voice your objection if you don't want it backported.
next beta-nomination: "resolve: Disambiguate a subset of conflicts "macro_rules" vs "macro name in module"" #54605
this seems small but I have no notion of relative risk in this code
yea the bus factor for resolve is annoyingly low
its fixing #54472 fyi
wait, why is that closed..
because it's fixed on nightly
a lot of the issues are closed before they're backported
I had thought we try not to do that
just a side-effect of "fixes #9999999"
but maybe I misremember
I'm ok with a beta backport I guess
I had thought we try not to do that
(or rather, that one often reopens the bug tracking the beta regression)
does anyone object to a beta backport of #54605 ?
okay tagged as beta-accepted
next: "do not normalize all non-scalar constants to a ConstValue::ScalarPair" #54693
oh @RalfJ already chimed in about this up above
the beta-backport is https://github.com/rust-lang/rust/pull/54759
why did it get tagged as S-blocked ?
which looks fairly low-risk
@Pietro Albini ^ ?
I think blocked on beta approval of the original nightly PR
why did the error messages change in #54759?
probably because the place the const eval error happened changed
@pnkfelix yep, because that PR was blocked on the approval
the error change also happens on the original PR
why does this change that? well, I guess I'm ok with beta backporting if @Oli is
(usually PRs are created after
I am ok with backporting
okay lets beta-accept #54759 then
the change in diagnostics is due to going from const eval errors to validation errors
I guess that is a side-effect of not normalizing
okay next beta-nomination: "normalize param-env type-outlives predicates last" #54701
should be quite low risk I think
(note: I'll probably just merge @RalfJ's backport on my rollup)
well, this stuff has sometimes surprising side effects I guess,
but we stabilized inferring outlives and so we really ought to fix the resulting regressions
so :+1: from me
re const eval: the new behavior was always present in structs with more than 2 elements - see https://github.com/RalfJung/rust/blob/d62aa3e085245621218759f8c8d56e29f600b74c/src/test/ui/consts/const-eval/union-ice.rs#L35
okay, any objections to beta-backport of #54701 ?
sure it's either that or bouncing out inferring outlives
I think it's a little bit risky
@nikomatsakis is inferring outlives something we must have in the beta?
just to make sure the question gets posed...
if there was no time pressure, I would prefer to bounce inferring outlives from beta
I think we could bounce it
we need it for RC2, but that's independent
(current beta is RC1, right?)
Okay: @Ariel Ben-Yehuda do you think you'd be able to be in charge of bouncing inferred outlives?
(well, I know that's true)
I can open the PR
Okay then. Lets tag PR #54701 as not beta-accepted. If something goes horribly wrong with bouncing inferred outlives, we can revisit the question.
last beta-nomination: "Fix dead code lint for functions using impl Trait" #54810
opneed 4 hours ago
I don't think the PR is particularly risky, I just think that landing trait system changes on beta is a risky concern.
but last beta nomination
I dont ... really care either way about #54810
it seems low risk, but also low reward? :)
looks pretty harmless
"just a lint"
I tagged it because the issue was tagged as a regression
I don't feel strongly about it
it feels worth it to me
is it a regression?
oh yes it is
used to lint, now it does not
with the PR it'll lint again
yeah, I think we should fix it
not very problematic if we don't backport
okay lets backport.
Unless anyone objects?
Okay, next up: nominations for backport to stable
namely: "Do not put noalias annotations by default" #54639
Seems low risk and high reward, right?
if this is going to be approved 1.29.2 will be shipped next thu
Fixes: "Incorrect code generation for nalgebra's Matrix::swap_rows()" #54462 FYI
(along with rls on win-gnu)
@Pietro Albini did we decide to do a stable point release then?
@Pietro Albini wait: do you mean regardless of whether this is approved, 1.29.2 will be shipped?
if so, we had better do #54639, as that was the whole impetus
or at least a major one
@nikomatsakis that was the consensus on the release team meeting yesterday
oh, not regardless
do we do point releases for non-regression non-security items?
@Pietro Albini the reason I'm confused is because of the addendum you added about "(along with rls on win-gnu)"
that made it sound like there was already something in the pipeline for the point release?
@pnkfelix oh, no, that's the other change we're going to ship along with this
but if we chose not to approve this, would you then cancel the point release?
do we do point releases for non-regression non-security items?
"ordinarily no, but potentially yes if they have high impact" is — I think — the rule. We're still feeling our way here I think.
hmm, we would probably rediscuss the release if this is not approved
that said, I think that #54639 is addressing a security issue
Okay. But in any case, #54462 is a regression-from-stable-to-stable
or at least a "soundness issue"
soundness issue != security issue
it's a long-standing regression-from-stable-to-stable
I feel like we shouldn't really debate the policy of whether to do the point release, personally, but just if we think the code is safe to backport. Otherwise, we'll be going round and round.
is the phrase "non-regression non-security" supposed to be an AND of the two, or an OR?
If it's already beta backported, then shipping a stable point release only gets the fix in users' hands 2 weeks earlier than they would get it in the next stable release.
@pnkfelix I think point releases should be either for security issues OR for severe regressions
Okay so then the question becomes "What's a severe regression" :)
I mean, new severe regressions
I still think this is is a low-risk high-value, but I actually don't care much either way
so we discussed this in the core team and decided to let the release team make the call
Okay, so core team delegated to release team and the release team said that they want it.
I guess we ought to decide how to manage these things
So if they're fine with it, the only reason we have to object is just because of the precedent it sets, right?
and I agree that having clear criteria is a good idea; what @Ariel Ben-Yehuda suggested potentially makes sense, I'm not really sure, I don't have a strong personal opinion
I do think that @Wesley Wiser has made a good point
that said, I feel like .. this is pretty bad misbehavior; in theory we support the current release, so it seems reasonable to fix
I guess my main point is that I want to go with the decision that was made, in part "because it was made", and I'm sure they considered the timing of beta :)
but if we want to push back, ok
actually, seeing the set of backports, there's a third category - accidental stabilizations
At this point I'm more worried that we're just spinning our wheels talking about this. We had a bunch of "sgtm's" up above...
(in particular, I wasn't thinking before about when the regression occurred per se)
I think our policy is sufficiently unclear that we should not legislate the backport of this PR based on what the policy hypoethically is...
I say compiler-team approve, but ask release-team for whether we want
*whether they want to point-release
I personally like that
as in, re-delegate to release team
in terms of the level of effort/reward involved?
well, the release team approved it yesterday
so we're good to go I think
I think it's reasonable to say this:
in general it's probably a good idea to decide who decides and leave it at that :)
maybe we need a broader conversation about it though
(stable backports and the criteria etc)
OKAY okay (sorry for yelling)
3 minutes left :wink:
here's all teh stable-to-beta regressions: https://github.com/rust-lang/rust/labels/regression-from-stable-to-beta
We've already looked at the ones tagged T-compiler and T-high
there is #54387 which is not tagged with T-compiler, but does have someone assigned to it.
has a PR up
(and I think we already discussed it)
(or at least it has a PR, right)
there are a few that are assigned to you, @pnkfelix ?
next: "[1.30 beta] Macros recursion limit detection changed" #54464
or are we going through them 1 by 1
we discussed this last week
one might argue we shoud prioritize the ones that are unassigned
before getting status reports...
@Vadim Petrochenkov makes a good case for WONTFIX there :)
I knew something was wrong… I hadn’t zulip open :D
[1.30 beta] Macros recursion limit detection changed #54464
to be wontfix
lets close #54464 as wontfix, yeah?
we can't treat small recursion level changes as regressions
next: "[1.30 beta] Multiple applicable items in scope" #54474
forgot about my T-compiler filter
[1.30 beta] Trait bound is not satisfied #54467
fixed on nightly
will revert infer_outlives_requirements for beta
right, we discussed. cool cool
[1.30 beta] Multiple applicable items in scope #54474
tagged as T-libs
yea looks T-libs
so ... let tehm deal with it ...?
yea nothing we can do about it
but they can stay assigned to me
sure that needs to be done quickly
[1.30 beta] More chars considered alphanumeric in 1.30 #54481 is T-libs
next is: "[1.30 beta] Compiler hangs when compiling primal crate for armv7-apple-ios" #54627
anyone want this?
(initial hypothesis is that its due to LLVM upgrade)
yea that makes sense
I don't have much time these days
@nagisa could you perhaps take point on this?
not sure if there's much we can do beond confirm that its due to the LLVM upgrade
The noalias regression is first on my priority list
but its good to at least double check that?
but I can at least try to minimise and report to LLVM
Okay, how aboutif I assign to you
and if you do not have time soonish
you let us know
and we'll find someone else
and #54754 is last, but it already has the PR we already discussed I think
I'll assign myself to it just so it has somene to blame if things go wrong
okay that was te stable-to-beta regressions
but we're 7 minutes over time. :sad:
(there's only one regression-from-stable-to-nightly, and it was filed 6 days ago: #54654 . It can wait until next week if it doesn't get addressed in the meantime.)
anything else important?
there's a waiting on team
I meant to link to #54592 in particular
namely "Support for disabling PLT for better function call performance" #54592
it was waiting on check boxes; I just got mine just now
(just @Oli and @Zoxc left )
looks like it was also blocked on @Zoxc and @Oli but any one of you would suffice I think
finally we have the nominated issues: https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen%20label%3AT-compiler%20label%3AI-nominated%20
but they can wait
I overlooked that ping when going though my notifs :confused:
@bors r+-after-fcp wanted
@nagisa sometimes I don't wait for the whole FCP in cases where we could always back out on controversy :)