Hey @T-compiler/meeting -- @pnkfelix told me he is not able to be here today. If anyone else wants to run the triage meeting (@nagisa?) that would be great, otherwise I can be around at the usual time (in ~4 hours) but I won't be able to do any pre-triage.
/me afk for now
I will likely miss most of the meeting today as well.
PSA: I'm out sick and won't be online or review PRs for at least the rest of the week.
Oh dear! Poor compiler team
Hey @T-compiler/meeting! Triage meeting starting now. We've got a bunch of people out today so we're just going to do the best we can. =) I'll probably cut right to any nominations and other urgent things. According to the calendar, this week we have a check-in from #wg-traits (cc me, @Jack Huey) and #t-compiler/wg-polymorphization (cc @davidtwco).
OK, let's get started I guess. We'll kick off with
From last week:
(we discussed backporting this in today's T-compiler meeting. We are not certain what warn! will do here, in terms of what an end-user will see, so we held off on approving this change until after we've double-checked the default UX there...)
Yeah I was bit dubious about the
warn! call here though it seems like this PR is basically harmless
But I guess I don't care enough to make a big thing out of it. I'm content to backport, that seems to be the consensus opinion from the emojis above :)
There are none that are not already approved.
I added a new beta-nominated PR
seems ok to me
though I can't register a vote easily because of how emojis work:)
Did slice patterns get stabilized?
They did yes
Not a lot of votes above :) I'm inclined to approve.
If there are any concerns though please do raise them
/me does not vote on their own PRs... it feels wrong :D
OK, approved, moving on.
Just entered FCP, nothing more to say here probably
Created an internals thread in response to our last discussion
The poll there had 71% in favor of minimal details
I personally agree with the majority; "overloading" is a real concern
I am tempted to say:
Btw; I'd like to highlight a new soundness hole:
Static lifetimes checking regression in rustc 1.41.0 #69114
OK, left a comment, feel free to add your own thoughts.
It would be good to fix that one sooner rather than later and consider stable backporting.
I wonder if @Matthew Jasper has time for deeper investigation
left a comment
I'm not sure if it's really waiting on our team though :)
did I forget about it again
for another month
I don't know what current status is
most recent comments suggest
yeah this ZST stuff is much rarer than the other things fixed
I think maybe you were going to prepare some minimal PR, @eddyb, with the apprach you preferred? I remember discussing that a bit, at least.
yeah then I forgot about it, clearly
I can leave a comment pinging the author saying "we'd prefer to do this minimal thing"
(i.e., from the team)
I think you outlined what you had in mind on a comment somewhere, right?
I feel comfortable anyway taking minimal steps first and not risking over-generalizing
Or you can just do that :)
I see this comment from you:
Wait, you've removed the target_env == "gnu" - this workaround only makes sense in that case, because ZSTs in C are a GNU extension.
I think it's split over several comments but what I had in mind is like a one line diff, we should've just done it months ago Q_Q
I remember you giving some small diff, yeah
OK I'm going to leave a comment saying "eddyb has a one line diff" :P
no, you need to actually pester me to put up a PR >_<
no, you need to actually pester me to put up a PR >_<
/me adds a "to do" item: "pester eddyb to put up a PR"
(I am actually doing this :P)
Ooookay, moving on.
we won't get through them all so maybe people can scan for ones to prioritize, I will do the same
just needs prioritization, I guess
P-medium I think
P-medium I guess
has PR I think
Static lifetimes checking regression in rustc 1.41.0 A-borrow-checker A-lifetimes C-bug I-nominated I-unsound :boom: P-high T-compiler regression-from-stable-to-stable
#69114 opened 16 hours ago by ilyavenner
didn't we just talk about that?
Discussed before; Let's assign to Matthew?
sure, ok, I'll do so and leave a comment
ICE: multiple @ bindings of slice patterns, e.g.
[a @ .., b @ ..] A-slice-patterns C-bug I-ICE I-nominated T-compiler
#69103 opened 21 hours ago by memoryruins
Has PR, labeling as P-high due to impending stabilization and removing nomination
you would think
*p = &n where
p: *mut &'static T would still error if
@eddyb let's discuss on issue
oh yeah I didn't want to spam it and I was too slow here :P
Rustc overflow its stack when using impl Trait and the struct containing the function itself A-impl-trait C-bug I-crash I-nominated T-compiler
#69096 opened yesterday by lszxb
/me is a bit confused about who is trying to drive :)
I guess I did ask for people to make some suggestions...
@nikomatsakis two drivers can be more effective :P
I'm feeling a bit overwhelmed :)
I was paging back with stuff and saw I had missed discussion is all
anyway, it's fine, we can look at #69096
Looks like codegen issue
Do we think this should... compile, not... ?
is it a regression? probably not
I feel like we added some code to check for this sort of thing
I guess the type is not infinite
the problem is probably occurring when generating the symbol name, @eddyb, does the symbol name somehow include the return type or something?
Godbolt says this regressed in 1.30.0
used to compile
ah, interesting, let's tag it for the cleanup crew
As far as priority, it's a regression, which makes me tend towards P-high, though I'd otherwise have probably said P-medium
Yeah; although I could see P-medium being justified as "no one said anything for so many releases" :P
but let's do p-high
@nikomatsakis how can I do the one-line patch when #69096 is far more interesting lol (left a comment already)
I think this is "close as expected behavior"
I naively thought we weren't wasting time with LLVM type names anymore, I wonder what kind of compile time wins we can get from skipping that
I think the problem here is we don't really know the code that reproduces it
#[track_caller] can't come soon enough
I'm inclined to un-nominate and re-nominate if we have an example.
but I can just leave it a week, don't care
@nikomatsakis let's call it P-high though?
we do now though? just not from the original poster
I don't believe we have anything that is narrowed down to something actionable
let's ping cleanup?
but I'm not entirely sure
Yeah, I was debating
this is presumably reducible https://github.com/rust-lang/rust/issues/68801#issuecomment-582920167
sure, cleanup crew seems reasonable
something about that comment made me suspect it won't reproduce but perhaps I was wrong
let's try cleanup crew then, seems good
re: priority, the ICE is pretty bad
it's not a regression afawk?
Yeah, hard to say, especially witout a minimal example
I guess P-high is ok, given the uselessness of the ICE
we could leave nominated and revisit
I marked as P-high. Let's do one more then pivot to check-ins
@Esteban Küber btw, why is https://github.com/rust-lang/rust/pull/68938 nominated?
caused by Promote references to constants instead of statics #67000 (cc @Santiago Pastorino, @oli)
We knew about this regression in the PR, maybe you remember that discussion. In #67000 (comment) I finally came to the conclusion that the reason we regressed perf here is that before that PR we didn't actually evaluate the promoteds, we just created pointers to them. #67000 causes all promoteds to get evaluated immediately when their use site is evaluated. Basically any real program would already have done this work as collect would have evaluated the constant. Only if you have loads and loads of dead promoteds can you see the difference.
Sounds like wontfix?
going by oliver's note
Was going to say the same.
Let's start with #t-compiler/wg-polymorphization (cc @davidtwco)
@davidtwco wrote me this to post in case they're not around:
Since this is the first update to the compiler team meeting, this working group is my work for my master's thesis - it aims to implement an analysis to detect when functions could remain polymorphic during code generation. Hopefully this will reduce the amount of LLVM IR generated and improve compilation times.
So far, I've got a basic analysis working and I've got it integrated into the compiler such that a
codegen-unittest that I've written pass with the analysis turned on and working. For the last couple months, I've been working on getting the compiler to bootstrap with the analysis turned on, and fighting ICEs to do so.
I've not been able to spend much time on it recently due to other university/work drains on my time, but progress should pick up soon.
Specifically the starting point is to detect functions that are generic but have some type parameters that are fully unused (this arises commonly with closures)
Is there anything people can do to help, @davidtwco ?
I'm not sure there is at the moment, it's just me finding some time to get back to it and work through the remaining ICEs.
OK. I forget if you said, is the branch pushed somewhere public?
Anyone who wants to can leave some review comments on the approach though, here's the branch: https://github.com/rust-lang/rust/compare/master...davidtwco:issue-46477-polymorphization
(it's long overdue a rebase)
OK, 5 minutes left, let's do a quick #wg-traits check-in
We are trying to get the "sprint concept" up and going again
And we had a recent discussion about which things to focus on
I was thinking before this meeting I shuold've maybe prepared a summary :)
but there's a mix of work on chalk / work on rustc
the idea is to sort of migrate rustc to integrate ideas from chalk and make it able to support GATs etc, while also improving chalk and working towards the rustc-integration we want. The hope is that the two can approach each other and eventually be readily merged. (But without blocking everything on that day.)
we've got some new blood coming in, which is great
we had some notes on the topics in this dropbox paper, still working out some of the details
I guess that's about it :)
Any final comments? We're at 58 minutes
OK, thanks everyone for attending! :heart:
Sorry I wasn't able to come for the check in :/ was busy with work