Hi @T-compiler/meeting ; the triage meeting will be starting in 2 hours 32 minutes
I will be doing pre-triage in a parallel topic
Today we are scheduled to check in with WG-traits
@nikomatsakis are you the rep for WG-traits?
:construction_worker: seeking help: Anyone want to look into fixing "proc-macro param attrs dropping first attrs in impl fns" #64682 ?
:construction_worker: seeking help: Anyone want to look into "error: internal compiler error: unexpected panic: inconsistent resolution for a macro" #64803
nikomatsakis are you the rep for WG-traits?
Lets get it started in here
We dedicate the first 5 minutes to announcements
I'm realizing there's something I want to add to today's agenda; whether its an "annoucement" per se is debatable
Well I'll just put it this way:
:paperclip: agenda item: selecting co-lead for compiler team
Announcement: Planning meeting tomorrow
Same crab time, same crab place :crab:
oh yeah, lets link the proposals that we'll want to schedule
Not too late to add more :)
Right: In case people aren't aware, we're trying to use a lighter weight process for proposals than we originally envisaged when these steering meetings first started
So you definitely have time to put up your own. Its literally as easy as opening an issue on that repo.
mir::Places are not recursive anymore (thanks @Santiago Pastorino ), let us know if you have any usability problems
very cool stuff!
oh also, if you all haven't seen
cargo -Z timings yet
it is very cool
and can be used with rustc
(i had a link with a demo, but my attempt to use it errors due to hitting a rate limit)
Oh btw, AST borrowck is being removed, https://github.com/rust-lang/rust/pull/64790
@simulacrum has also done some awesome work integrating the
rustc -Z self-profile info into perf.rlo
oh yeah! I saw that!
Oh yeah, you should definitely click around on perf.rlo!
to find your own, in the "comparisons" page, click on the measurements
okay so I'll assume that's all today's announcements. (If anyone wants to add more, priv msg me and I'll allocate time at the end for them.)
e.g., those timing numbers, or the % change numbers (you can see they are links...)
so first lets go through the two beta-nominations
To be clear ... I think the timing right now is that we're talking about backports into the beta that has already been cut. @centril , can you confirm that?
Yes beta has been cut, this PR did not make it, I believe
@pnkfelix yes, beta meaning 1.39.0
anyway it seems harmless enough to me.
(and I haven't seen any opposition in the emojis)
fixes an ICE, :ship:
beta-nom: "Rustdoc render async function re-export" #64599
Impl seems simple and it's early so I think it's safe
will get much testing
yes okay I'm okay with that logic
if something comes up we'll deal with it
I'm inclined to err slightly (but not that far) in favor of backports for async-await, esp. in these early weeks
Great: there aren't any stable nominations (unsurprising given timing w.r.t. release.)
just because "never get a 2nd chance at a 1st impression"
still, an ICE or bug will spoil that 1st impression even more, so only slightly :)
/me just realized (again?) that our long-standing link for listing nominations has
is:issue in its query
/me tries to make mental note to fix that later.
okay I see 6 nominated PRs and issues
part of my strategy here is to try to limit too much discussion: If something needs more than a few minutes of discussion, then we should consider a design meeting
nominated 1/6: "Make all alt builders produce parallel-enabled compilers" #64722
this is tagged both T-compiler and T-infra
not sure if there's much for us to discuss at moment, beyond (perhaps) we'd like this?
I'm OK with it
I guess this is the important bit:
Going to nominate for infra and compiler teams as I'd like to check that the claims I've made are true:
* usage is minimal, mostly to deal with LLVM-related regressions (-Zthreads=1 is probably enough to sidestep any bugs in parallel that could impact this)
* we are comfortable altering them in such a "big" way.
I feel good with those two things; the main thing here is that we do plan to keep llvm assertions enabled
which implies that this will help flush out parallel bugs but won't be a good test for how fast it is
one thing I mused about recently was whether we could have any hope of using a tool like
rr on one of these builders to try to capture a trace when things go wrong
but I don't know if that's anywhere near feasible.
Anyway, it seems like no one present objects
I'll write a comment on the issue saying as much (and pointing out niko's point above about LLVM assertions)
nominated 2/6: " proc-macro param attrs dropping first attrs in impl fns" #64682
I left this nominated because I wasn't comfortable prioritizing it without feedback
or wait, that was a different one. :smiley:
New stable feature, must be investigated and fixed -- I have the context I guess so I should have a look?
this one I did prioritize as P-high. But I wanted to see if anyone wanted to fix it
@centril if you don't mind, that would be great
I will assign you for now?
nominated 3/6: " Deprecate
#[plugin_registrar] with removal deadline: 1.44.0" #64675
I haven't caught up with the discussion. We might not be able to remove it in 1.44.0, but I'd like to at least emit a warning so we don't get any new uses of it
Anyways, that's what I was going to say on the lang team meeting
I suppose this as much as anything should motivate me pointing out a Pre-RFC I posted this morning: Pre RFC Cargo: report future-incompat
(at least I think this is related to future-incompatibility stuff in general)
@pnkfelix N.B. this is an unstable feature
... but I'd like to at least emit a warning so we don't get any new uses of it
ah warnings can be good. One might ask whether it would be silenceable (ie a lint) or not.
pnkfelix N.B. this is an unstable feature
Yea, not doing it as a lint was just much easier
Have we any idea how many users we have or if there have been new users arriving?
is the warning set up in a way where users are directed to give feedback regarding the feature?
Don't think so; but people do pop up on internals every now and then saying they want to depend on it
@pnkfelix what sort of feedback would that be? I don't see this feature ever getting stabilized
Giving out access to the HIR in a stable form or the type system feels like a complete non-starter
anyways, we have limited time in this meeting
I guess the question is whether people know what options they have for migrating away from it.
I'll have to look more closely at the thread, but it seems clear that we can't out-and-out remove the feature yet without more work on a replacement. Warnings might be ok, though I think that's not obvious to me (e.g., I don't know that servo wants to get a warning on each build)
lets move along, it doesn't sound like anyone is vetoing this
I am vetoing it :) I think maybe a design meeting might be in order, though
(e.g., I don't know that servo wants to get a warning on each build)
I'm pretty sure they're already unhappy about pre-existing cases of this
@nikomatsakis let's talk on the lang meeting
nominated 4/6: "Rustc panics while compiling gstreamer in RLS" #64659
this is the one I didn't know how to prioritize
how are we feeling about panics caused solely by RLS at this point?
P-high? Or P-medium?
My intuition is P-high, but I worry about whether we are dealing with these properly
I feel like that is P-high
and also whether we are generally pushing towards rust-analyzer anyway?
I'm not sure if @Igor Matuszewski has any thoughts on looking into it
I'm happy to tag it as P-high for now
might be a duplicate of that other long-standing RLS issue?
I just want to make sure we have people able to make progress on RLS issues
it seems like it's a recent regression
I'll tag as P-high then. We can move on beyond that.
(except that maybe it's a pre-existing bug that was masked)
nominated 5/6: "debuginfo/pretty-uninitialized-vec fails with
Cannot access memory at address 0x7fffff7fe000" #64343
I would be extremely happy if this one was treated as P-high because it is preventing me from doing
./x.py test and so it harms my ability to do rollups and such
oh, right, this nomination is semi-coupled with PR #60826 " WIP: Implement new gdb/lldb pretty-printers"
I would so wish that we had somebody taking care of debuginfo
so here's the question: Are we willing/able to maintain debuginfo stuff
if we do, then its P-high, no problem.
That said, I don't know how to fix this personally.. gdb and me are not buddies.
if we don't, then can we afford to keep these tests?
(because the test failures do cause problems for others elsewhere)
Yea, it's mainly the test failures that are a problem for me
Maybe this should be discussed in a steering meeting?
I'm willing to throw a proposal up. The question of "what are we doing long-term about debuginfo" seems pretty broad
I thnk that seems good -- maybe we can get the author of #60826 to attend
and the only way it would be resolved here quickly would be if someone present said "Oh hey, that's my speciality, I'll take care of it myself."
I feel like this might be a place where it would behoove us to "call for help", too
/me thinks of another ICE-breaker concept
okay I'll make a proposal.
basically saying "we need help to maintain this or we may have to remove it"
nomination 6/6: "apfloat: improve doc comments" #63416
I'm bringing this up because @RalfJ wanted us to weigh in
there a couple different things at play
(no -- to a port of an upstream component)
I personally agree with @eddyb that we shouldn't have those kinds of deviations localy
wait, hold on, sorry I'm not being clear
so skade is looking into the licensing issue, which is what I'm waiting on
so, right: The PR itself is targeting a port of an upstream component
once that's solved, we can do https://github.com/rust-lang/rust/issues/55993
@eddyb I wasn't even aware of a potential legal issue; I thought this was merely a process one
In terms of it not making sense to maintain deviations like that ourselves
the licensing nonsense is why apfloat is still in-tree
I don't think that landing these changes really interacts with the legal issue per se..?
LLVM relicensed everything since I ported apfloat btw, which has fun consequences
there's something else I did want to mention, though
anyway the important thing is to keep the changes separate enough IMO so we can tell things apart, this is annoying in-tree
Is it your intention @eddyb that the library we should just not touch the libary until it is extracted and licensing clearer up, unless absolutely necessary?
when someone suggested to @RalfJ that they should close their PR
( I can get behind that, we should just say it )
@RalfJ responded by saying "hmmph there is precedent of commiting tiny doc changes to apfloat"
what do you think of this approach? https://github.com/rust-lang/rust/pull/63416#issuecomment-524545946
some context: there were changes not approved by me and even an out-of-tree copy that also didn't involve me and I hope none of that bites us when the licensing is sorted out
@eddyb I'm getting there
RalfJ responded by saying "hmmph there is precedent of commiting tiny doc changes to apfloat"
the aforementioned precedent was, in two out of three cases, broad doc changes made by @Alexander Regueiro
oh I haven't even seen those
when I say "broad", I mean across the rust-lang/rust repo
the change to apfloat itself was narrow
this is the comment from @RalfJ with links
I guess I wanted to call attention to this because even if there was a precedent set here, I don't think we should follow it.
if we do https://github.com/rust-lang/rust/pull/63416#issuecomment-524545946 then we can keep those changes, and @RalfJ's PR, but have them separate enough from the port itself so they're more like the patches we have on top of LLVM
10 minutes left in meeting
what do you think of this approach? https://github.com/rust-lang/rust/pull/63416#issuecomment-524545946
my take is that this sounds like more work than is warranted by some minor improvements to the docs; but if we do want to prevent any changes from landing, moving to a separate repo is prob wise
10 minutes left in meeting
(and maybe even upstream some stuff to LLVM if we have the time to or it's an important bug fix)
Anyway, does anyone here want to argue against just closing this PR?
(TL;DR if @Florian Gilcher or @eddyb think that avoiding this sort of thing will help in sorting licensing stuff out, that seems like a perfectly good reason to hold off, I'll post in the thread)
I would not want to close the PR, I just wish we had all of this sorted out already (it was tricky because I kept forgetting about it or not knowing who to talk to)
okay I'll let you all post in the comment thread for the PR then
and not attempt to make any decision one way or the other about it now
So that's all the nominations, yay
wait can we use S-blocked here?
@nikomatsakis do you want to give an ultra-fast update from WG-traits?
to avoid triage from threatening to close the PR
Slowly coming back online. We don't yet have a full roadmap yet.
I've dedicated however some big blocks of time each week to get things up and going.
Currently pursuing a "few" leads:
- improving the chalk api and integration into rust-analyzer (avoiding the need to enumerate all impls, all structs, solving cases where we do too much exploration)
- improving chalk's approach to lazy norm based on that
- investigating altering the way rustc integrates to integrate at a higher-level, like rust-analyzer
- extending chalk to support dyn/impl trait types (@Keith Yeung)
- extending chalk to support specialization (@Sunjay Varma)
- exploring how/why const generics is blocked on lazy norm and how to fix (largly @Aaron Hill)
- enabling trait upcasts (largely @Alexander Regueiro)
- fixing the
dyn Trait coherence soundness issues (@blitzerr and I)
- landing the "dyn Trait"-WF changes (me)
(Zulip, why no bullet list?!)
I expect to get a regular meeting up and going to establish a clearer roadmap "RSN", maybe next week, probably adopting a "focus issues" approach
Oh and Jonas Schievink is working on associated_type_defaults :tada:
Also I think I owe feedback to basically all those people :eep: -- working on it!
Ah, yeah, true!
@Ariel Ben-Yehuda landed the impl reservation stuff just now
(Zulip, why no bullet list?!)
! may finally get shipped
oh yeah, and fixing some ICEs (largely me at this point, but we'll see :)
anyway, that's it!
Great thanks @nikomatsakis !
sounds very exciting about chalk!
In other news, we released a new version of Rust today: https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html :tada:
"A truly boring release" :P
I've got a draft PR to create a blog where rust teams can post announcements, meeting notes, and the like. I hope we'll be able to use this more in the future to post minute notes, design meeting thoughts, calls for help, etc
crap I forgot about my agenda item
just to get the mental juices flowing (ewww?)
NIko and I have been talking
Niko wants to share leadership duty of the compiler team
He asked if I would be willing to be co-lead
and I would be happy to serve in that role
@pnkfelix aren't you, de-facto?
but I was not comfortable taking the role without first at least bringing it up here
to give people the chance to put their hat in ring
doing it in overtime of a triage meeting
is not exactly democratic
but then again, maybe that's the ideal time since I have to go AFK at this point anyway. :wink:
I'm fully in support of you becoming co-lead, @pnkfelix!
@nikomatsakis regarding https://github.com/rust-lang/rust/pull/63416#issuecomment-535544376 - do you think it's okay to mark the PR as S-blocked?
Okay well you all can nonetheless feel free to find some side-channel to discuss your misgivings with such
that said, thank you everyone in @T-compiler/meeting for attending!
and please do come to tomorrow's planning meeting!
pnkfelix aren't you, de-facto?
so this was indeed why I talked to @pnkfelix about it, but I am happy that he brought it up here and I'd like to hear from others if they think they want the role; along those lines, we also created a design meeting proposal to talk about heping to further define the roles in the team, including what exactly co-lead means. (In my view, it means a few things: most obviousy representing the team in various official places, but also mediation and a sense of "buck stops here", i.e., generally trying to ensure that things are proceeding as they ought)
I had a more elegant description somewhere but screw it ;)
Congratulations, @pnkfelix !
@nikomatsakis I think it's okay to merge PRs, if we get signoff from the person contributing to allow us to relicense