---
title: Triage meeting 2026-01-07
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2026-01-07
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202026-01-07/
url: https://hackmd.io/501bspOdSHedXnwh7UCu8Q
---

# T-lang meeting agenda

- Meeting date: 2026-01-07

## Attendance

- People: TC, tmandry, Josh, Nadri, Jack, dianne, Tomas, Nia Espera, Niko, theemathas, Eric Holk, Yosh Wuyts

## Meeting roles

- Driver: TC
- Minutes: Tomas

## Scheduled meetings

None.

Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

Nadri: I got one about a desugarings-for-spec [experiment](https://nadrieril.github.io/rust-via-desugarings/) I'm doing

### Guest attendee items

TC: For any guests who are present, please note in this section if you're attending for the purposes of any items on (or off) the agenda in particular.

### Moving right along

TC: As we've been doing recently, due to the impressive backlog, I'm going to push the pace a bit. If it's ever too fast or you need a moment before we move on, please raise a hand and we'll pause.

### Design meeting at 12:30 EST / 09:30 PST / 17:30 CET

TC: Remember that we have a design/planning meeting that starts half an hour after this call ends.

Nadri: I wrote a proposal on translating surface Rust to MIR, and would be interested in trying to turn it into an implementation, with the idea of having the spec executable. I'm looking for a vibe check on having something executable being the source of truth.

TC: Eric Huss and I looked at your document yesterday. I want to have a core language that the rest of the language desugars to as a long term thing. I'm excited about this. We do specify some desugaring in the Reference. If there are other things that can be expressed that way today, that would be great to add to the Reference. The process would be submitting incremental PRs. Some things in your document surprised me: I don't think we can desugar match -- but we can have an conversation.

Nadri: I'm hearing that we want the desugaring. What about the implementation?

Eric Holk: Wasm had an executable spec from pretty much the beginning and I think it's been a good thing for Wasm.

Josh: It sounds like an interesting idea. I'd like to read the document. The idea of having something executable as the source of truth sounds really appealing. The concept of desugaring sounds potentially interesting. How do we ensure the desugaring matches the behavior of the compiler. Is the expectation that the desugaring would in fact be the compiler's implementation? Second, if you define Rust by canonically desugaring to MIR, then you'll have to specify the definition of MIR. We haven't had to do that previously, but we don't have that today and we would have to define this in the Reference.

TC: In his document he's making Rust to Rust desugaring.

Nadri: Yes.

Niko: I'm in favor of this general direction. I'd like to chat with Nadri about a-mir-formality being a good home for this.

Nadri: Any major "no"s I should be worried about?

Tyler: It sounds interesting, no major objections. I want to dig into it more.

Tyler: If it can proceed in parallel with MiniRust/MIR work, that would be ideal.

Josh: When we're working with RFCs and other proposals to the language, we define the new constructs via desugaring. Having a canonical micro-subset of Rust that we can provide to desugar to would be interesting for that purpose too.

Nadri: Thanks for the vibes.

### Next meeting with CPython

We're meeting on 2026-01-08 at 15:00 UTC

### Next meeting with RfL

We're next meeting with RfL on 2026-01-14 (next week) to review the status of RfL project goals.

https://github.com/rust-lang/rfcs/pull/3614

## Nominated RFCs, PRs, and issues

### "Regressions in 1.93.0 crater run: rustdoc errors on invalid `#[test]` attribute" rust#150665

**Link:** https://github.com/rust-lang/rust/issues/150665

TC: We FCPd a decision where `#[test]` was in places where it shouldn't and removing those. There's a crater failure. People have test attributes in their doctests. The breakage is more extensive to rustdoc than to rustc. Did we mean to do that? Do we still want to do that?

Tyler: Did any of these have dependents?

TC: It's in the rustdoc. I don't think breaking that means you're breaking their dependencies.

theemathas: The test attribute is in random places in their code, but for some reason it only broke rustdoc

Josh: A quick look at the 12 cases, I'm seeing some random GH repositories, and some crates that don't look like they have many users. I'm not seeing a substantial root regression here.

TC: Agreed.

TC: I'm still comfortable with our earlier FCP.

Tyler: I'm comfortable with the breakage. I'm curious about what theemathas said about it showing up in random places, but only triggering rustdoc.

Tyler: Do we need to FCP this again?

TC: Our prior FCP stands, if we take no action it just goes as planned.

Josh: Did the earlier change already have a relnotes tag and did someone wrote a detailed writeup about compatibility? We should also extend the compatibility note to mention the rustdoc. Ideally with examples of where you can and can't put the test attribute.

TC: It's tagged in relnotes, I trust the release team will put the compatibility notes where they belong

https://github.com/rust-lang/rust/issues/150760

TC: Anyone unhappy with the proposed meeting consensus?

(no one raised their hand)

### "Revert "Do not check privacy for RPITIT."" rust#146470

**Link:** https://github.com/rust-lang/rust/pull/146470

TC: We were waiting on crater run. It shows a lot of regressions.

Tyler: Petrochenkov comments we might need a FCW

Niko: Considering how not strongly motivated this was, I want to revisit it in light of the breakage (3+k crates)

Josh: I want to understand the root conditions and seeing whether we're actually catching something we wanted to catch or whether those use cases are perfectly OK

Example:

[INFO] [stderr]    Compiling embassy-executor-macros v0.6.2 (https://github.com/embassy-rs/embassy?rev=4af2d9a#4af2d9ad)
[INFO] [stdout] error[E0446]: private trait `TaskReturnValue` in public interface
[INFO] [stdout]   --> /opt/rustwide/cargo-home/git/checkouts/embassy-c08a80187403f815/4af2d9a/embassy-executor/src/lib.rs:78:9
[INFO] [stdout]    |
[INFO] [stdout] 68 |     trait TaskReturnValue {}
[INFO] [stdout]    |     --------------------- `TaskReturnValue` declared as private
[INFO] [stdout] ...
[INFO] [stdout] 78 |         type Fut: Future<Output: TaskReturnValue> + 'static;
[INFO] [stdout]    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't leak private trait
[INFO] [stdout] 
[INFO] [stdout] 
[INFO] [stdout] For more information about this error, try `rustc --explain E0446`.
[INFO] [stdout] 
[INFO] [stderr] error: could not compile `embassy-executor` (lib) due to 1 previous error
[INFO] [stderr] warning: build failed, waiting for other jobs to finish...
[INFO] [stdout] error[E0446]: private trait `TaskReturnValue` in public interface
[INFO] [stdout]   --> /opt/rustwide/cargo-home/git/checkouts/embassy-c08a80187403f815/4af2d9a/embassy-executor/src/lib.rs:78:9
[INFO] [stdout]    |
[INFO] [stdout] 68 |     trait TaskReturnValue {}
[INFO] [stdout]    |     --------------------- `TaskReturnValue` declared as private
[INFO] [stdout] ...
[INFO] [stdout] 78 |         type Fut: Future<Output: TaskReturnValue> + 'static;
[INFO] [stdout]    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't leak private trait
[INFO] [stdout] 

TC: The next step is for someone to propose a FCW or a concrete proposal

Niko: I'd want a deeper analysis of the crates along what Josh said.

TC: Didn't Petrochenkov analyze this and said mostly with the concrete versions of image-0.25

Jack: There's a lot more than that it seems.

Josh: Also, image itself is a pretty important crate. Image 0.25.9 is the lastest version that's two months old. There's no version with the fix available. Before we do the FCW that affects thousands of crates, we need to figure out what's actually going on.

Niko: In the case of embassy, it's an implementation detail for macros where I think they may well want to keep that crate private

https://github.com/embassy-rs/embassy/blob/main/embassy-executor/src/lib.rs#L61-L74

Tyler: I don't think we can do a FCW immediately. Maybe start with a regular warning and upgrading.

Josh: Sounds like we've got a rough meeting consistency: we're less sure about doing this. We need to understand what's the core problem breaking things and whether we really want to have those fixed.

Niko: I guess ... they could just declare `TaskReturnValue` pub and I can see a case for it, but [here is the code](https://github.com/embassy-rs/embassy/blob/c4910299324feaf696c840ed4f7b6f192ee6a6ca/embassy-executor/src/lib.rs#L61C1-L83):

/// Implementation details for embassy macros.
/// Do not use. Used for macros and HALs only. Not covered by semver guarantees.
#[doc(hidden)]
#[cfg(not(feature = "nightly"))]
pub mod _export {
    //...
    trait TaskReturnValue {}
    impl TaskReturnValue for () {}
    impl TaskReturnValue for Never {}

    #[diagnostic::on_unimplemented(
        message = "task futures must resolve to `()` or `!`",
        note = "use `async fn` or change the return type to `impl Future<Output = ()>`"
    )]
    #[allow(private_bounds)]
    pub trait TaskFn<Args>: Copy {
        type Fut: Future<Output: TaskReturnValue> + 'static;
        //                       ^^^^^^^^^^^^^^^ the error is here
    }

Tyler: This is a consistency argument, we were trying to buy ourselves more options in the future.

Nadri: The particular example would work as a sealed trait so not sure what to conclude from it.

Niko: If we had those as a (more convenient/first-class) thing, that would be helpful.

Josh: I propose we summarize this and move on.

TC: I'm still happy with the consistency argument but I don't want to break that many crates either. I want to see a proposal -- that's why I'd like to see a concrete a proposal.

Josh: I want to see that there is a viable replacement for what the crates are trying to do. Whatever we recommend people do (e.g. sealed traits), do we have a pattern for them to use.

TC: Agreed.

Niko: I can write something up.

### "Support importing path-segment keyword with renaming" rust#146972

**Link:** https://github.com/rust-lang/rust/pull/146972

Tyler: This was in FCP, there are two open concerns. One for documentation and one for consisntent-axioms.

TC: I don't think anything's moved on this one.

Josh: It looks like it's being worked on. The author is doing rebasing but they haven't seemed to respond to the concerns.

Niko: Petrochenkov did respond to my concern. I was arguing that `self` is an identifier that we should be consistent about. He argued that it's part of the braced syntax. I think it's not, it's a name like everythnig is a syntax.

Josh: I feel the next step is currently on us.

Niko: I don't think his point there is an inconsistency. I don't like it because figuring out what's being named here becomes even more complicated.

Josh: I'm not suggesting we nede to make that change, but we should answer it from the language point of view.

Josh: Where you're saynig the language should accept things that only have one obvious meaning, I could see the argument that `::self::something` has an obvious meaning and it's redundant -- should it be a lint? I'd say no one ever used it so we shouldn't allow it. But I could see it being desired.

Niko: I could see it being usable in the macro context. It's useful to be able to append these together and have them make sense.

Niko: I find the language consistent without it, but I think there's an argument for it that is stronger than I'd thought before.

TC: Do you have any reasons not to do this?

Niko: I don't think so.

Tyler: I'm mostly aligned with Niko. I could see there being an argument for `self` and `super` in the middle of paths. But consistency is not the greatest argument. I'm not sure if I followed the last thing

Niko: The middle thing where he said we could us the middle operator. To me if there is a keyword there it should be like the other thing in there.

Tyler: What does have to go in braces?

Niko: If you wanted to say that part of the `::{` syntax is to rename self as part of that, I'd say it's more consistent to drop `self` and just have `use foo::{as name}`.

TC: As a vibe if we just allow them everywhere, would that resolve the issues?

Josh: I'd hesitate to support `super`/`self` in the middle. But I found the last sentence of Petrochenkov compelling.

> If this is a desirable direction, then this PR could bring back the support for use std::{io::self} (without extending it), and unbreak most of the regressions.

Independently of the proposal to allow `self`/`super` in the *middle* of paths, I think we should allow *this* and reduce regressions.

TC: I think petrochenkov is saying is he'd object to that last sentence *unless* we're buying into this last model.

TC: I'm align with Niko's vibe.

Tyler: Are we talking about the `std::{io::self}`

Josh: I asking about the thing having `super` and `self` in the middle.

Niko: I don't object to it. Started negative and then moved to more positive. I want to allow simple copying and pasting to do what you expect to do and use lints to prevent you from typing dumb things.

Josh: I wouldn't object to adding it and aggressively linting against the stupid thing.

TC: I was always surprised that this didn't work like that.

Niko: I've always thought of `pub use` as symbolic links.

Nadri: But then we get the same issue as symlinks -- that you can't always normalize them.

Josh: That's a really good point: if you allow `super` in the middle, you have the same issue as `..`. Does it apply to the path as written or as resolved?

Niko: Yeah that actually convinces me not to permit `super`, but I still feel like `self` and `crate` should not go there.

Josh: I'm going to summarize this in the issue.

Nadri: actually `crate::path` is basically an absolute path, so we'd get all the issues when trying to concatenate that

Niko: Yeah, this also explains why I thought these were orthogonal questions.

Niko: I'll write a response.

niko sketches

`use foo::{$A, $B};` => `use foo::$A; ...; use foo::$B;` -- I guess argues for `use foo::self` in the same way.

### "Inhibit all-absent-variant optimization for all enum reprs that inhibit layout optimization, not just repr(C)." rust#146989

**Link:** https://github.com/rust-lang/rust/pull/146989

Nadri: it's a fix to `MyEnum` being zero-sized here:

#[derive(Clone, Copy)]
enum Never {}

#[repr(u32)]
enum MyEnum {
    A(Never),
    B(Never),
}

Nadri: For `repr(int)` enums, we do layout optimizations. It feels less like a language point, it's more fixing a bug of what it means to be a `repr(int)`. Seems like a no-brainer to me.

Tyler: Does this need an FCP? I don't think it's a breaking change. I think it's just fixing a bug.

Josh: I'm not sure you could construct a case that would regress. It does seem like a language change. `repr(int)` like `repr(C)` and unlike `repr(Rust)` define the layout and so I think we should FCP this.

Nadri: I don't think we guarantee any layout optimizations around uninhabited variants, do we?

Josh: Here we have an actual uninhabited enum.

Nadri: We don't guarantee anything about the uninhabited enum layout.

Josh: I'm not suggesting this change is likely to break people. But we previously guaranteed `repr(u32)` is a stable layout. If people wrote all the reprs currently, they could know that this layout could e.g. be sent over a wire that you could serialize/deserialize. I want to make sure we don't break this.

Josh: I like this change, but I'm saying that it is potentially a breaking change.

Tyler: Does that guarantee hold for enums that have data in their variants? I didn't think we guaranteed anything for those.

Nadri: We do guarantee the layout of `Repr(int)`

Josh: Just like we guarantee `Repr(C)`. So we're changing something that's guaranteed layout. We're fixing a bug, but this needs a release note. The folks who do stunts like zero copy etc. probably want to take a close look at this.

TC: Are we sure we want to do this? I think of `repr(u32)` is if there's a discriminant, it should be a `u32`.

Nadri: reference section: https://doc.rust-lang.org/reference/type-layout.html#r-layout.repr.primitive.adt

Nadri: I'm surprised we guarantee so much for `repr(int)`

Tyler: But we do guarantee that, right?

TC: It would be good to do some archeology on how did the text get there

Josh: People largely listen to us when we say `repr(Rust)` is not stable and we tell them to use ones that are stable. This is one of the ones that's stable.

theemathas: There' a difference between `repr(int)` and `repr(C,int)` together.

Josh: They both have a defined meaning.

Josh: Proposal: I think we should try to do this, we should treat it as a compatibility change, we should rel note it. Make sure we notify some of the folks who do interesting serialization stunts, like `zerocopy` and `rkyv`.

TC: Reading the Reference, it is an error for a zero-variant enum.

Josh: It's uninhabited, not zero-variant.

TC: That's what we currently optimize it as

Niko: I agree with TC, I feel zero variants are probably intended as uninhabited. But there's the distinction between private and public uninhabited.

Nadri: I generally treat uninhabited as ZSTs

Tyler: If we expose the current behavior it can only be for publicly uninhabited.

TC: Does somebody want to write it up? It should have a Reference change if we're going to do this. To be clear about this point.

Josh: I'd be happy to write up a summary of this one and start an FCP.

TC: Should we be crater running this?

Josh: Possibly, yes. It's not obvious this change would be caught by crater.

Tyler: I'd definitely want to review the change to the Reference. I'm still not clear what the change is saying.

(the first part of the meeting ended, we'll be back for the extended triage later)

## Extended triage

- People: TC, Nadri, Jack, Nia Espera, C, Tomas Sedovic, dianne, Tyler Mandry, Yosh Wuyts, Niko, Josh Triplett, Eric Holk, Aapo

## Meeting roles

- Driver: TC
- Minutes: Tomas

### "Remove the single-variant enum special case in pattern matching" rust#150681

**Link:** https://github.com/rust-lang/rust/pull/150681

Nadri: this is a language change proposal that fixes a number of surprising things, the most egregious being the fact that removing `non_exhaustive` can affect UB https://github.com/rust-lang/rust/issues/147722

Nadri: It says whenever we match on an enum we read the discriminant.

Josh: Is this purely an opsem thing? As in logically we read the discrimimant and you're not allowed to have it invalid? Or does it actually involve runtime behavior?

Nadri: It's an operational semantics.

Josh: As long as we're treating the discriminant as "there's nothing here because there's only one value" and there's no runtime work to be done, this seems reasonable.

Nadri: There's also a bit about closure captures. When we do the discriminant read, the closure needs to

Josh: Could that affect the borrow checking of closures?

Nadri: It's a breaking chaneg. We have a crater run in progress

TC: The single variant enum special case has some intuitive appeal. There's a reason it's there. I'm curious to hear from Niko more on the history.

Josh: Do we have a piece of code that demonstrates how to get UB using this pattern?

Nadri: It's here: https://github.com/rust-lang/rust/issues/147722

Nadri: Without the non-exhaustive attribute it was not UB, with the attribute its' UB already. So this makes it consistent.

TC: This is restricting the set of programs you're allowed to write in your crate.

Nadri: there's alwso a borsrc = craneLib.cleanCargoSource ./.;rowck change: https://github.com/rust-lang/rust/issues/146590

Nadri: Some weird borrowchc stuff is allowed for some uninhabited variants because we didn't emit discriminant reads yet.

Niko: We don't have crater results yet?

Tyler: We don't. I want to see the results. I see the appeal, it feels like a simpler model and I'd prefer we had it.

Niko: Where else do we have differences between single-variant enums? Theres' field projection

Nadri: We don't allow it on single-variant enums.

Niko: It's surprising to me that a single-variant enum doesn't behave like a struct. And it's surprising to me that it doesn't behave like a two-variant enum. What's the precedent we have in other places for single-variant vs. multi-variant enums?

TC: We ran into the same distinction when we talked about uninhabited fields and things like set discriminant.

Niko: Yes. There's also the closure capture one. I wonder if it shows up in Ralf's operational semantics.

Nadri: There's also `derive` how they work on structs or enums. I don't think anyone's using a single variant enum and using it as a struct, never intending to add another variant.

Tyler: +1

Niko: I think this is saying that I don't want to take advantage of how this works just because I happen to have a single variant right now and I don't want the closure capture rules to change when I add another variant. I'm convinced by that.

Josh: +1

TC: Do we need to do this for all enums? Or just marked as `non_exhaustive`. Right now opsem depends on how things are factored within crates. Can we fix that without doing this for all enums?

Nadri: We could make it that discriminant_read on non_exhaustive happens regardless of the current crate. There's still the other inconsistencies. Im' trying to say than enum is always morally non_exhaustive. You could always add more variants.

TC: There's some appeal to the ADT model Niko's handwaving at. I regret this change much less in the non_exhaustive case. In your own crate you still have to handle the non_exhaustiveness.

Nadri: That means within your crate,

Tyler: That's part of the change we're discussing. And TC's trying to carve out a subset he's comfortable with

Nadri: We could pretend that non_exhaustive is not in the current crate. That's surprising because it's not consistent with what you expect.

TC: I think the non_exhaustive does matter. If you don't have non_exhaustive on it, you don't put non_exhaustive on it. You're committed for the moment to the number of variants you have. Even just within your crate you're still committed until you've changed.

Tyler: TC, what I think you're saying is if you have non_exhaustive on an enum in your current crate, you want to be able to write code that when you add a new variant, it continues compile. It would lose one kind of consistency: within your crate we would treat non_exhaustive differently at the opsem level than we treat it at the pattern-matching level.

Josh: I'm looking at this and going: "really?". If you wrote unsafe code that finds the offset of the field in the enum and directly reads just that value, that would be the defined value. But if you're writing a match on an enum wher you said "there exist a discriminant" we can optimiza that you don't actually read anything there. But relying on saying where we don't and having an undefined memory I don't feel you'd want to write that program.

TC: This affects closure capturing so there are reasons why you'd want to rely on this in your crate.

Josh: I'm not suggesting that's the only way of relying it. But because of that argument you shouldn't be able to rely on that in general.

Nia: Regarding the pont about non_exastive chaging behaviour. I'm partial to the argument that we should always read the discriminant. But it's weird that having a single-variant enum be UB depending on whether it's non_exhaustive.

Nadri: I think that's inconsistent with the definition of non_exhaustive. If we did what you said, someone in a foreign crate could add a new varient and that would be a change in behaviour.

Nia: Would that be a change in observable behaviour?

Nadri: UB is observable, so is closure capture

Niko: I suggest we move on, it's not actionable unless we see the crater result.

### "Single-variant exception for `match` consequences for `#[non_exhaustive]`" rust#147722

**Link:** https://github.com/rust-lang/rust/issues/147722

Nadri: Same as the above PR

### "Stabilize ppc inline assembly" rust#147996

**Link:** https://github.com/rust-lang/rust/pull/147996

TC: This adds assembly for PowerPC and PowerPC64. We have a FCP proposed. Waiting on checkboxes. One more person will put this into FCP.

Tyler: Who's using PowerPC?

Josh: A handful of embedded folks and a lot of retro computing enthusiasts. It's still an architecture using PowerPC64 on big iron.

Tyler: You wrote the platform support RFC. What can we do when the platform goes away?

Josh: If we drop a target via a policy for target tier, if it just becomes Tier 3 it doesn't let us rip out something we added to the language. But if we rip out the architecture/target then we can stop compiling for it. And then there's no code to break and so we could rip it out.

Tyler: No objection.

Josh: If PowerPC64 weren't a thing people would wildly want to support, I'd not say it's worth the extra effort. But because we're supporting PowerPC64, it's similar to us having support for 32-bit x86 inline assembly.

### "Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint" rust#148214

**Link:** https://github.com/rust-lang/rust/pull/148214

TC: We have an open FCP on this. It has one outstanding concern from Josh.

Josh: If you try to add must-use on a function, you get clippy warning.

Jack: We're just waiting on clippy. Currently today clippy warns against the opposite pattern -- to remove must use. I don't think there's anything for the lang team to do here.

Josh: Agreed. We need to wait for clippy to make this change before we can go forward. I propose we say that this came in today's meeting, that we're not making any change now, we're waiting on clippy.

TC: What's the simplest thing the clippy team can do?

Josh: They reimplement a given check that Rust already has. It's not clear to me if they did it because they added something. If the check is just redundant, they could change it to allow.

Jack: There's a slightly separate question on: should we have clippy stop warning about it a version or two before this lands. Depending on whether they reuse this must_use function. If clippy stopped warning the same version we landed this, it would be fine. But it's worth thinking about this being an update to the new version.

TC: Scott commented on that last month: https://github.com/rust-lang/rust/pull/148214#issuecomment-3644897652

Josh: I'd broadly agree with Scott's comment that we'd try to make it at least one release window. We should ideally make it longer. I have sympathy for people who can't make this without breaking people on the older version. If we made the clippy change to stop warning about this, that would be good. But I would not want to be that done simultaneously with that change. Say we're looking at making this change in a release note. I think we should make the change, wait a bit and then make the change. And give them a loud heads-up.

TC: Waffle has a question about what would resolve the concern; let's be sure to answer that specifically.

Tyler: There's a way to write code today that's compatible with the change and not fire the clippy lint. You put a method?? on your must_uses attribute.

Josh: That means there's at least a useful workaround then. But why do we need to do this on an aggressive timeline?

Tyler: I'd be sad if we had to wait for this for six months but I'd be okay if we waited one release.

Josh: That's good to know.

Niko: How many peolpe are impacted?

Josh: Jack did a scan of how many people would potentially use this pattern. There would be a lot of code that would be affected if the warning was removed. It's not code that guarantees we want those warnings to show up.

TC: Niko and Josh you haven't checked a box, feel free to do that. It won't go forward until the concern is resolved anyway.

### "Stabilize the `supertrait_item_shadowing` feature" rust#148605

**Link:** https://github.com/rust-lang/rust/pull/148605

Tyler: There's an outstanding concern for a Reference PR and checkboxes for Types.

TC: We'll catch Amanieu next time he's on our call and ask how that's going.

### "const-eval: always do mem-to-mem copies if there might be padding involved" rust#148967

**Link:** https://github.com/rust-lang/rust/pull/148967

TC: We have a proposed FCP on this, Tyler and I checked the box.

TC: The context is, this is in const-eval, we're copying something that has padding. What are we doing with the padding in the destination? Right now it depends on the details (are we doing a scalar pair optimization or not). In our proposal here says we're doing this but we're not guaranteeing that's what we're going to do. In the Reference we'll say that any uninit type might have a pointer fragment. If that happens, we may fail the const-eval. We'd prefer to uninit that padding, but the perf run is expensive.

Nadri: What we're saying that uninit bytes that go from const-eval to runtime would be a problem. This is less restrictive.

TC: Yes.

TC: Niko checked a box. Josh do you have any questions? It's still waiting on documentation.

Josh: Confirming, I'm saying this seems fine on the basis of we're not doing the thing has expensive perf result. If this turned to have a massive perf impact, I'd want to know and reconsider.

TC: We did a perf run; it doesn't have significant perf impact.

### "FCW Lint when using an ambiguously glob imported trait" rust#149058

**Link:** https://github.com/rust-lang/rust/pull/149058

Tyler: Change description in https://github.com/rust-lang/rust/pull/149058#issuecomment-3666856777

Josh: I'm looking at the description of the change. I want to make sure this change only applies when the traits are actually different, correct? If both of these were `pub(use)` of the same trait, we wouldn't give any warning, is that accurate?

Josh: The change proposed soungs reasonable to me. I want to flag we don't trip this FCW on glob-importing the same trait. I want to make sure there is a test covering this.

Tyler: That can still result in a problematic situation if one is a `pub` and one is `pub(crate)`

Josh: That's a different issue, depending on visibility.

Josh: I'll write a quick comment to the crate to make sure this works and has a test.

Tyler: The end goal is to accept the imports but not the use of the trait methods or name?

TC: Yes, that would be my understanding. The glob import would be ok but if you tried to rely on it, you'd get an error.

Josh: That's consistent with how we're doing glob imports. We don't want to break it on the import assuming you're not using anything there.

Tyler: That sounds good to me.

Niko: We had a discussion with Petrochenkov about interactions between different visibilities, that's different from this, right?

Josh: Yes.

### "Make PinCoerceUnsized require Deref" rust#149218

**Link:** https://github.com/rust-lang/rust/pull/149218

Tyler: Alice Ryhl merged a change to close up an unsoundess issue in `PinCoerceUnsized` change to prevent doing this breaking change. theemathas says let's just make the breaking change because crater is clean.

TC: Tyler do you want to say out loud why this is true?

Tyler: there's an open issue by theemathas: https://github.com/rust-lang/rust/issues/145081

Tyler: Some additional history with Pin and CoerceUnsized...

* Original issue: https://github.com/rust-lang/rust/issues/85099
* First PR by Alice (closed) removed CoerceUnsized impl for Pin: https://github.com/rust-lang/rust/pull/144896
* Second PR by Alice (merged): Prevent downstream impl DerefMut for `Pin<LocalType>` https://github.com/rust-lang/rust/pull/145608

Josh: I think the right answer is go ahead and start an FCP on this. The description and recommendation seems pretty clear.

TC: He says here "pin doesn't do anything useful for non-Deref types".

Nadri: The point is it's `Pin<P>`. All the guarantees depend on what `P` points to. A `Pin<u32>` is useless, but `Pin<&u32>` is.

TC: I'm not sure I followw the premise.

Nadri: He's saying that `Pin<T>` is useless if `T` is not `Deref`

Niko: `Pin` is meant to be applied to a `Deref` type. And `PinCoerceUnsized` is just to allow you to get from `Pin<Arc<T>>` to `Pin<Arc<Deref<T>>>` ??

Tyler: I don't see a reason not to do this. Alices is in favor, Theemathas is in favor, crater's clean.

TC: Looking at the example in: https://github.com/rust-lang/rust/issues/145081

use std::cell::UnsafeCell;
use std::pin::Pin;

fn foo(x: Pin<UnsafeCell<&i32>>) -> Pin<UnsafeCell<&dyn Sync>> {
    x
}

fn bar(x: Pin<&i32>) -> Pin<*const dyn Send> {
    x
}

TC: Why should this be disallowed?

Josh: That's the odd part. You can't silently coerce `Pin<&i32>` but you can if you do a raw pointer to a trait object.

Nadri: Also, a pin of a raw pointer is equally useless. Pin uses Deref pretty crucially.

Niko: `Pin<*const` doesn't have the expected guarantees that we've written.

Nadri: The main way to create a Pin of an arbitrary thing would be `Pin::new_unchecked` which requires `Deref` so you can't even construct it. All the `Pin` methods require `Deref`

TC: It seems intuitive why you'd want a ??

Nadri: It would, it's just not how we designed `Pin`.

TC: What is this change do example?

Tyler: It deletes the impls.

Tyler: In a hypothetical world where we'd want to support raw pointers with Pin, this would make it harder but we don't support that today.

Josh: In a hypothetical world, should we have made `Pin<T>` require `T: Deref`?

Nadri: +1

Niko: I think we should have. There's a general trend in the library to not put where clauses on structs.

Josh: I vaguely agree with it in terms of HashMap or BTreeMap but here, there's no function without it.

TC: How locked are we on this `Deref` thing on `Pin`? Is there some reason we couldn't actually remove the `Deref` requirement to the argument to `new_unchecked`?

Tyler: I don't know of a reason we couldn't. I think it would risk .. using a raw pointer you know you have to be careful with this.

Nadri: Someone could accidentally use a pin of a value than a pointer.

Tyler: That's a good point. I'd like to catch it earlier.

Nadri: With the filed projection work it Pin will refer to a place and there it might make more sense.

TC: That's what's giving me a pause. Any place you should accept a reference you should accept a pointer too.

Nadri: What we needed for specifying Pin is a notion of what what the thing points to. And currently in the language that's specified by `Deref`. But if we broaden this later, we'd update this too.

Tyler: I think the maximally forward compatible thing would be to remove the impls and don't add the supertrait.

TC: I'd be more favor in removing the impls becaues we can always add them back.

Tyler: The maximally forward compatible thing would be a supertrait of a sealed trait that implements Deref. There would a blanket impl on the sealed trait.

pub unsafe trait PinCoerceUnsized: SealedDeref {}

#[sealed]
trait SealedDeref: Deref {}
impl<T: Deref + ?Sized> SealedDeref for T {}

Niko: Is this a stable trait? PinCoerceUnsized is a nightly-only API

Tyler: I think it's probably an observable change.

Jack: You can't use the trait yourself but the behavior around it is stable.

Tyler: But it might become stable soon.

Niko: I do see TC's point. TC do you want to leave a comment?

TC: Yeah. We're generally okay with removing the impls. And at least I have reservations around moving beyond that. But the trait is not stable so as long as we're careful about it later, it's okay.

### "Promote `uninhabited_static` lint to a hard error" rust#149518

**Link:** https://github.com/rust-lang/rust/pull/149518

Josh: We previously made this change to start complaining about it becaus ethere's nothing you can do with a static has an uninhabited type. We enabled this FCW five years ago.

TC: We were waiting for crater results. We have them now.

Tyler: It looks like we weren't warning in deps for this FCW. It's set to only warn not warn-in-deps

Josh: Then we need to look at the crater results more carefully.

TC: https://github.com/rust-lang/rust/pull/149518#issuecomment-3607908232

> It's worth noting here that, though this has been an FCW for a long time, it's only set to warn and is not set to report in deps. If we were to decide to not make this a hard error immediately, it'd seem that would be the natural next step. In the meeting, we talked about how perhaps if there is no observed breakage in crater that we might be OK with going to a hard error directly regardless.

Nadri: +1

Jack: +1

TC: There is observed breakage so the next step is to make this warn-in-deps.

Josh: Is there a link to the observed breakages?

Jack: I'm looking at them and they're definitely real.

Josh: That's great, thank you. I agree we should upgrade it to WCW warn-in-deps and wait a while.

Josh: It's not the current version of xcb and python3-sys. But `block` is the current version. It has 2m recent users and was last updated nine years ago.

### "reduce `unreachable-code` churn after `todo!()`" rust#149543

**Link:** https://github.com/rust-lang/rust/pull/149543

TC: This is about treating `todo!` differently than `panic!` and not showing warnings that follow it.

Tyler: That'd be nice.

Josh: It came in a meeting before. There are a couple of different workflows people have. One is they add `todo!` and want the build to silently not do anything. And there's the workflow of "nice, warnings, I'm not done yet".

Josh: Would it make sense to add a different variant of `todo!` that has that meeting?

TC: I don't recall us discussing that.

Tyler: That's a valid point. I would suggest we make a lint on todo itself. And that would be a separate lint. You always get a warning telling you you have more stuff to do but don't have a massive list.

Josh: The code pattern I often follow is effectively a compiler driven development. I write a function, I add todo, I have warnings on unused arguments and I know I'm not done for unused arguments.

Tyler: This is for unreachable code not unused arguments.

Josh: Fair point. If we're just talking about suppressing unreachable code and making a lint saying there's `todo!`, sure, ok.

TC: Are we buying into a mental model of pretending `todo!` is not there?

Niko: I think that's aligned with both Tyler and Josh's point of view.

Jack: As an implementation thing, I don't like this implementation. Diverging this changes actual type-checking behavior. If we'reg going to do this it should happent on the lint side not type checking side of things.

Nadri: The workflow is surprising behavior. I don't personally rely on the warnings. On the implementation point: it still considers the code as divergent.

Niko: My mental model for `todo!` is that it's replaced by some function. I'd like to have the ability to have a list of things I can do there i.e .what Josh proposed. I want it to be equivalent to a function like this: `fn foo<T>(...) -> T`

Tyler: My proposal is to treat `todo!()` as something like `{ let _temp = || panic!(); _temp() }`. (I typed this before Niko said the above.)

Josh: Is there any way this could start warnings ??. When we talk about code being unreachable, that supresses warnings about what the code does.

Jack: If Nadri is correct that this is still treating as it diverges, then it shouldn't change anything. Regarding Niko's point, if we could change it as not diverging that changes behavior and might break some code.

Nadri: ?? something about never type fallback?

Niko: But not until we do the fallback which is late in the type process. I'm okay if it ends up being type never. I'm super annoyed about the dead code warnings, that makes it almost never useful for me.

TC: I feel if code has `todo!` in it then I feel that's going to be a low-priority breakage.

Tyler: That makes me thing this could be a function in the standard library, not a macro.

Niko: I would like that.

Tyler: My understanding is todo is just a panic with another name.

Niko: todo without any arguments you can do today.

Josh: todo, panic and unreachable are the same, you just expressing different intent.

Tyler: I still think it should not be considered diverging.

TC: So is this a good step? Can we FCP it?

Niko: The simplest implementation of `todo!` would be

macro_rules! todo {
    () => {
        fn my_todo<T>() -> T {
            panic!()
        }
        my_todo()
    };
    
    ($a:literal) => {
        fn my_todo<T>(x: &str) -> T {
            panic!()
        }
        my_todo($a)
    };
}

Niko: We could have it desugar to standard core and see who's impacted.

Josh: In the proof language, the equivalent here would be a function called "absurd"

Niko: Yes.

TC: This is not the "absurd" function. That takes an argument of `!` and returns `T`.

Tyler: Jack, regarding your concern.

Jack: I have to look but I think it'll do what Nadri said.

Tyler: We could just change the behavior of the lint.

Niko: I think this is more towards Nadri's desugaring. But I'm fine with changing the lint.

TC: Does this have a transitive effect? You have something below todo that would be dead code. And this is not going to lint because your code is going to be seen past todo?

Niko: Seems so.

Josh: If that also does cascade to "and your no longer making calls to this function"

Nadri: We don't take reachability into an account.

TC: You're sayngi this PR doesn't do this or does?

Nadri: reachability of a function call does not affect whether the function itself is considered used for the `unused` lints

fn foo() {
    return;
    bar(); // <-- this gets a warning ("dead code")
}

fn bar() { } // <-- this does not

fn main() { 
    foo();
}

Tyler: I'd like to be able to do the change in the standard library desugaring into a macro but I don't want to block that. Do we have consensus to change the desugaring as a positive change for future development?

Josh: It wasn't clear what the net positive benefit of switching to that function was.

Niko: Those are the semantics I want. I don't care how it's implemented.

TC: With respect to changing the desugaring, and looking at the desugaring aboe, note that this works and does string interpolation in the error message:

fn main() {
    todo!("hello {}", 1);
}

Niko: I'd just desugar it to a function that prints out the message. Don't take it literally. No change to runtime behavior.

Josh: If people want to propose a change to the actual desugaring, that should be a separate proposal and PR. But +1 to the semantic of this should return an arbitrary value and ??

Tyler: I can take the comment. I'm lukewarm about requiring a lint on todo for this change but I think it's a positive change.

Josh: I would not want to land this change if this lint required an optional clippy lint for it to work.

Tyler: So you'd want to land the todo lint?

Josh: I'd want to land the todo lint before shipping this change. But I'm fine with shipping the change.

Josh: Instead of having the "the rest of your function is redundant" lint would be replaced with a "this is a todo!" lint.

TC: I see.

Josh: Considering you don't typically want to commit such code, that makes sense.

TC: I think that's right.

### "resolve: Report more visibility-related early resolution ambiguities for imports" rust#149596

**Link:** https://github.com/rust-lang/rust/pull/149596

### "Mark const SIMD intrinsics as indirectly stable" rust#149648

**Link:** https://github.com/rust-lang/rust/pull/149648

### "stabilize `cfg_select!`" rust#149783

**Link:** https://github.com/rust-lang/rust/pull/149783

### "Do not deduplicate captured args while expanding `format_args!`" rust#149926

**Link:** https://github.com/rust-lang/rust/pull/149926

### "deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls" rust#149978

**Link:** https://github.com/rust-lang/rust/pull/149978

### "Implement lint for black_boxing ZSTs" rust#150037

**Link:** https://github.com/rust-lang/rust/pull/150037

### "Resolving lang concern on `dyn`-compatibility of `final fn` trait methods (RFC 3678)" rust#150101

**Link:** https://github.com/rust-lang/rust/issues/150101

### "`#[expect(redundant_lifetimes)]` doesn't work when `#[derive(Debug)]` is present" rust#150553

**Link:** https://github.com/rust-lang/rust/issues/150553

### "Don't try to evaluate const blocks during constant promotion" rust#150557

**Link:** https://github.com/rust-lang/rust/pull/150557

### "UB inconsistency when derefing a place in a closure" reference#2121

**Link:** https://github.com/rust-lang/reference/issues/2121

### "Guarantee `repr(C)` union field offset" reference#2128

**Link:** https://github.com/rust-lang/reference/pull/2128

### "Revise decision process: champion vs FCP decisions" lang-team#360

**Link:** https://github.com/rust-lang/lang-team/pull/360

### "Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32`" rust#139087

**Link:** https://github.com/rust-lang/rust/pull/139087

### "`#![register_{attribute,lint}_tool]`" rfcs#3808

**Link:** https://github.com/rust-lang/rfcs/pull/3808

### "`RUSTC_ALLOW_UNSTABLE_<feature>`: a `RUSTC_BOOTSTRAP` alternative" rfcs#3882

**Link:** https://github.com/rust-lang/rfcs/pull/3882

### "CMSE calling conventions" rfcs#3884

**Link:** https://github.com/rust-lang/rfcs/pull/3884

### "Add `cargo_cfg_target_family_multivalued` FCW" rust#147545

**Link:** https://github.com/rust-lang/rust/pull/147545

### "Add a FRC about implicit numeric widening" lang-team#356

**Link:** https://github.com/rust-lang/lang-team/pull/356

### "RFC: cfg_target_version" rfcs#3750

**Link:** https://github.com/rust-lang/rfcs/pull/3750

### "repr(ordered_fields)" rfcs#3845

**Link:** https://github.com/rust-lang/rfcs/pull/3845

### "Match guard can both move and static-promote a single constant" rust#145237

**Link:** https://github.com/rust-lang/rust/issues/145237

### "`ref` patterns can const-promote a single constant more than once" rust#145555

**Link:** https://github.com/rust-lang/rust/issues/145555

### "Uplifts and extends `clippy::needless-maybe-sized` into rustc" rust#145924

**Link:** https://github.com/rust-lang/rust/pull/145924

### "Decide about future of `rustc_legacy_const_generics`" rust#146613

**Link:** https://github.com/rust-lang/rust/issues/146613

### "Stabilize Frontmatter" rust#148051

**Link:** https://github.com/rust-lang/rust/pull/148051

### "Tracking Issue for enum access in offset_of" rust#120141

**Link:** https://github.com/rust-lang/rust/issues/120141

### "Stabilize the `breakpoint` function" rust#142325

**Link:** https://github.com/rust-lang/rust/pull/142325

## Project goals

### "Const Generics" rust-project-goals#100

**Link:** https://github.com/rust-lang/rust-project-goals/issues/100

### "Ergonomic ref-counting: RFC decision and preview" rust-project-goals#107

**Link:** https://github.com/rust-lang/rust-project-goals/issues/107

### "Finish the std::offload module" rust-project-goals#109

**Link:** https://github.com/rust-lang/rust-project-goals/issues/109

### "Getting Rust for Linux into stable Rust: language features" rust-project-goals#116

**Link:** https://github.com/rust-lang/rust-project-goals/issues/116

### "Stabilize cargo-script" rust-project-goals#119

**Link:** https://github.com/rust-lang/rust-project-goals/issues/119

### "SVE and SME on AArch64" rust-project-goals#270

**Link:** https://github.com/rust-lang/rust-project-goals/issues/270

### "Unsafe Fields" rust-project-goals#273

**Link:** https://github.com/rust-lang/rust-project-goals/issues/273

### "C++/Rust Interop Problem Space Mapping" rust-project-goals#388

**Link:** https://github.com/rust-lang/rust-project-goals/issues/388

### "Continue Experimentation with Pin Ergonomics" rust-project-goals#389

**Link:** https://github.com/rust-lang/rust-project-goals/issues/389

### "Design a language feature to solve Field Projections" rust-project-goals#390

**Link:** https://github.com/rust-lang/rust-project-goals/issues/390

### "Develop the capabilities to keep the FLS up to date" rust-project-goals#391

**Link:** https://github.com/rust-lang/rust-project-goals/issues/391

### "Evolving trait hierarchies" rust-project-goals#393

**Link:** https://github.com/rust-lang/rust-project-goals/issues/393

### "In-place initialization" rust-project-goals#395

**Link:** https://github.com/rust-lang/rust-project-goals/issues/395

### "MIR move elimination" rust-project-goals#396

**Link:** https://github.com/rust-lang/rust-project-goals/issues/396

### "Reborrow traits" rust-project-goals#399

**Link:** https://github.com/rust-lang/rust-project-goals/issues/399

### "reflection and comptime" rust-project-goals#406

**Link:** https://github.com/rust-lang/rust-project-goals/issues/406