Hi @T-compiler/meeting ; the triage meeting will be starting in 2 hours 17 minutes
I will be doing pre-triage in a parallel topic
For this week's WG checkin, we have WG-Async/Await and WG-Diagnostics scheduled.
last week I created a dedicated topic in async-await for gathering announcements. So far, nothing posted there.
similar story for dedicated topic in wg-diagnostics
(but, its a new system; probably too soon to declare failure.)
in any case, since both of the leads for WG-async-await are USA-based, I expect they will not be around due to Thanksgiving holiday there.
but for WG-diagnostics: Is either @oli or @Esteban Küber around to potentially provide an update at the time of the T-compiler meeting? (Or send me one ahead of time?)
:wave: I'm here
:construction_worker: volunteer requested: need someone to identify (via bisection) which PR fixed this: "rustc crash on 1.39.0 stable with combination of async
and ..
" #66618
okay I've got my draft for today's agenda prepared
Hi @T-compiler/meeting! Add a :wave: emoji to show you're here :)
We'll start off with five minutes for:
perf has been fully migrated to new backing hardware for the collector
perf has been fully migrated to new backing hardware for the collector
what does this mean for us in practice?
in theory, nothing
in practice, it means that the collector is theoretically more accessible to e.g. ssh access for particular contributors
(this is largely not useful -- try builds + rust-timer queue are good enough -- but if you need to check something, contact me, and I can try and hook you up)
the new hardware is also a tad larger (6C/12T vs. 4C/8T) which might make perf a bit faster
we have both windows and linux running on github actions!
at the moment they take 1hr25min for a full build, but that's going to slow down as we re-enable llvm and debug assertions on the slower builders
(we disabled them on the slowest azure builders to avoid going over 4 hours)
Awesome
also, macos is still probably going to be on azure for a while (we need macos 10.13 to avoid dropping support to i686 apple, and gha only has 10.15)
so I guess y'all should expect ~2hrs for a bors auto build once we land that
(all from me)
Lets get the rest of the meeting started. (If anyone has an additional announcement to add, privmsg me and I'll allocate time at the end for it.)
so, as previously mentioned, here is our agenda for today
beta-nominations first
beta-nom 1/2: "Handle non_exhaustive in borrow checking" #66722
I think if this is okay for nightly, then its okay for beta
(I will admit that I want to read over it again myself. but for now I'll mark beta-accepted.)
beta-nom 2/2: "Fix some issues with attributes on unnamed fields" #66669
(this one seemed like a clear win to me in terms of being "clearly the right thing")
at least in terms of the effects on the test suite
the words "HACK" in the PR itself do give one pause...
the other options are that we: 2. decline to beta accept, or 3. wait until next week to decide on this one.
okay lets beta-accept this
We can accept the beta nom and defer on the stable too
next up, stable nominations
yeah the only stable nom is what we just discussed, "Fix some issues with attributes on unnamed fields" #66669
lets defer to next week on the stable nom there.
okay, next: There are two PR's marked S-waiting-on-team.
One of them, "Turn HIR indexing into a query" #59064, is awaiting a steering meeting. We don't need to talk about that here.
The other, "PowerPC C ZST ABI fixes" #64259, was meant to have follow-up discussion, which did happen in a parallel zulip chat
but the discussion sort of died out about three weeks ago
part of the problem here is that I don't know if anyone on the team is in a position to evaluate these changes.
or at least is in a position to drive the conversation forward to consensus
Okay well clearly no one present here is volunteering to take over
lets move along. (Maybe if we are still in same position next week I will self-assign or something)
We have 37 open P-high issues. 21 of those issues are unassigned
Can you think of anyone that _could_ take it up (without considering whether they have the bandwidth)?
that was a general alert. Maybe I should just put that as part of my standard announcements at the beginning.
Can you think of anyone that _could_ take it up (without considering whether they have the bandwidth)?
I don't know. Its pretty niche, I think.
Regarding that list of P-high issues: I did mention at the outset of the meeting that I'm seeking a :construction_worker: volunteer to track down where this bug was fixed: "rustc crash on 1.39.0 stable with combination of async
and ..
#66618
Beyond that, a lot of the other issues might fall under a common umbrella topic (e.g. normalization issues, which I'm hoping to spend some time on soon).
Lets move on to the concrete nominations.
I tagged "COPYRIGHT file is wildly out of date" #63232 as T-compiler, because I wanted to use that issue to draw attention to a more general problem
In last weeks' planning meeting, we opted not to schedule a Friday meeting dedicated to licensing (see also compiler-team#220 and @Florian Gilcher 's draft guidelines )
but we probably do need to identify a group of people willing to do some work here, in the short term, to deal with the licensing mess we've made for ourselves
there was also a parallel zulip topic where @Florian Gilcher and I were discussing this matter.
given the nature of the problem, and the fact that I don't expect many people to volunteer to manually review our source tree to try to identify licensing problems
I mostly wanted to use this spot in the meeting for two things:
the current example that is running through my mind is someone who adapted code from gcc for some compiler-builtins support library.
in case I'm not being clear: We are not supposed to accept code like that into this project. Our license is not compatible with accepting such code.
(it doesn't matter if you provide attribution. It doesn't matter if it was a trivial algorithm that no one could have patented; copyright law doesn't work that way.)
anyway, I or someone else will probably be talking more about this in the future, probably via multiple channels to try to catch everyone's eyeballs
next nominated issue
nom: "under latest MinGW, cannot link with C code using stdout" #47048
we started talking about this last week and then got side-tracked.
at this point, here is my question regarding this bug: What is the Tier 1 platform we supposedly support here?
if our CI is fixed to a narrow (and old) set of versions of mingw, then we probably shouldn't be claiming Tier 1 support for anything except those versions, right?
(independently, it does sound like some people are discussing solutions on issue #53454 ...)
And another question: Do we have any active MinGW (MSYS2?) users present who would be willing to try to help address this?
hey @T-compiler/meeting , should I just switch to WG-checkins so that we can adjourn early?
... okay then ... let's hear from @oli regarding WG-diagnostics
wg-diagnostics is moving slow on implementing all the diagnostic rendering out of tree in https://github.com/rust-lang/annotate-snippets-rs/
but there's new work happening since last week
great, thanks @oli
(@pnkfelix I'll take the :construction_worker: #66618)
there were a few other nominated issues on the agenda, but I figured I could demote them to mere announcements
unless someone convinces me that I need to use rfcbot merge or whatever to poll the whole T-compiler team
(but I'm not inclined to do so; I'd rather r+ the PR, with rollup=never, and then let people find out if there are real performance regressions from it)
lang already discussed Box and perf numbers seem good, evenrollup=never
is probably overkill
namely, @Simon Sapin has put up PR #66841, which adds the intrinsics you'd need to recover the old "so awesomely fast and who cares about UB" behavior
okay, that's all from me
bye, thanks for joining @T-compiler/meeting !
@pnkfelix what happened to never_type?
pnkfelix what happened to never_type?
are you asking about an issue that should have been on the nominated list?
I know that I curated the list that I put up for this week, rather than dynamically selecting from our usual overload of nominated issues. But I don't recall anything about never_type there, except for maybe the fallback issue which may be P-high, not nominated?
oh and there's the bug about Infallible
, maybe you mean that, @centril ?
yea that one
probably should circle back to T-lang?
to be honest I wasn't certain from reading over the dialogue there whether that was a T-compiler matter to resolve
I was joking on a rust-lang/reference issue that "I wonder how long it lasts" (the stabilization...) :D
but at the same time I failed to tag it as T-lang
okay now added comment to #66757 and tagged it as T-lang