Triage meeting 2026-04-22

--- title: "Triage meeting 2026-04-22" tags: ["T-lang", "triage-meeting", "minutes"] date: 2026-04-22 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202026-04-22/ url: https://hackmd.io/W256SGfjQOOJocFBRuYp7w --- # T-lang meeting agenda - Meeting date: 2026-04-22 ## Attendance - People: TC, Josh Triplett, Tyler Mandry, Jack Huey, Mark, scottmcm, Chris Sena, Waffle, Nurzhan ## Meeting roles - Driver: TC - Minutes: Nurzhan ## Scheduled meetings - 2026-04-15: "Design meeting: Read/review RFC 3845 `repr(ordered_fields)`" [lang-team#349](https://github.com/rust-lang/lang-team/issues/349) - 2026-04-22: "Design meeting: Open enums" [lang-team#371](https://github.com/rust-lang/lang-team/issues/371) - Nurzhan: Who's preparing the design document? - TC: We'll be reading the RFC on it. - 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 ### "stabilize never type" rust#155499 **Link:** https://github.com/rust-lang/rust/pull/155499 Waffle: I've been working on finishing up never type stabilization. Have some open PRs. The first one is ready for review and t-lang approval; it's concerned with the stabilization of `!` and two changes that might need a thorough look. There's a change to the fallback behavior on all editions that we've talked about before. We've done a similar change in 2024 where `!` falls back to itself when inference can't figure out the intended type (the old behavior was falling back to `()`.) This is the big breaking change that needs to happen. Crater results: almost all the breakage comes from traits depending on old library versions. All those libs had newer versions that fixed that. IMO waiting doesn't helped because the libs have been fixed, and dependents have been receiving warnings because of the lint on the breakage. It will not be better in the future, so it's a good time to do the breaking change now. Finally, I'm removing the breakage lint because the lint is against the behavior with the unit fallback, which can no longer be triggered. Jack: There's 3k crates that break, which is a lot even if they depend on older libraries. Looking through the list, there's a lot of cases where many crates depend on one version. Is there something we can do to mitigate this, possibly in collab with crate authors, to reduce the amount of breakage? I see that, e.g., sqlx, etc., if we could issue patches... Tyler: I understand that all the crates have a patch, it's just.. Waffle: For some of the crates, the fix is in the breaking release rather than the patch version. Jack: That's what I'm saying. Maybe we could issue patches... if we did a dozen, that would reduce the breakage by half at least. For this scale, it makes a lot of difference. TC: That's still assuming people run `cargo update`, right? Jack: Not necessarily? If it's a ptch version, and they don't have a Cargo.lock, that would just be updated. Even if they do have a lockfile, if they update, they might not be updating to the latest breaking change version. In many of the cases it might require some kind of update, but it's still more likely for people to update to a minor version. In the grand scheme, I don't think it's weird for crates to sit for a year without an update. It's not hard to issue some patches to get 3k crates to not break. Josh: At the risk of asking a question that leads to a harder road, could we set the `!` fallback to `!` on a new edition, and then either not change on older editions, or wait changing on older editions until we've worked with the crate authors? That'd me more conplicated and slow, but it would give people `!` to work with, and a new edition for that work. TC: We can't. One of the blockers was that we wanted to set `Infallible = !`. For that, we need to do it across all editions. That's the context in which we FCPed the plan to stabilize the never type in https://github.com/rust-lang/rust/pull/141937: 1. Change fallback to `!` in Rust 2024. - https://github.com/rust-lang/rust/issues/123748 - Add a number of FCWs in all editions against the problematic cases, and make [`never_type_fallback_flowing_into_unsafe`](https://doc.rust-lang.org/nightly/rustc/lints/listing/warn-by-default.html#never-type-fallback-flowing-into-unsafe) deny-by-default in Rust 2024. - See <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/never-type-fallback.html>. 2. Stabilize Rust 2024. 3. At a later date when 2024 edition adoption is widespread: - Make the breaking change to fall back to `!` always everywhere. - Change `Infallible = !`. - Stabilize `!` (!). Mark: Are we currently doing FCW including dependency use for the lint? TC: Yes, and it's deny by default. Waffle: The lint has been in place for 2 years. Most libs fixed it a while ago. Since 310 days ago, we also emit it in dependencies (TC: and deny it by default). Mark: So it hasn't been a year, but long enough for people to have seen it. Jack: Unclear why we can't fallback to `!` in 2024 and newer. Waffle: The blocker issue is that the lib team wants to make `Infallibe = !` as a type alias. If you have fallback to `()`, it breaks too much code using `Infallible`. `!` coercing spontaneously to unit breaks stuff. That's why we have to do a breaking change across editions. Jack: Is there a code example that breaks like that, and a crater run that ...? Waffle: Not a recent one. There were runs before that concluded the impossibility of this. Jack: Would be good to have a recent run. Assuming most code updated to 2024, the run could be different. Waffle: I don't think most crates updated to 2024. Jack: I would like to see a code pattern that breaks when you change Infallible to ! but not update the fallback in older editions, and I'd like to see that crater run. It's even possible that maybe we can find more nuanced versions of fallback. Waffle: No, we've tried, and this really doesn't work. When you try to single out the issue, you end up with more complications and hard-to-follow rules. Jack: I'm aware of the past attempts, but those attempts more much more generalized. It's good to have the options on the table. For me, 3k crates is a lot of breakage. A year is a lot of time, but not that much. We could wait for the next edition if we wanted to. I really want `!`, but we shouldn't rush until weighing the alternatives. TC: You mentioned using the next edition. There's nothing more I know we can do with editions. If you mean releasing this all-edition change with the next edition toolchain, that's not something that I want to do from the Edition side. Jack: We need more time, maybe a year? Edition could work, probably not. The point is that we could wait longer if we needed to. Frank: Am I correct that JAck says that it could be the case that there's a way to make it so the currently intended to be stabilized inference behavior would apply to older(?) editions, and for the current... Jack: No. The behavior we want on all editions... I'm saying if we can identify the set of prolematic cases that break when you set Infallible = ! but also keep ! fallback to () in older editions. As well as having a couple example crates with the current breakage... Frank: There are two breakage patterns discussed: 1) ?? and 2) relying on () fallback. Is your suggestion to find a way to make ?? apply to older editions in a way that preserves... Jack: I expect that any nuance would only apply to the older editions. Again, I don't know what that is, but I think without examples, there's no way to know. I can imagine cases, but I don't know what the breakage looks like today and what can be done to mitigate that. Frank: What's the previous work to check if this is possible? TC: I'll find the design meeting minutes about that. It's this one, from 2024-03-13: https://hackmd.io/CwxuSa2jT7Wr_Ma86Mt4dg Waffle: IIRC, it was looking at the coercion graph of inference variables and trying to see if it would work with () and !, choosing them dynamically. Jack: At least what we had previously, you'd take the inference vars, find which one of them unify with something that's live, and if it's live, we fall back to (), otherwise !. That was an option, but I think what we do here, if anything, would be much simpler than that and more targeted to Infallible rather than !. Waffle: Hard to target Infallible when it's just an alias. Jack: There are things we can do. Mark: I tend to agree with Waffle that I'm not optimistic about finding a way to do this. People spent non-trivial amounts of time on this. Maybe there are caveats, but I'm not convinced there's a path. We should accept the breakage and encourage people to update. Maybe Jack could look into it if he feels optimistic. Tyler: The options I'm hearing: 1) wait longer; 2) land this as is; 3) have types review and find a third option. +1 to Josh on not doing the design here. The option Jack brought up to get patches out for crates with breakage... Not sure how many crates we'd need to patch. I don't think just waiting longer is appealing to me. Jack: I'm saying there are things we could do. The first step is running crater where we change Infallible to ! and don't change the fallback on older editions. Not saying we need to commit to doing it differently, just wanting to see the breakage. Maybe there's less breakage or more. Let's get more data, then we can talk specifically about addressing things then. I don't understand, if there's pushback to this, the reasons for the pushback. We've run crater, but things have changed. Josh: My suggestion: sounds like there are a couple of people who want to explore alternatives. We should time-bound that. It sounds like Jack is pointing to a specific test setup, and I think it's reasonable to try if someone's willing. We could pick a target, say, aiming to stabilize ! in 1.99 or 1.100, and try to get a few more fixes of minor crate versions in, and let Jack and others experiment with alternatives or mitigations. Either way, we're on the horizon of shippinh this soon, but at the same time, it's worth exploring. Waffle: To summarize, we want more data on whatever we need to change the fallback on odler edition. I can do the crater run and will do so sometime soon. To the point of patching crates, I think the biggest crates (sqlx, ...), I can reach out and see if I can work with them on this. I'll do that, and then we can talk when we have the data. Jack: Thanks, Waffle. Sounds great. To me, that's the minimum we should do, even if we decide to proceed with the current plan. It's fine if crate authors ignore the patches, but we should... Tyler: And if you're considering alternative migration strategies, that's a t-types matter. We don't have to talk about that here. TC: Thanks Waffle for working on the stabilization. Please renominate when this is ready for more discussion. ### "Add lint againts invalid runtime symbol definitions" rust#155521 **Link:** https://github.com/rust-lang/rust/pull/155521 TC: This is a second attempt after an earlier PR. Jack: Pointing out that one of the lint issues is on the open function, and that's not covered under current symbols checked. I like the idea that we can do better to help people to not use the same name as something else. I don't think the lint as-is does enough to solve the actual issue. The list here may help some people, but it's not what people are actually running into because the linked issues are different functions. I'm curious if there's a different way of doing this that's not just... TC: The context is that in the earlier issue, we left feedback, and Urgau is trying to make incremental progress by finding a subset that doesn't have concerns. While there's more we could later do, would you not want to do this? Jack: I do like this, but I don't know if this is... There's a problem that people write no_mangle functions that overlap with runtime functions. There's some set of function that we're gonna warn/error about. My question is, is that an effective enough overlap that the lint is actually useful? And the answer seems to be no. I want to know, is that enough? Josh: Jack, could you clarify what you mean by it not being enough? Just that it doesn't cover "open"? Jack: I mean that there's six functions currently checked. Are people actually writing these functions and marking them no_mangle? Tyler: This PR doesn't check for read. Josh: I appreciate Jack's point that it doesn't cover the reports. Josh: That's my reaction as well. I like the lint. There's an unbounded amount of functions to cover. We had two specific reports where this confused people and seemed like a common case to hit. My intuition is to say that we like the link and ask Urgau to cover the reported cases. And we can add more later. Tyler: This is a deny by default lint for invalid definitions. This sort of overrides the definition of existing symbol, loosely speaking. Makes sense to me as a DBD lint. Those () probably shouldn't be DBD because there are cases where you'd want to write these functions. We might want to consider a different lint for them. TC: For my part, here my question for this room: I'm planning to propose FCP merge. This makes sense to me. What Urgau is trying to do by not handling the non-core std cases is to avoid the concerns we had raised about linting on `std` cases with `no_std`. Urgau can handle the rest separately. I don't want to block this incremental progress. Is somebody going to raise a concern or not check a box? Josh: If the goal is incremental progress and eventually shipping a lint, alloc and std... then it seems fine. My only concern would be failing to follow through or shipping something that covers the original cases we asked to make better. If the lint brings us closer to that, fine. If we can add ?? that's deny by default unless you make the allow by default... Jack: I don't think I'll raise a concern, but it feels weird if this weird won't fix the cases people actually reported as confusing. Maybe people are writing this intentionally. If there are cases where people are saying that they're running into this accidentally, this lint would help. This seems stronger, where we're saying that if you write this, you're always making a mistake. TC: Jack, you mentioned this maybe firing as a false positive more often than as a true positive. How could someone use this in a way that's a false positive, given that it's checking the signature and only firing on `core` cases? Jack: I don't know, but nobody has told us they've run into this either way. It's subtle. It's nice to have that lint, but it's not something people asked for in this capacity. scottmcm: linting on this when we discuss it explicitly in <https://doc.rust-lang.org/nightly/core/#how-to-use-the-core-library> makes sense to me, since it's doing a signature check. I don't think we need to worry about whether other lints would be nice. Jack: That's convincing. Frank: In the PR discussions so far, there's mention that this PR replaces the previous, and that this PR is based on the user reports. ?? But it shouldn't stop the current PR. Tyler: I'll check the box. Since this is pretty much always UB, we should lint on it. Jack: I'm convinced by scottmcm's argument, but ?? Tyler: Do you want to leave a comment asking that? Jack: I will. scottmcm: As lang, we should say that there are a bunch of well-known names we use. We shouldn't approve the exact list, just say which names we use, and let people update the list. ### "error on empty `export_name`" rust#155515 **Link:** https://github.com/rust-lang/rust/pull/155515 Josh: This was an attribute that we added, and the original intent was to specify a name. There was some expected behavior when you specified no name, but that was buggy and problematic. This is removing the case that allowed doing that. I think this was just a missed detail of "this doesn't work, let's not allow it" TC: This is about setting export name to an empty string. Are there other invalid values? Josh: They cover some cases in tests, like embedded nulls. Primarily they cover embedded nulls or empty string. TC: Makes sense. I'll propose FCP merge. Josh: There's a comment in the PR explaining what's wrong. LLVM makes up a name if you don't provide one, but sometimes... ...so it won't link. TC: Interesting. I've proposed FCP merge. ### "stabilize `feature(cfg_target_has_atomic_equal_alignment)`" rust#155006 **Link:** https://github.com/rust-lang/rust/pull/155006 Waffle: I proposed this. The idea is that I was trying to suggest to libs to stabilize Atomic... from mut and get mut functions. The fn transforms a &mut int to Atomic of the same width. On some platforms, atomics may have a higher alignment than normal ints... For this reason we have cfg_target_has_atomic_equal_alignment since it's blocked on ??, I was asking if we can just stabilize it. Josh: You can take a `&mut u64` and get `&mut AtomicU64` from it. Tyler: Is it a coercion? Josh: It's a function. It's a lib function, but the one thing blocking it is that it can't exist everywhere. TC: I recall talking about this before. We'd said if we had `cfg_accessible`, that's how we would expose this. Josh: We got consensus on that we *could* use it for that, and we didn't evaluate whther we *should* because that was academic if we won't have it any time soon. Waffle: It sounded like we wouldn't have cfg_accessible any time soon, so this is how we would stabilize this, I thought Josh: ?? doesn't mean we shouldn't ship more things... TC: We talked about this in a prior meeting about `cfg_accessible` and what else it would obsolete. Josh: There's also one for pointer. Josh: Instead of doing cfg unix, you could say "do i have the unix domain module"... Tyler: Does anyone has an issue with stabilizing this? I'll check my box. The name is complicated, but it's niche. We could have a better feature if we ship cfg_accessible. TC: Are there better names for this? This isn't a great name; it's worth taking a minute on this. Josh: Ship it. cfg_target_has is necessary, and atomic_equal_alignment we could shorten to atomic_eq_alignment... but not sure if it can be shorter. TC: I'm not worried about the length, just the clarity. It's opaque. I don't have better names immediately. Josh: I don't see any one or two words that make this easier. Frank: Standard, normal alignment? Some adjective could indicate that it's the same as the normal... (Naming discussion...) Josh: The problem with the specific targets is not the alignment of atomic, but the alignment of non-atomic... The bug is with non-atomics having too little alignment. TC: I agree that "has" should come first. The problem is the word "equal" for reasons Frank described. TC: We're out of time. We'll continue this later. ### "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 ### "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 ### "Fields must fit in the type, even for repr(Rust)" reference#2166 **Link:** https://github.com/rust-lang/reference/pull/2166 ### "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 ### "UB inconsistency when derefing a place in a closure" reference#2121 **Link:** https://github.com/rust-lang/reference/issues/2121 ### "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