Meeting in 5 minutes, @T-compiler/meeting
Lets begin I guess. First, are there any announcements?
I did some pre-triage, I expect the coming weeks to be quite quiet in terms of actionability on issues, but that is fine, I think.
to add to the quiet vibe, I've been spending some time on #wg-grammar-related things this week (but feel free to ping me if you need me for something)
Another thing, we will likely have no WG check-in this week at least, because I have no idea where the schedule currently is.
Okay, so moving on, I’d like to get backport nominations handled first, there quite a few of them.
This is a tiny PR, fixes an ICE, well tested.
Note that this PR is also nominated for a stable backport, on which we will vote later.
It appears that the consensus is to backport.
The next one is Cancel unemitted diagnostics during error recovery #62666
This is similarly small, but hasn’t tests, fixes an ICE.
Perhaps a good idea to vote on Handle errors during error recovery gracefully #62604 at the same time, as these are strongly related
That one adds tests.
Next up is Correctly break out of recovery loop #62607
(again the vote is for a beta-backport, we’ll vote for stable backports later)
Much like the previous PRs, small, tested, fixes ICE.
Okay, I see a majority.
Moving on there is a pair of related PRs, first Emit warning when trying to use PGO in conjunction with unwinding on Windows #61853 and then Only error about MSVC + PGO + unwind if we're generating code #62615
The 2nd PR is essentially a revert of the first
The first PR seemed semi-controversial last week and I volunteered to find an alternative approach which is #62615.
I suggest that we vote for the end result, which would occur after both PRs are backported in correct order.
In essence that would mean that the behaviour implemented by the 2nd PR gets backported.
This fixes Firefox use-cases I believe.
so it isn’t exactly something that we keep broken.
@Wesley Wiser okay, in that case I’ll reject the backport for the Emit warning when trying to use PGO in conjunction with unwinding on Windows #61853 now.
Please vote for/against backporting Only error about MSVC + PGO + unwind if we're generating code #62615 on the emojis above.
I find the approach there okay, but I would also ask @Wesley Wiser how confident they are in implementation
one question imediately arises is that the title says "when we are generating code"
but what the implementation really checks for is
sess.opts.prints.iter().all(|&p| p == PrintRequest::NativeStaticLibs)
PrintRequest::NativeStaticLibs is special in that it's the only
but it is possible for code to be generated with PGO without anything being printed at all as well, isn’t it?
rustc -Zwhatever-flag-that-enables-pgo --emit=link src/lib.rs
Am I misunderstanding the initial issue?
Oh, I see,
all() is also true, never mind me
Yes, but in that case
sess.opts.prints.iter().all(|&p| p == PrintRequest::NativeStaticLibs) will return true which causes the error to be emitted.
Iterator::all() on an empty iterable returns
Okay, I guess 3 for to 0 against is positive enough. Gimme a sec to mark as accepted for backport.
Final beta backport is rustc_target: avoid negative register counts in the SysV x86_64 ABI. #62380
Unlike the other backports, this is not as trivial, but we have tests!
Fixes a soundness issue.
A long standing one, though, so the only thing a backport achieves is fix arriving to users sooner.
@oli want to elaborate?
I'm fine with backporting, just don't think it's overly relevant to backport it
Does it help if the backport is motivated by Firefox folks having to actively work-around this issue for extra 6 weeks if this does not get backported?
Got it, okay, accepting for backport.
yeah I think the only user who cares right now is Firefox, given nobody seems to have hit it so far
(you need a combination of floating-point, integer and struct arguments that is kind of rare in FFI outside of code like this that communicates internal browser stuff between C++ and Rust)
Two of the PRs we discussed for backport are also nominated for a stable backport. While the release team has expressed no intention for a stable point release this cycle, we are supposed to handle these nominations disregarding this piece of information
The PRs are:
Correctly break out of recovery loop #62607
Note that both ICEs fixed by these are already stable-to-stable regressions
In that sense I personally feel these are not critical enough to backport to stable, even if we did end up making a point release.
It is not like these fix a soundness issue or anything like that.
(I myself vote :stop:, need more votes for consensus :slight_smile:)
Okay, lets proceed, feel free to vote while meeting is still in progress and I’ll check if we reach a consensus there by the time meeting is over.
Lets proceed with a mix of nominated and P-high issues.
The first one I think we should check is STATUS_ACCESS_VIOLATION on 'index out of bounds' Windows 7 with lto and avx #62762
it appears like a fairly serious codegen issue to me, the question is whether anybody wants to be assigned on this?
@Nikita Popov perhaps?
I guess I can assign to myself and Nikic seeing as they are already somewhat actively interacting with the reporter.
Spurious unused variable lint warning on enum with no variants #62083 is nominated for a T-compiler decision on what the compiler should be allowed to do
I essentially share pnkfelix’s opinion on this issue
Are there any objections to closing this as WORKS-AS-INTENDED?
Nope, this is all perfectly fine imo (other than it could have more lints complaining about dead code)
There is then ICE: Rust spins when referencing associated types in
where clause #62430
Ah, never mind I assigned myself on this.
There is ICE: Generic type alias to invalid type crashes during type check on latest stable #62742
There are plenty of similar issues but those reproductions all involve const generics.
Would be great to have somebody investigate this, but I’m not sure who the best person would be. Also a P-tag. Looks P-high to me.
Any objections to P-high?
Okay marked P-high.
With 3 minutes remaining for the meeting, I think it is fine to check back on the stable backport votes and adjourn.
#62668 seems like pretty :stop:
and #62607 is somewhat in the middle with 1 vote difference in favour of :stop:.
Thus rejecting both for a stable backport I guess.
With that the meeting is over, thanks all for exercising your right to vote :slight_smile:
If any one is interested in reviewing #62615, I'd appreciate it! :slight_smile:
By the way, is Niko already on vacation?
Yeah, I believe so
(I need to decide whether to reassign some PRs or not.)
Yes, both @nikomatsakis and @pnkfelix are on vacation
I'm kinda back, still digging myself out of the 1k notification hole that my vacation dug for me :D