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

Announcements

• Tomorrow, at this same time, is the T-compiler planning meeting for the upcoming cycle

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

• We finished our first sprint of 2021 last week. :)

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

MCPs/FCPs status

• New MCPs (take a look, see if you like them!)
  • "Lang Item for Transmutability" compiler-team#411

• Old MCPs (not seconded, take a look)
  • "MCP: More Cranelift-friendly portable SIMD intrinsics" compiler-team#381
  • "Debuggable Macro Expansions" compiler-team#386
  • "Uplift the invalid_atomic_ordering lint from clippy to rustc" compiler-team#390
  • "Staged queries" compiler-team#391
  • "Do not traverse the HIR to generate metadata" compiler-team#392
  • "Embed version numbers in backport nominations and regression labels" compiler-team#393
  • "Add different entry points for x.py" compiler-team#396
  • "rustdoc is using rustc_ast_pretty, would it be possible to make it somewhat "stable"?" compiler-team#403

• Pending FCP requests (check your boxes!)
  • "Adding diesel to the cargotest suite" rust#81507
  • "reduce threads spawned by ui-tests" rust#81942

• Things in FCP (make sure you're good with it)
  • "Filter out query machinery from compiler backtraces by default" compiler-team#410
  • "MCP: Embed the hir_id of the _awaited expression_ into DesugaringKind" compiler-team#413

• Accepted MCPs
  • "Eagerly construct bodies of THIR" compiler-team#409

• Finalized FCPs (disposition merge)
  • "Allow specifying alignment for functions" rust#81234

(Late announcement: LLVM12 bump landed, with the new and exciting features, fixes and, of course, bugs)

WG checkins

@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 into rustc_type_ir, particularly around Encodable/Decodable
• Work towards GATs stabilization
  • #82066
  • #82272
• Work towards type_alias_impl_trait/min_type_alias_impl_trait stabilization
  • #82558
  • #82898

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

Backport nominations

T-compiler stable / T-compiler beta

• No backport nominations for 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.

T-libs-impl stable / T-libs-impl beta

• "std: Fix a bug on the wasm32-wasi target opening files" rust#82804
  • fixes rust#82758
  • P-high regression on target wasm32-wasi prevents from opening files
  • see P-high regressions in agenda :point_down:
  • cc: @Mara

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

• should also discuss a stable backport?

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

PRs S-waiting-on-team

T-compiler

• "add dynamically-linked musl targets" rust#82556
  • opened by @Ariadne Conill
  • assigned to @nagisa, raises some concerns on the behaviour consistency
  • assigned also to @Vadim Petrochenkov, provides a great summary on Zulip, suggests to enable dynamic linking on nightly to see what breaks
  • @richfelker (author and mantainer of musl) recommends proper naming to avoid confusion
  • discussion is still ongoing, revolves around clarifying the --target behaviour and what people expect when compiling for MUSL

This 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

• No PRs waiting on T-libs-impl this time.

Issues of Note

Short Summary

• 2 T-compiler P-critical issues
  • 0 of those are unassigned
• 65 T-compiler P-high issues
  • 40 of those are unassigned
• 0 P-critical, 2 P-high, 1 P-medium, 0 P-low regression-from-stable-to-beta
• 2 P-critical, 1 P-high, 1 P-medium, 0 P-low regression-from-stable-to-nightly
• 1 P-critical, 38 P-high, 90 P-medium, 10 P-low regression-from-stable-to-stable

P-critical

T-compiler

• "char::encode_utf8 crash on nightly" rust#82833
  • Opened by @David Hewitt
  • Assigned to @Nikita Popov
  • Unsoundness on nightly when compiling with RUSTFLAGS="-Ccodegen-units=1 -Cinline-threshold=0 -Clink-dead-code"
  • comment shows that regressed in pr rust#81451
  • seems caused by an LLVM upstream issue
• "Slice length becomes random between nightly-2021-03-04 and nightly-2021-03-05" rust#82859
  • Assigned to @Nikita Popov
  • On nightly println!() macro prints garbage when inlining functions
  • Related to the above :point_up: (#82833) LLVM 12 upgrade unsoundness

fudge

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

• "Slice length becomes random between nightly-2021-03-04 and nightly-2021-03-05" rust#82859
  • Assigned to @Nikita Popov
  • On nightly println!() macro prints garbage when inlining functions
  • Related to the above :point_up: (#82833) LLVM 12 upgrade unsoundness

okay 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

T-libs-impl

• "std::io::copy returns Bad File Descriptor with writer files in append mode in 1.50" rust#82410
  • Issue happens when streaming one file into another and the writer is in append mode, only when using BufWriter/BufReader
  • @The 8472 provides a patch rust#82417, pending review

@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

T-rustdoc

• No P-critical issues for T-rustdoc this time.

P-high regressions

P-high beta regressions

• [t-libs-impl] "WASI: path_open regression in Rust 1.51 when using LTO" rust#82758
  • compiling for --release and with LTO enabled breaks loading files from the filesystem
  • WASI is Tier 2 target
  • Alex Crichton submitted a patch in #82804 (nominated for beta backport)

(already discussed, approved for nightly by me, and delegated to T-libs-impl re beta-backport decision)

Unassigned P-high nightly regressions

• No unassigned P-high nightly regressions this time.

Performance logs

2021-03-10 Triage Log

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

Regressions

Rollup of 8 pull requests #82929

• Moderate regression in instruction counts (up to 1.6% on full builds of keccak-debug)
• A fairly consistent (albeit small) regression in the 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 tell

Improvements

• Move check only relevant in error case out of critical path #82738
• Backport some LLVM compile-time improvements #82783
• Rollup of 10 pull requests #82953
• Update tracing to 0.1.25 #82553

Mixed

Upgrade to LLVM 12 #81451

• Very large improvement in instruction counts (up to -11.3% on full builds of keccak-opt)
• Large regression in instruction counts (up to 7.7% on full builds of deeply-nested-opt)
• Some of the perf regression seen here was gained back in #82783.

Nags requiring follow up

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?

seems like PR #82738 is the followup that resolved the regression injected by #81458

Nominated Issues

T-compiler

• "Invalid field is never read: lint warning" rust#81658
  • Already discussed during T-lang meeting
  • Conclusion is to improve diagnostic
  • However, related issue rust#81626 is a stable-to-beta regression
  • Should we "just" revert PR #81473 on beta-alone, and in parallel improve the diagnostic on nightly?

pnkfelix 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

• "Make symbols stripping work on MacOS X" rust#82037
  • MacOS' linker can't strip binaries anymore, Apple documentation recommend using a separate strip tool for that.
  • This change allows the compiler to use that tool after a target has been compiled to strip symbols.
  • Assigned to @Esteban Küber asks more eyeballs on this

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#82151
  • Opened by @Alex Kornitzer
  • Unassigned and mentioned two meetings ago, scheduled to be discussed again today

oh, 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.

https://github.com/rust-lang/rust/issues/65610 maybe?

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:

https://github.com/rust-lang/rust/issues/65610 maybe?

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

• "add dynamically-linked musl targets" rust#82556
  • Mentioned in PR waiting on team

we already discussed this

• "fn() -> Out is a valid type for unsized types Out, and it implements FnOnce<(), Output = Out>" rust#82633
  • opened by @Frank Steffahn
  • issue bisection seems to point to PR #73905
  • issue seems to reproducible on stable since long (so not a regression) but to be unsound on nightly
  • something to investigate a bit closer -> (needs an owner)

we'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 with R: !Sized in general, or at least change the compiler so that they don’t implement FnOnce.

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

• No nominated issues for T-libs-impl this time.

RFC

• No nominated RFCs for 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:

• @WG-diagnostics by @Esteban Küber and @oli
• @WG-rustc-dev-guide by @Santiago Pastorino and @Joshua Nelson