Hi @T-compiler/meeting ; we’ll be starting the weekly triage meeting in about 46 minutes.
The current agenda, prepared by @WG-prioritization , is here: https://hackmd.io/3dTKNk1_RiK3NOZMfyOldw?view
@nikomatsakis and @tmandry , is there anything to report from WG-async-foundations ?
and likewise, @nikomatsakis and @Jack Huey , is there anything to report from WG-traits ?
Hmm. :) Yes.
(sorry was about to post the invite)
(in either case, feel free to put it directly into the above linked agenda
No problem @apiraino , I just happened to be here
Hi @T-compiler/meeting , the weekly triage meeting is starting now. Leave a :wave: to show that you're here
Lets start off with 8 minutes for
here is "current" list of proposals: https://github.com/rust-lang/compiler-team/issues?q=is%3Aopen+is%3Aissue+label%3Ameeting-proposal+-label%3Ameeting-scheduled (thanks to @Wesley Wiser for posting proposal re sprint retrospective)
which reminds me
I think there was a lot of useful exchange of ideas and gathering of information during the week
Not so much to report on concrete action, though some PR's did land that should have an effect.
Could we try to get a list together of PR's from that week that did land?
anyway we can talk about that at the retrospective, assuming it happens
Wesley Wiser said:
Could we try to get a list together of PR's from that week that did land?
that would be good
(it might have been a good idea to allocate a label on the repo to tag PR's related to the sprint)
lets keep going
invalid_atomic_ordering
lint from clippy to rustc" compiler-team#390hir_id
of the _awaited expression_ into DesugaringKind
" compiler-team#413(Late announcement: LLVM12 bump landed, with the new and exciting features, fixes and, of course, bugs)
@WG-async-foundations by @nikomatsakis and @tmandry:
- Ongoing preparations to launch the "async vision doc" effort.
- RFC #3014 (
must_not_suspend_lint
) was accepted 18 days ago, will be merged soon.- Other ongoing work can be found on the project board.
@WG-traits by @nikomatsakis and @Jack Huey:
- Incremental progress on the binder refactor PR #76814
- Design work on how to move types out of
rustc_middle
intorustc_type_ir
, particularly aroundEncodable
/Decodable
- Work towards GATs stabilization
- Work towards
type_alias_impl_trait
/min_type_alias_impl_trait
stabilization
This isn't an announcement, as much as a general query:
If you have recently used either gdb or lldb to debug a rust program (not necessarily rustc) you recently (within last month lets say) compiled, can you put a :+1: on this comment?
(should I assume you mean "compiled with rustc"?)
Oh yes! That should have been explicitly stated.
(I ask because I recently tried to use gdb on what I thought was a relatively simple program, on Linux, and things didn't work as I expected. So I'm trying to find other people who have used it recently so I can pick their brain to figure out what I'm doing wrong.)
I've been using Windbg recently and the experience is not great there either. So perhaps there are some more general issues that are xplat?
(I'll look at the :+1: 's later and ping those people, perhaps in a dedicated zulip topic)
(when I say "didn't work as expected", I mean like I wasn't even able to get source code references, so step
didn't work, because it didn't have a notion of what the next line of code even was.)
I wouldn't be surprised if there are issues, including xplat ones.
I just am a bit surprised it got as bad as I observed. I don't yet know if my issue is related to cargo as well, or if it can be narrowed to rustc
anyway,I got my list of "people" to bother about this later.
so lets move along
@nagisa (is there a particularly good or bad time for me to try to get a conversation going with you? Is today good, or tomorrow better?)
Oh there's one more announcement worth making
the next release will be on march 25th
that's two weeks away
which makes backport questions all the more important! So lets get to them
T-compiler stable / T-compiler beta
T-compiler
this time.pnkfelix said:
nagisa (is there a particularly good or bad time for me to try to get a conversation going with you? Is today good, or tomorrow better?)
I've a 2hr block later today I have preexisting obligations at, but otherwise any time is fine.
well, this isn't subtle at all /s
This seems fine to me, assuming the performance hit is acceptable for the short term...?
(basically I trust alex to make such calls there.)
however it hasn't landed on nightly yet. :(
I'll just go r+ it now, I think it looks solid, so it has time to bake in nightly
Yeah, I was thinking about it, but there isn't a reason we cannot accept a backport conditional on r+ for nightly.
right, we've done so before
In terms of the performance impact... is this worth saying rollup=never ?
its not going to impact rustc's performance
we don't run perf on wasm, let alone wasi.
do wasm developers ever bisect over rustc commit history to investigate performance?
right
pnkfelix said:
In terms of the performance impact... is this worth saying rollup=never ?
#t-infra has been discussing separating "this PR is risky" from "this PR affects perf"
So okay, I'm not going to post rollup=never here
by running perf runs for some prs even if they get rolled up
a wasi developer looking into performance should be able to build their own rustc
(perf runs won't tell us anything in this case)
(this was more a question about what development practices wasi developers are likely to rely on, such as bisecting over the CI-build)
It seems like no one is objecting here to a beta backport, but no one is pushing for it either
I think we should delegate to libs-impl for the call there
cc @Mara
(to be fair, libs-impl was not tagged on the issue until yesterday)
lets leave it beta-nominated for now
can someone leave a note summarizing what I wrote above?
moving on
hmm. I don't think I want to think about back-porting #82804 to stable
the release is in two weeks anyway. I don't think it would matter.
:point_up: thats more a question from me (just in case the backport was approved)
(unless we don't get it into beta before release)
so lets not worry about stable-nomination for now
--target
behaviour and what people expect when compiling for MUSLThis is waiting a design meeting slot
oh hey. reading back
Ah, ok. I can file a meeting proposal for that.
Great, yeah, Lets make a meeting proposal. Thanks @Wesley Wiser !
And maybe someone can communicate with the PR filer about the protocol here, in terms of setting expectations about how long it might be before the discussion happens?
@Esteban Küber would you be willing to do that? or @nagisa ?
I'll make sure to post a comment in the thread in #t-compiler
okay great, that will do.
and maybe also try to get some dates that work for the PR author.
super :+1: to that
T-libs-impl
this time.println!()
macro prints garbage when inlining functionsfudge
This has been investigated and I think there's a fix for that if my memory serves me right.
On our end or llvm?
yeah comment thread says LLVM
Not sure if we have a PR to backport the LLVM fix.
the LLVM fix itself has landed upstream.
@Nikita Popov any interest in making a backport PR ?
its currently assigned to them
anyone else want to own just the part of making sure the backport PR happens?
I can look after it, yes.
okay great, thanks @nagisa
(obviously best to coordinate that with @Nikita Popov )
next
println!()
macro prints garbage when inlining functionsokay so the theory is that this has the same casue
(lets get another :tada: for the LLVM 12 upgrade. :laughing: )
pnkfelix said:
Nikita Popov any interest in making a backport PR ?
Yeah, I'm waiting for existing submodule update to land first, to avoid conflicts.
awesome
next
@Mara is it best to tag such fix PR's with T-libs-impl as well? Or do you all get to them via the issue list anyway?
oh yes, having the PR tagged would be great
okay. I tagged it already
good to know for future
I'll assume that T-libs-impl will handle it, and also make judgement call about whether to beta-nominate etc
P-critical
issues for T-rustdoc
this time.--release
and with LTO enabled breaks loading files from the filesystem(already discussed, approved for nightly by me, and delegated to T-libs-impl re beta-backport decision)
Unassigned P-high nightly regressions
P-high
nightly regressions this time.A generally positive albeit quiet week though many of the perf improvements were gaining performance back from previous regressions. We'll need to continue to keep an eye on rollups as there were two that caused small performance changes.
Triage done by @rylev.
1 Regression, 4 Improvements, 1 Mixed
2 of them in rollups
Rollup of 8 pull requests #82929
full
builds of keccak-debug
)typecheck
query across different benchmarks though none of the PRs in the rollup seem to touch that query. This might be noise, but it's hard to tellUpgrade to LLVM 12 #81451
full
builds of keccak-opt
)full
builds of deeply-nested-opt
)No nags for this week and the nag from last week has been resolved by #81458.
@rylev: did #81458 resolve something? or did it regress something that was resolved elsewhere?
field is never read:
lint warning" rust#81658T-lang
meetingpnkfelix said:
seems like PR #82738 is the followup that resolved the regression injected by #81458
That is correct
thanks @rylev !
Okay so I ensured #81658 was on our docket. Lets try to summarize it quickly.
Can someone talk me out of just reverting PR #81473 ?
Should we "just" revert PR #81473 on beta-alone, and in parallel improve the diagnostic on nightly?
I think this would be a good idea.
I don't see any reason this "has" to ship in beta and it looks easy to revert.
(I'm mentoring Sunjay Varma to fix the issue, and that will be simpler to tell them that we'll focus on nightly.)
Okay lets just revert PR #81473 on beta. I can own that.
next
strip
tool for that.discussion of this might well be worth a design meeting. Maybe.
or maybe it just needs an owner. :)
(it also might make sense to cc alex crichton on the issue)
Okay. I'll self-assign to look at it. I've had some experience messing around with this stuff on OS X
next
undefined reference to
linker error when using dylibs" rust#82151oh, yeah, we tabled this for post-sprint. :)
sigh
we're not as short on time as we would normally be at this point
so maybe lets take a moment for #82151
(take a minute to read the bug itself, that is)
This might be an issue in link argument order or lack of #[link(...)]
attributes in user code or something like that.
lets consider the given MCVE
I recall somewhere else an issue about how cdylib
and dylib
don't mix well, too.
so it seems like the steps here are: 1. identify whether the MCVE is correct code or not (incl how it mixes cdylib+dylib), 2. document options for fixing the MCVE, 3. figure out how to apply those steps to the larger bug (which includes tokio+hyper etc)
Wesley Wiser said:
I don't think that's related, but https://github.com/rust-lang/rust/issues/56784 seems to be.
I'm willing to allocate some time today for steps 1 (+2, if I can complete 1)
I'm debating whether there would be any benefit to trying to engage with people on tokio side. I suppose it will depend on what the answer for what the fixes are
I'll self-assign for now
we already discussed this
fn() -> Out
is a valid type for unsized types Out
, and it implements FnOnce<(), Output = Out>
" rust#82633we're almost out of meeting time. I sense that no one is going to volunteer to own this issue this week.
We used to have a traits wg
but they're focused on foundational question and new trait-solving architectures at this point, right? Not technical artifacts like this?
From @Frank Steffahn comment
As to ways this _should_ be fixed: Either disallow all types
fn(...) -> R
withR: !Sized
in general, or at least change the compiler so that they don’t implementFnOnce
.
That might be a relatively easy fix to put in, in any case. So more a question of whether its a good fix. Maybe a question for T-lang then?
I'm going to put that in a comment and retag as T-lang. Nothing like passing the buck.
I can take a look at the impl side of that
T-libs-impl
this time.T-compiler
this time.(Next week)
@Esteban Küber don't stress too hard about implementing it though, until after T-lang has had chance to confirm
okay good
thats our meeting time everyone
thanks to everyone in @T-compiler/meeting for attending!
Draft for next week's agenda:
https://hackmd.io/PD1DrtFbSJaLo-hZ0WYc5g?view
Scheduled checkins: