Triage meeting 2026-06-03

--- title: "Triage meeting 2026-06-03" tags: ["T-lang", "triage-meeting", "minutes"] date: 2026-06-03 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202026-06-03/ url: https://hackmd.io/KITX9y0PSOqaj0E34XaDNw --- # T-lang meeting agenda - Meeting date: 2026-06-03 ## Attendance - People: TC, Josh, Niko, Tyler, Mark, Jack, Chris Sena, Frank, Nurzhan, RustyYato, zachs18 ## Meeting roles - Driver: TC - Minutes: Nurzhan ## 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!) ## Nominated RFCs, PRs, and issues ### "stabilize feature `float_algebraic`" rust#157029 **Link:** https://github.com/rust-lang/rust/pull/157029 TC: This is about stabilizing some intrinsics with a corresponding libs stabilization. (Explains the intrinsic.) Josh: This presumably allows optimizations ..., anything that would be algebraically correct. Is that right? TC: Yes. LLVM has flags for optimizations that this sets. Josh: I've been following this and checked the libs FCP. Tyler: I need something I can read. Is there a TL;DR on what this is? Josh: https://doc.rust-lang.org/std/primitive.f32.html#algebraic-operators Mark: There's also a comment by Ralf. Tyler: I see, the operations are the same but we tell the LLVM it can reorder them as if they were algebraic... TC: That's right. Tyler: Seems useful, great. So we'll be exposing the intrinsics, and this will be available on all targets we support. I'm happy with it. Is there a box to check? TC: Yes... (FCP started.) ### "stabilize optimize attribute" rust#157273 **Link:** https://github.com/rust-lang/rust/pull/157273 TC: I looked at this last night. Personally, ready to fire FCP. There are open questions, though. Maybe a bit premature to fire it from the compiler standpoint. Since the RFC, I think optimizer none was added, but it's OK(?). Josh: From lang semantics persp, reasonable. But if ocmpiler thinks it's not ready, we should wait for their OK. TC: It's OK for reasons: (?). We should probably answer these before FCP even though it's not a lang concern. ?? The author should add test cases for that. Josh: Seems like a good case study in multi-team FCP... Tyler: Are you saying you want to raise lang concerns? TC: No questions. Waiting for the author to ... and planning to propose dual FCP merge. Tyler: Sounds good to me. ### "Move logic for emitting UNSAFE_CODE for unsafe attributes to attr parsing" rust#157201 **Link:** https://github.com/rust-lang/rust/pull/157201 Josh: An interesting one. TC: This is one of the attribute cleanups. I proposed FCP merge. There are some new labels you can see on this. It's mostly an impl detail on where we check for ?? attributes. Ralf is moving the check to the outer layer rather than checking on every inner attribute. Mark: Is there a description of the stable change from this? https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a9262eaa3b411932d4ae01704d69016d Josh: I think I understand, can you send the playground link? Sounds like it's saying that the lint might not be firing on all unsafe attributes. Maybe adding ?? or deny unsafe code might cause ??. TC: It's not a failure to write unsafe. The question is whether the lint (allow-by-default ??) is ??. Mark: So it's about the lint. Makes sense. Josh: As far as I can tell, would be helpful to confirm by getting the various incantations of the ?? correct. RustyYato: https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=4f93d92b69886870d7325d64ce878336 Tyler: Sounds trivial, checking a box. Josh: ~~I'm confused on why it compiled rather than saying it's unstable.~~ because the playground I was starting from didn't have `extern "C"`; RustyYato's example added it. TC: Naked functions are stable. ### "Add a new lint `UNCONSTRUCTIBLE_PUB_STRUCTS`" rust#146440 **Link:** https://github.com/rust-lang/rust/pull/146440 TC: I proposed FCP merge while this had a different name. If your struct does not appear ?? anywhere in the public API, and it's uninhabited, and all of the fields are (not?) ZSTs, and all fields are public, then we lint that the struct is unconstructible. We discussed cases where, e.g., structs with a trailing DST field... In those cases the author pointed out that it'd make sense to have that field public because ??, so the lint wouldn't fire because the field is public. I suggested extending this a bit such that ??, which the author adopted (e.g. checking uninhabitedness beyond `!`). I proposed FCP merge based on... Josh: note on spelling: https://www.merriam-webster.com/dictionary/constructable > constructability noun > or less commonly constructibility It was originally "constructible" and someone correctly corrected it to "constructable". Tyler: Motivation for the lint? TC: Cleaning up things that are logically unused on the public interface. Josh: Normally we warn about unused structs. If you mark it pub, the assumption is that you'd use it from outside. But if it's pub and no way to construct it, so pub shouldn't change the unusedness. Jack: Am I correct that there's a crater run and 2500 crates are affected? (TC: yes). MAybe we should start by allowing by default, and then...? TC: That'd be a lot of breakage but we don't run crater regularly enough when adding warn-by-default lints to have a good baseline for where this falls in the spectrum. Tyler: I don't consider added warnings breakage. Curious about the specific cases. Jack: I'm just saying it seems like a lot, and maybe we want to allow it at first. Josh: I personally hit this myself and would have appreciated this lint. It's easy to end up in this situation while refactoring... To Jack's point, I think the number is concerning, but at the same time we probably won't move the needle much by making it allow-by-default. I'm a fan of starting with warn and moving to deny, but by starting with allow we might find ourselves in a situation where even more crates are affected as time passes. (Constructible vs. constructable spelling.) TC: If you (Josh) want to file a naming concern, feel free. Tyler: The only problem I have... Is there a write up on the exact rules of the lint? Frank: TC summarized it in the beginning, but the notes seem wrong. scottmcm: I agree that starting with warn is fine. I wonder if there's a specific pattern that triggered most of the crater failures. Mark: I left a comment on the PR. Most of them are allow(dead_code) ?? tests... Should this be under unused? Feels closer to dead_code to me. TC: dead_code is an unused lint (?) Mark: Then I don't understand how it's failing. Frank: ?? Mark: Seems like a subset of failures are tests that are... Niko: I was surprised that we didn't call this dead_code (?) and had a specific name for it. On constructable vs. constructible, I think neither might be right (?). I don't fully understand our naming convention between dead_code and unused. TC: It's in the unused lint group but doesn't use unused in the name... Josh(chat): unused_pub_struct_cannot_be_constructed Josh: +1 to maybe not using the word in the lint to avoid the spelling debate. Niko: Let's move the bikeshed offline. Frank: The error message could be more complete. Doesn't seem to mention inhabitedness. You can't remove a public type without breakage, but... This comment clarifies that unconstructible structs, as well as ZSTs, are excempt from the lint, so the lint won't fire for those (just as clarification for ppl reading these notes ^^) ... https://github.com/rust-lang/rust/pull/146440#issuecomment-4585654893 ### "`dyn Allocator` together with `Allocator + Clone` requirements is unsound, leading to UB with `Arc`" rust#156920 **Link:** https://github.com/rust-lang/rust/issues/156920 TC: We talked about this last week. There's an ask for us to do something, and I don't think it's relevant anymore. Josh: The nomination is stale. The libs is working on other candidates that don't involve lang changes. I propose to unnominate this and nominate again if there are new questions. TC: There was some pressure on us last week to signal our OKness on a lang feature during a call, and we almost had an inclination to say yes. It would've been a bad look for us to have OKd that then. It's worth having a write up and thinking about it more. ### "Add `T: PartialEq` bounds to derived `StructuralPartialEq` impls." rust#156807 **Link:** https://github.com/rust-lang/rust/pull/156807 TC: Theemathas raised an interesting issue, as he often does, finding that there's a case where using a const in a pattern doesn't match what you'd expect to get when ... (Explains.) Tyler: I need to see the impl we generate before/after. Tyler: I don't understand the connection to coherence but believe it exists. Josh: The issue is when we're deriving PartialEq on a generic, we attach StructuralPartialEq when ..., but that bound doesn't make assumptions on what we recurse into. Tyler: ?? TC: Because of `None`. We need to do value-based reasoning. ```rust const X: Option<Box<()>> = None; fn main() { if let X = X {} } ``` TC: FCP is up. Josh: I understand the coherence issue. PartialEq written here wouldn't have been possible if we had the bound because they would be mutually exclusive, right? TC: Maybe what you said is correct. ...putting a bound prohibits this case because ?? is not PartialEq. There are two cases here, one blocked by coherence, and the other by requiring a bound. Tyler: You could write PartialEq on Incomparable? TC: No because you'd be conflicting with derived PartialEq. Tyler: I see. That's quite subtle. Maybe there's another framing that makes this more obvious. I'm surprised we allowed this in the first place. The fact that putting a bound on StructuralPartialEq prevents you from ... PartialEq... I need to sit with this for a while. Niko: Looking at the test in the PR, it's not failing in coherence, which I think is correct, but I guess it's not impl PartialEq for Incomparable if that's the point. Tyler: Good point. You're right, we get the error on the actual comparison. It fits better into my mental model of how Rust works. Josh: I tested some corner cases... theemathas: see my comment on the pr (https://github.com/rust-lang/rust/pull/156807#issuecomment-4614234339) Tyler: I'm checking my box. ### "Document that `ManuallyDrop`'s `Box` interaction has been fixed" rust#155750 **Link:** https://github.com/rust-lang/rust/pull/155750 scottmcm: In FCP now. ### "Add lint againts invalid runtime symbol definitions" rust#155521 **Link:** https://github.com/rust-lang/rust/pull/155521 TC: We finished FCP. Renominated because there was a discussion on why this hasn't been merged yet. After the FCP... It does what we expect given the ABI compatibility. Josh: Urgau reached out during AH. I said that it makes sense to check for ABI compatibility... Potentially relevant for Rust in the kernel, but you won't have std in that case. Alice said we shouldn't accept that, so I think we should consider that. scottmcm: Once we're talking FFI, ABI being the thing we care about is obvious. I want to write `NonNull<T>` on the Rust side when it's the better type, and getting a lint against it is not what I want here. These aren't POSIX symbols, but... TC: Makes sense. How about we leave comments on the thread and see how it lands. ### "stabilize never type" rust#155499 **Link:** https://github.com/rust-lang/rust/pull/155499 scottmcm: dunno if this is *easy* but optimistically pulling it up in hopes that the seventh time we can stabilize :) TC: Checking in here. We've talked about this and have a plan. Since last time, waffle made PRs to multiple projects for semver stability. Maintainer of ?? said thank you. How do people feel about this? Tyler: Pretty good. Met with waffle during RW. Feeling positively about moving forward. Jack: I don't think this is ready yet? IIRC, waffle talked about mitigating breakage last time. I think it's too soon for a lang team check-in. TC: What's the shape of what you're expecting? Jack: Don't know the exact details, but lcnr and waffle have been talking about type system hacks to mitigate breakage. I think we shouldn't talk about this without waffle. Tyler: Was this nominated or just queued? TC: It was sitting in the queue, and I renominated it. I'll check in with waffle based on what Jack said and see what waffle and lcnr are thinking. Jack: It would be good to check in with them. Tyler: I have notes from talk with waffle. There are around 15 crates that have regressed, and they all have new versions. Not all of them are semver compatible with all crates. There's only so much we can do to prevent breakage. Given that we had this FCW for a while, we'll have to ship it. Jack: Agreed, but if there's something they've talked about, I'd rather hear directly from them. ### "make repr_transparent_non_zst_fields a hard error" rust#155299 **Link:** https://github.com/rust-lang/rust/pull/155299 TC: Filed and resolved concern (on generativity), this is in FCP. ### "Named `Fn` trait parameters" rfcs#3955 **Link:** https://github.com/rust-lang/rfcs/pull/3955 ### "Stabilize c-variadic function definitions" rust#155697 **Link:** https://github.com/rust-lang/rust/pull/155697 ### "Lint against iterator functions that panic when `N` is zero " rust#153563 **Link:** https://github.com/rust-lang/rust/pull/153563 ### "arbitrary_self_types: Split the Autoderef chain" rust#146095 **Link:** https://github.com/rust-lang/rust/pull/146095 ### "`#![register_{attribute,lint}_tool]`" rfcs#3808 **Link:** https://github.com/rust-lang/rfcs/pull/3808 ### "RFC: Associated const underscore" rfcs#3527 **Link:** https://github.com/rust-lang/rfcs/pull/3527 ### "Improve the documentation around layout guarantees given by `Box`" rust#155597 **Link:** https://github.com/rust-lang/rust/pull/155597 ### "CMSE calling conventions" rfcs#3884 **Link:** https://github.com/rust-lang/rfcs/pull/3884 ### "RFC: Allow cfg-attributes on elements of tuple type declarations" rfcs#3532 **Link:** https://github.com/rust-lang/rfcs/pull/3532 ### "Vibe check: can `Simd<T, N>: Receiver<Target = T>`?" rust#156270 **Link:** https://github.com/rust-lang/rust/issues/156270 ### "Allow `UnsafeCell` in shared statics" rust#152540 **Link:** https://github.com/rust-lang/rust/pull/152540 ### "When matching on enums, read the discriminant even if there's only a single variant" rust#154756 **Link:** https://github.com/rust-lang/rust/pull/154756 ### "Fields must fit in the type, even for repr(Rust)" reference#2166 **Link:** https://github.com/rust-lang/reference/pull/2166 ### "Lint against inherent methods on types implementing `Receiver` and `Deref`" rust#151583 **Link:** https://github.com/rust-lang/rust/issues/151583 ### "UB inconsistency when derefing a place in a closure" reference#2121 **Link:** https://github.com/rust-lang/reference/issues/2121 ### "Do not deduplicate captured args while expanding `format_args!`" rust#149926 **Link:** https://github.com/rust-lang/rust/pull/149926 ### "Add a FRC about implicit numeric widening" lang-team#356 **Link:** https://github.com/rust-lang/lang-team/pull/356 ### "Decide about future of `rustc_legacy_const_generics`" rust#146613 **Link:** https://github.com/rust-lang/rust/issues/146613 ### "Uplift and extend `clippy::needless-maybe-sized` into rustc" rust#145924 **Link:** https://github.com/rust-lang/rust/pull/145924 ### "`ref` patterns can const-promote a single constant more than once, and can both const-promote and move from the same value." rust#145555 **Link:** https://github.com/rust-lang/rust/issues/145555 ### "Add a note about uninhabited-struct layout optimization" lang-team#346 **Link:** https://github.com/rust-lang/lang-team/pull/346 ### "Match guard can both move and static-promote a single constant" rust#145237 **Link:** https://github.com/rust-lang/rust/issues/145237 ### "repr(ordered_fields)" rfcs#3845 **Link:** https://github.com/rust-lang/rfcs/pull/3845 ### "RFC: cfg_target_version" rfcs#3750 **Link:** https://github.com/rust-lang/rfcs/pull/3750 ### "Stabilize the `breakpoint` function" rust#142325 **Link:** https://github.com/rust-lang/rust/pull/142325 ### "Tracking Issue for enum access in offset_of" rust#120141 **Link:** https://github.com/rust-lang/rust/issues/120141 ## Project goals ### "Wasm Components" rust-project-goals#656 **Link:** https://github.com/rust-lang/rust-project-goals/issues/656 ### "Stabilizing `f16`" rust-project-goals#655 **Link:** https://github.com/rust-lang/rust-project-goals/issues/655 ### "Stabilize the Try trait" rust-project-goals#654 **Link:** https://github.com/rust-lang/rust-project-goals/issues/654 ### "Stabilize never type (`!`)" rust-project-goals#653 **Link:** https://github.com/rust-lang/rust-project-goals/issues/653 ### "Stabilize concrete type specialization" rust-project-goals#652 **Link:** https://github.com/rust-lang/rust-project-goals/issues/652 ### "Redesigning `super let`: Flexible Temporary Lifetime Extension" rust-project-goals#648 **Link:** https://github.com/rust-lang/rust-project-goals/issues/648 ### "Prepare TAIT + RTN for stabilization" rust-project-goals#646 **Link:** https://github.com/rust-lang/rust-project-goals/issues/646 ### "Open Enums" rust-project-goals#645 **Link:** https://github.com/rust-lang/rust-project-goals/issues/645 ### "Normative Documentation for Sound `unsafe` Rust" rust-project-goals#644 **Link:** https://github.com/rust-lang/rust-project-goals/issues/644 ### "Nightly support for function overloading in FFI bindings" rust-project-goals#643 **Link:** https://github.com/rust-lang/rust-project-goals/issues/643 ### "Implement Supertrait `auto impl`" rust-project-goals#636 **Link:** https://github.com/rust-lang/rust-project-goals/issues/636 ### "Immobile types and guaranteed destructors" rust-project-goals#635 **Link:** https://github.com/rust-lang/rust-project-goals/issues/635 ### "Explicit tail calls & `loop_match`" rust-project-goals#634 **Link:** https://github.com/rust-lang/rust-project-goals/issues/634 ### "Evolving the standard library API across editions" rust-project-goals#633 **Link:** https://github.com/rust-lang/rust-project-goals/issues/633 ### "Declarative (`macro_rules!`) macro improvements" rust-project-goals#629 **Link:** https://github.com/rust-lang/rust-project-goals/issues/629 ### "Control over Drop semantics" rust-project-goals#628 **Link:** https://github.com/rust-lang/rust-project-goals/issues/628 ### "Case study for experimental language specification, with integration into project teams and processes" rust-project-goals#627 **Link:** https://github.com/rust-lang/rust-project-goals/issues/627 ### "Box notation for dyn async trait" rust-project-goals#625 **Link:** https://github.com/rust-lang/rust-project-goals/issues/625 ### "BorrowSanitizer" rust-project-goals#624 **Link:** https://github.com/rust-lang/rust-project-goals/issues/624 ### "Arbitrary Self Types" rust-project-goals#619 **Link:** https://github.com/rust-lang/rust-project-goals/issues/619 ### "reflection and comptime" rust-project-goals#406 **Link:** https://github.com/rust-lang/rust-project-goals/issues/406 ### "Reborrow traits" rust-project-goals#399 **Link:** https://github.com/rust-lang/rust-project-goals/issues/399 ### "MIR move elimination" rust-project-goals#396 **Link:** https://github.com/rust-lang/rust-project-goals/issues/396 ### "In-place initialization" rust-project-goals#395 **Link:** https://github.com/rust-lang/rust-project-goals/issues/395 ### "Field Projections" rust-project-goals#390 **Link:** https://github.com/rust-lang/rust-project-goals/issues/390 ### "Continue Experimentation with Pin Ergonomics" rust-project-goals#389 **Link:** https://github.com/rust-lang/rust-project-goals/issues/389 ### "C++/Rust Interop Problem Space Mapping" rust-project-goals#388 **Link:** https://github.com/rust-lang/rust-project-goals/issues/388 ### "Stabilize Unsafe Fields" rust-project-goals#273 **Link:** https://github.com/rust-lang/rust-project-goals/issues/273 ### "Sized Hierarchy and Scalable Vectors" rust-project-goals#270 **Link:** https://github.com/rust-lang/rust-project-goals/issues/270 ### "Stabilize cargo-script" rust-project-goals#119 **Link:** https://github.com/rust-lang/rust-project-goals/issues/119 ### "Stabilize the next-generation trait solver" rust-project-goals#113 **Link:** https://github.com/rust-lang/rust-project-goals/issues/113 ### "Ergonomic ref-counting" rust-project-goals#107 **Link:** https://github.com/rust-lang/rust-project-goals/issues/107 ### "Const Traits" rust-project-goals#106 **Link:** https://github.com/rust-lang/rust-project-goals/issues/106 ### "Full Const Generics" rust-project-goals#100 **Link:** https://github.com/rust-lang/rust-project-goals/issues/100

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.