Triage meeting 2026-04-29

--- title: "Triage meeting 2026-04-29" tags: ["T-lang", "triage-meeting", "minutes"] date: 2026-04-29 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202026-04-29/ url: https://hackmd.io/pIbUgMQuQcGaibJcinOcEw --- # T-lang meeting agenda - Meeting date: 2026-04-29 ## Attendance - People: TC, tmandry, scottmcm, Niko Matsakis, Josh Triplett, Folkert de Vries, Jack Huey, James Muriuki, Frank Steffahn, Aapo Alasuutari, Nurzhan Saken ## Meeting roles - Driver: TC - Minutes: Nurzhan ## Scheduled meetings - 2026-04-29: "Design meeting: Reflection and comptime" [lang-team#372](https://github.com/rust-lang/lang-team/issues/372) 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 ### "Add feature gate for view_types experiment" rust#155939 **Link:** https://github.com/rust-lang/rust/pull/155939 TC: Niko, tell us about it. Niko: Wanted to get eyes on it. The intention is to experiment with minimal view types I've blogged about. Someone reached out to me saying they want to work on it. Josh: It's Sasha, that's awesome. https://smallcultfollowing.com/babysteps/series/view-types/ Niko: They'll be working on this proposal: https://smallcultfollowing.com/babysteps/blog/2026/03/21/view-types-max-min/ but with the `.` syntax Niko: I'll start working on the RFC in parallel. I'd also like us to have project goals for all active experiments and have tracking issues for them, to have a unified way to track them. Josh: When you say "with the `.` syntax", do you mean `self.messages` rather than `self {messages}`? Niko: not quite, `self.{messages}`, [see here](https://smallcultfollowing.com/babysteps/blog/2026/03/22/max-min-view-types-followup/). It's not final, but I thought it was better that I had before. tmandry: I'm excited to see view types move forward. Niko: Since I wrote the post, I've heard people say this is a gap for them. Josh: Writing a simple demo program trying to encapsulate two things and running into a borrow problem is one of the things that almost got someone off of Rust. TC: What are the dependencies here? Any blockers? Mostly all in the borrow checker? Niko: Borrow checker, mostly. If we wanted to go for extensions like aliases or ?? that don't correspond to fields, that'd be a separate discussion. Should have a shallow type-system impact and more in the lang domain. TC: Sounds like low-hanging fruit — suprising we've left it there for years. Exciting. Frank: Does this include syntax for borrowing, or is this just for method signatures? Niko: TBD. Frank: There could be a benefit in doing it in method signatures (less new syntax). Niko: I'd like for us to be able to write everything. I agree that in the common case you'd not use it. Josh: I'm assuming that the things listed as out of scope would be achievable in the future. Niko: Right, but I'd expect to stabilize without them. Josh: I'd be curious on why adding this to public functions is harder. Niko: Let's continue on Zulip. TC: Niko, thank you. We've vibe checked this. ### "validate `#[link_name = "..."]` & `#[link(name = "...")]` parameters" rust#155817 **Link:** https://github.com/rust-lang/rust/pull/155817 Folkert: This is another one of the attributes that validate the parameter they get. In this case, `link_name` is on `extern fn`s, and `link(name)` is on dynamic libraries. They shouldn't contain nulls since they're C strings, ??, and empty strings also cause issues. It's similar to `export_name` from two weeks ago, I think. TC: Makes sense. I'm looking at the tests. TC: I've proposed FCP merge. scottmcm: The only thing I'd ponder on, we could make this a lint instead of a hard error. Folkert: It's only the empty name that would cause linker errors, but there isn't value in ??. LLVM would start making up names if ??, so it's unpredictable. Given that ??, we may as well error. scottmcm: (Analysis of whether this should be an error.) TC: FWIW, Scott, I enjoy your manner of analysis on these kinds of issues. (FCP boxes checked.) scottmcm: I wouldn't want to write in the spec that we generate something random, so yeah, let's ban it. ### "Libs proposal: Policy for constifying traits and trait implementations" rust#155816 **Link:** https://github.com/rust-lang/rust/issues/155816 TC: The situation here is that we have const trait impls in nightly, and people have been constifying std on that basis. This is valuable for const trait design because it is hard and interesting to migrate std. It paints a picture of what the ecosystem might look like. The problem is that Mark is mostly the only one doing the libs reviews, and this adds load, so, reasonably, there's a question of whether we want to keep doing this. tmandry: I assume this is... a libs team matter. Frank: I also wonder what the lang ask is. TC: It's more of a heads-up. Part of the consideration is whether we would do const trait impls. ?? they may not do it, change the semantics, cause churn. For my part, I've communicated that my expectation is that we absolutely will do const traits. There are remaining questions on syntax and default bounds, which is a syntactic lowering matter. That's the lang part. scottmcm: I was going to ask something similar, if there's a particular concern that... To me it feels like we'd exepct to be able this, assuming we want const closures and loops, etc. I can't see us deeming this a mistake and not bothering. ?? stop writing manual FnOnce implementations and wait for const closures. tmandry: I agree on the general vibes that I want us to do this. As a general note, we want to let things take time and bake, but sometimes it creates uncertainty for other teams or design in general. This is not a criticism of anyone or any process. A lot of people want to see this. Sometimes moving quickly can... Niko: Can I restate? Maybe we should prioritize gettign the lang part of this decided? tmandry: Yes. TC: I agree with all of that. I see people are leaving comments. Frank: It also makes maintainability harder. The discussion addresses this pain point. It's hard for compiler devs to keep up with minor changes to const traits that might still come. TC: There's a lot of design value. If you read through the issue, there are challenges in migration, and it's useful for us to know about that for design. It'd be harder to design without knowing about those difficulties. Frank: The question is if there should be more PRs that don't add something new to design. scottmcm: For an example, we've learned what it means to drop something and const Destruct, and then we don't need to interact with that part... tmandry: Good point. We'll want to see if the Forget trait... scottmcm: I actually don't mean that... tmandry: But you've touched on a related point. We'll be seeing new implied traits being added (Forget, Move, ...) and we'll see a similar issue with those. Mostly for people's awareness, this is on the horizon. (Mark joined.) Mark: To add to Tyler's point, the general shape of the issue... I think with features like this and field projection, there's a potential for big changes in terms of LOC (churn). We struggle with this. TC: COuld you tell more what we could do for you? Mark: What we've done with projection stuff, adding documetnation up front, is a good pattern. With const, one of the big patterns called out, there's not a clear stance from lang that we want to see X kind of implementation. That leaves the question, if a user comes and wants to use an unstable feature and adds it, it's hard to refuse the change. That guidance doesn't exist. scottmcm: I like what Mark said about ??. Maybe we could have some associated meaning with labels (S-needs-baking, S-tracking). Maybe labels aren't the best way, but we could signal to contributors if they shouldn't add something to imcomplete features. Frank: ?? Mark: Whenever I look at these PRs, it's hard to answer if by constifying something, we expose something unstable in stable accidentally. Frank: I've recently seen a blog post about some trait, and they used the const keywords in the trait definition even though it's not stable. TC: .. There's some discussion about syntax, and people are expecting this to be stabilized eventually. How does ?? shape your thinking? Mark: I'm aligned with lang's expectation that this feature should land eventually. Let's say we move forward with const Destruct, then it's hard to reason about the guarantees when the bound is sprinkled everywhere (?). I don't have a good sense on how we should be making these decisions. TC: Thank you. Niko, wasn't there some work on nightly bounds? Niko: Yeah, don't know what happened to it. TC: Maybe it could help us to mark these bounds as nightly. Niko: I don't know if we talked about that or nightly impls, but that could be an option. Mark: To the extent that lang expects unstable features to be used across std, I think it would be useful to design a guarantee on some level that allows us to be confident whether we expose or not something to users. I haven't seen this sensibly thought out. If we accidentally ship const traits to stable, that'd be hard to solve. TC: Thanks for thinking about this. We should take some time to think about how to get you more help on this. ### "Document that `ManuallyDrop`'s `Box` interaction has been fixed" rust#155750 **Link:** https://github.com/rust-lang/rust/pull/155750 TC: Waffle let us know that `MaybeDangling` was implemented in December. Ralf points out that us documenting this is making a stable guarantee. tmandry: Did we RFC maybe_dangling? TC: Yes, we accepted it. https://github.com/rust-lang/rfcs/pull/3336 tmandry: So this is a partial stabilization of the RFC. I don't see anything wrong with it. TC: I'm checking the diff — what this actually says. Yes, OK. It's documenting what was undefined behavior and guaranteeing this pattern is sound after a particular compiler version. Mark: This is a prime example of something that could have been accidentally stabilized. Frank: There's already [a crate](https://docs.rs/maybe-dangling/latest/maybe_dangling/) that tracks the progress of `MaybeDangling` and offers a (limited) version of it (implemented) in terms on `ManuallyDrop` and intends to change it further (to be in terms of actual `MaybeDangling` once that's stable). So there are maybe people relying on this are already using the kind of guarantee that we're proposing to stably guarantee here. Josh: I'm staring at the doc comments changed here, and they're mentioning the pre-1.96 interaction with Box and ?? derive certain traits, and I'm trying to wrap my head around what's unsound. There's a mention of derive(Debug).. ?? Mark: The issue that... Josh: I'm asking where have they dropped the string. Mark: Line 80 in the diff. TC: One thing worth highlighting is that we're committing to `MaybeDangling` and `ManuallyDrop` not being orthogonal. That was one of the design choices. (Explains how.) This documentation would commit us to comingling the two in this way. Frank: Unions are related since ManuallyDrop is one. The question is, should this be documented for unions? (Mark corrects that MaybeUninit is the union.) tmandry: TC, what would be the purpose of making these orthogonal? TC: Optimizations. There could be a case where you want something to be manually dropped but also not lose optimization due to flagging it as `MaybeDangling`. It's probably not high value. Frank: The crate I mentioned earlier *is* using `MaybeUninit` to achieve its functionality, so this PR would allow them to move over to `ManuallyDrop`. tmandry: You said the crate uses a union internally to simulate MaybeDangling? Frank: It uses MaybeUninit. tmandry: OK. TC: Josh, you were in the meeting I assume. Given Nia's comment, I want to confirm that libs-api wants to be on the FCP. Josh: I believe they're positive on this but expected that we'd need something like a dual FCP. We had meeting consensus but we don't make decisions like this via meeting consensus. TC: Makes sense. I figured as much. Frank: TC mentioned that the orthogonality could be a possible counterargument. I wonder what would be the arguments against that were, maybe someone should look up / write down if there was anything relevant. tmandry: We may want to stabilize something more fundamental, so you could implement `ManuallyDrop` using the more fundamental thing. But I think we should do the useful thing now and handle that if it comes up later. Frank: Also, I think for the longest time (IDK the current status) the documentation for `ManuallyDrop` never mentioned the possibility of UB from merely moving a `ManuallyDrop<T>` around after (or passing it to a function) after its content have been, manually, dropped. So accepting this PR will stabilize the behavior that'll risk fewer users running into potential (highly subtle) soundness footguns. TC: I'm proposing dual FCP. ### "Stabilize c-variadic function definitions" rust#155697 **Link:** https://github.com/rust-lang/rust/pull/155697 Folkert: I'd like to discuss this. It's part of the unresolved questions: how we should handle targets, niche 3-tier targets, and verify that C variadics work there? opsem and ?? has been hammering that we should be more strict and not have tier-3 targets do weird behaviors. C variadics are radioactively unsafe, which makes Ralf anxious (justifiably so). Do we panic, put it behind a flag, or ignore? My preference is to put it behind a feature gate. We have a decent amount of confidence that the implementation works. Josh: Option 1 or 3 is potentially viable. Do we have a reasonable test suite for testing this? "Here's a C header file, ?? and Rust functions, and we verify that these don't crash?" Folkert: ??. The remaining ones are old or embedded. We do know that the test assembly matches the one clang emits modulo minor, expected changes. There's also custom targets, where we have no idea. Josh: In general, we don't run test suites for tier 3 targets. This seems likely to be the most broken thing on those targets. We might hide this behind a gate until someone tests it thoroughly. OTOH, since it's a tier 3 target, if it doesn't pass the test suite, we could consider it a normal thing. Mark: Is there a stability risk where some targets couldn't support the whole set of variadic ...? Folkert: I don't believe it to be a big risk. Usually, you have a big array of arguments, or a more fancy setup where ??. Some things like 128-bit integer support, is handled on the libs side through traits. Mark: ?? Folkert: The C standard has requirements here. There might be corner case on obscure targets that we missed. Niko: Is this unique to this feature? I'm confused what makes this special. Folkert: Ralf wants us to be strict here. This is a feature, where because of the big array you can read past of, there's big UB potential. Mark: Here, we're making target-specific decisions, unlike most features. We have an else block in the compiler that says "we don't think there's anything weird about these targets, but we haven't checked". The question is whether to put a feature gate on that else block. Josh: I think that given how much is waiting on this feature, and that it's very useful without taking the archs into account, I propose we go ahead with the third proposal (feature gating). We can consider in a future discussion whether we want to wait for tests before lifting the feature gate, or how much testing is needed for that. Let's go ahead with however much we're ready to stabilize, and then set a precedent for tier 3 targets. Folkert: Ralf mentioned that this should be part of a checklist for tier 3 targets, and surprisingly, this wasn't part of it. Josh: Yes, part of the checklist for transitioning between tiers should be ??. Would it be possible to partially resolve this through feature gating, etc.? I'm wondering if we could start an async stabilization given this has a comprehensive stabilization report. Folkert: Yes. There are a couple of WIP items, but it's pretty much done. TC: So the next step is that you'll break part of this out behind a feature flag? Folkert: Yes. There are pieces that are parts of other features (read the report). Frank: ?? The current flag should work for ?? targets... ### "Lint unused pub items in binary crates" rust#149509 **Link:** https://github.com/rust-lang/rust/pull/149509 TC: After our FCP proposal, the lint was renamed to `dead_code_pub_in_binary`. Sounds OK to me. Everyone OK with that? tmandry: Sounds fine. Josh: Sounds reasonable. TC: Then I'll reply that the remaining quorum accepted this. (The meeting ended here.) --- ### "Add lint againts invalid runtime symbol definitions" rust#155521 **Link:** https://github.com/rust-lang/rust/pull/155521 ### "error on empty `export_name`" rust#155515 **Link:** https://github.com/rust-lang/rust/pull/155515 ### "Lang proposal: const expressions in `#[repr(align)]` and `#[repr(packed)]` and friends." rust#155390 **Link:** https://github.com/rust-lang/rust/issues/155390 ### "stabilize `feature(cfg_target_has_atomic_equal_alignment)`" rust#155006 **Link:** https://github.com/rust-lang/rust/pull/155006 ### "Prevent macro expansion hang from exponential token growth" rust#154968 **Link:** https://github.com/rust-lang/rust/pull/154968 ### "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 ### "fix: fix the capture behavior of `if let` in closures" rust#154210 **Link:** https://github.com/rust-lang/rust/pull/154210 ### "Keep dyn-compatible final methods in the vtable" rust#153696 **Link:** https://github.com/rust-lang/rust/pull/153696 ### "fix(resolve): Warn on Self-Type Lifetime Elision for Non-`Self` Types" rust#153692 **Link:** https://github.com/rust-lang/rust/pull/153692 ### "Lint against iterator functions that panics when `N` is zero " rust#153563 **Link:** https://github.com/rust-lang/rust/pull/153563 ### "Do not deduplicate captured args while expanding `format_args!`" rust#149926 **Link:** https://github.com/rust-lang/rust/pull/149926 ### "Revise decision process: champion vs FCP decisions" lang-team#360 **Link:** https://github.com/rust-lang/lang-team/pull/360 ### "Reduce `unreachable-code` churn after `todo!()`" rust#149543 **Link:** https://github.com/rust-lang/rust/pull/149543 ### "resolve: Partially convert `ambiguous_glob_imports` lint into a hard error" rust#149195 **Link:** https://github.com/rust-lang/rust/pull/149195 ### "arbitrary_self_types: Split the Autoderef chain" rust#146095 **Link:** https://github.com/rust-lang/rust/pull/146095 ### "Resolver: Batched Import Resolution" rust#145108 **Link:** https://github.com/rust-lang/rust/pull/145108 ### "RFC: Associated const underscore" rfcs#3527 **Link:** https://github.com/rust-lang/rfcs/pull/3527 ### "Tracking issue for RFC 2412, "The optimize attribute"" rust#54882 **Link:** https://github.com/rust-lang/rust/issues/54882 ### "Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust (c_variadic)" rust#44930 **Link:** https://github.com/rust-lang/rust/issues/44930 ### "CMSE calling conventions" rfcs#3884 **Link:** https://github.com/rust-lang/rfcs/pull/3884 ### "`RUSTC_ALLOW_UNSTABLE_<feature>`: a `RUSTC_BOOTSTRAP` alternative" rfcs#3882 **Link:** https://github.com/rust-lang/rfcs/pull/3882 ### "Add a FRC about implicit numeric widening" lang-team#356 **Link:** https://github.com/rust-lang/lang-team/pull/356 ### "Add a note about uninhabited-struct layout optimization" lang-team#346 **Link:** https://github.com/rust-lang/lang-team/pull/346 ### "`#![register_{attribute,lint}_tool]`" rfcs#3808 **Link:** https://github.com/rust-lang/rfcs/pull/3808 ### "RFC: Allow cfg-attributes on elements of tuple type declarations" rfcs#3532 **Link:** https://github.com/rust-lang/rfcs/pull/3532 ### "Allow `UnsafeCell` in shared statics" rust#152540 **Link:** https://github.com/rust-lang/rust/pull/152540 ### "Cargo script edition policy (lang/edition aspects)" rust#152254 **Link:** https://github.com/rust-lang/rust/issues/152254 ### "Lint against inherent methods on types implementing `Receiver` and `Deref`" rust#151583 **Link:** https://github.com/rust-lang/rust/issues/151583 ### "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 ### "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 ### "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 ### "Evolving trait hierarchies" rust-project-goals#393 **Link:** https://github.com/rust-lang/rust-project-goals/issues/393 ### "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 ### "Design a language feature to solve 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 ### "Unsafe Fields" rust-project-goals#273 **Link:** https://github.com/rust-lang/rust-project-goals/issues/273 ### "SVE and SME on AArch64" 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 ### "Getting Rust for Linux into stable Rust: language features" rust-project-goals#116 **Link:** https://github.com/rust-lang/rust-project-goals/issues/116 ### "Finish the std::offload module" rust-project-goals#109 **Link:** https://github.com/rust-lang/rust-project-goals/issues/109 ### "Ergonomic ref-counting: RFC decision and preview" rust-project-goals#107 **Link:** https://github.com/rust-lang/rust-project-goals/issues/107 ### "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.