Triage meeting 2025-11-26

--- title: Triage meeting 2025-11-26 tags: ["T-lang", "triage-meeting", "minutes"] date: 2025-11-26 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-11-26/ url: https://hackmd.io/n-_7HNVkRly3g1CTUNDB7A --- # T-lang meeting agenda - Meeting date: 2025-11-26 ## Attendance - People: TC, tmandry, Josh, scottmcm, Jack, Yosh, Nadri, theemathas, Mark ## Meeting roles - Driver: TC - Minutes: TC ## 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!) ### 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. ### Next meeting with RfL We're next meeting with RfL on 2025-12-03 to review the status of RfL project goals. https://github.com/rust-lang/rfcs/pull/3614 ## Nominated RFCs, PRs, and issues ### "Explicitly export core and std macros" rust#139493 **Link:** https://github.com/rust-lang/rust/pull/139493 TC: Jane looked into this on a preliminary basis, but she's still looking into it. We'll wait for that. Josh: Looking forward to this one but yeah, let's let it cook a little longer. ### "`format_args` deduplicates consts with interior mutability or destructor" rust#145739 **Link:** https://github.com/rust-lang/rust/issues/145739 TC: We had asked for volunteeers and offered support; ShoyuVanilla has volunteered to work on this. How do we best suppport that, e.g. by assigning a champion? Jack: That person does work on rust-analyzer. Josh: I'll post something encouraging. ### "Don't strip shebang in expr-ctxt `include!(…)`" rust#146377 **Link:** https://github.com/rust-lang/rust/pull/146377 TC: This was raised by the frontmatter work. We can't strip the frontmatter with `include!` in an expression context -- it's a breaking change due to the fact that `-` can be parsed as an expression. So this now asks, should we even be stripping the shebang in an expression context? tmandry: It seems surprising that we're stripping things at all. Josh: It seems sensible to take the step of not stripping in an expression context if crater looks OK. This seems to be an improvement in consistentcy, whether we go further or not. TC: I'm not endorsing it, but for context, the other option for restoring consistency is that, over an edition, we could do stripping in expression context for frontmatter. scottmcm: If we want to go further, since it's not stable yet, we could not strip frontmatter even in item context when we stabilize it. TC: Not stripping in item context can only break things, right? It can't make anything work. scottmcm: It'd simplify the definition of `include!`. Josh: It'd be interesting to see a crater run that strip everywhere. TC: Other languages do this stripping -- as I recall -- Python, Perl, etc., with their similar include mechanisms. I'd estimate that's where we got this from. tmandry: I think I'm persuaded that not stripping in item context can't help anyone. Jack: I'd like us to have the data on whether we could go further before making a lang decision; this influences what we'll want to do with frontmatter. tmandry: This is asking for more from the author than is needed for this incremental step; that has a cost. TC: Jack, what would make sense would be for your concern here to go on the frontmatter stabilization rather than on this issue; if you want to put it there, I'll proxy it. Jack: Sounds good. ### "Revert "Do not check privacy for RPITIT."" rust#146470 **Link:** https://github.com/rust-lang/rust/pull/146470 TC: I proposed FCP here. Are we waiting on anything? Josh: On review, I checked a box here. It seems to be moving toward consistency and removing a special case. tmandry: I'll probably need to look at it. ### "Stabilize Frontmatter" rust#148051 **Link:** https://github.com/rust-lang/rust/pull/148051 TC: I proposed FCP, after reviewing carefully, and filed a set of concerns. (Describes the concerns.) TC: Within the concerns, one of the lang questions is whether we care about preserving CFG-ness. It seems at this point worth preserving to me. Naddri: I care. Josh: I don't think we need to preserve it, but I think there are practical reasons to add a limit here. scottmcm: I would also like the 255 limit. It was useful in strings to have a smaller count to keep the in-memory sizes small anyway. tmandry: Was preserving CFG-ness the thing that's why we still have turbofish? TC/Josh: No, that was originally about lookahead, and then about general ambiguity. Nadri: The turbofish example: https://github.com/rust-lang/rust/blob/main/tests/ui/parser/bastion-of-the-turbofish.rs ## Nominations, part 2 People: TC, tmandry, Josh, Nadri, Jack, Yosh, scottmcm, Mark ### "Stabilize the `supertrait_item_shadowing` feature" rust#148605 **Link:** https://github.com/rust-lang/rust/pull/148605 TC: Josh proposed FCP. Scott has now checked a box. I've now filed a concern due to this still needing proposed language for the Reference. ### "Warn on codegen attributes on required trait methods" rust#148756 **Link:** https://github.com/rust-lang/rust/pull/148756 TC: Scott has now also checked a box on the proposed FCP. The author has asked Jack whether the recent work addresses his concerns. Jack, what do you think? Jack: I'll look over this async. tmandry: Niko proxied the concern, so we'll need him back. Josh: There's a notably one crate affected. Jack: We now have data that we can't remove it immediately, but this is what FCWs are for, when we want to remove it eventually. I'll leave a comment so Niko can resolve the concern. ### "Tracking Issue for `FnStatic` and `FnPtr::addr`/`from_ptr`/`as_ptr` and `Code`" rust#148768 **Link:** https://github.com/rust-lang/rust/issues/148768 TC: Where did we leave this? tmandry: I had wanted to think about the implications. There's been discussion of how people could use a type alias for `NonNull<Code>` (for `as_ptr`) to help if we were to later change things to support platforms where the size of a code pointer and a data pointer are different. What I'd propose is that we add the type alias ourselves. Josh: Regarding the idea of separating "code pointer" and "data pointer", that ship has already sailed, and circumnavigated the globe. Trying to address that as part of this change can only produce inconsistencies. No objection to experimenting with it, but I'd like to hold off on stabilizing `as_ptr` and `Code`, and use a separate feature flag for them. tmandry: It makes sense to separate that out. tmandry: Let's talk about how `FnStatic` fits in the language. ``` fn f<F: FnStatic(A, B), A, B>(a: A, b: B) { (F::as_fn())(a, b) F::call_static((a, b)) // unstable? F(a, b) // possible extension } ``` TC: Are we / should we be using the `Fn(A, B) -> R` parens syntax for bounds and for calls one the generic parameter? Nadri: sounds important since it's part of the Fn trait hierarchy tmandry: One of the things the `Fn() -> R` syntax lets us do is relax default bounds like `Destruct` on `Fn::Output`, since today you always have to specify a type `R` in your bound. TC: Do we have a champion assigned to this? tmandry: Not that I'm aware of. TC: Should we? tmandry: Probably. We may need an RFC here. I can champion it. Jack: It seems at some point the types team should be looped in here. TC: That seems a good thing for the champion to navigate. ### "Derive macros that emit unsafe code can't rely on mentioning the field type twice" rust#148793 **Link:** https://github.com/rust-lang/rust/issues/148793 TC: We had discussed this in the context of proc macro nondeterminism. After we did that, Hanna suggested that we had missed it; that it's not just about proc macro nondeterminism but about other things in the language to which this can also apply, e.g. CTFE. I asked RalfJ about this. RalfJ points out that const items are deterministic, but const expressions are not. tmandry: I'll leave a comment here. TC: We had said "proposals welcome", and that still seems to be the state. ### "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: This had come up because we noticed that we expose into stable Rust today details of how we do and optimize typed copies. There are two solutions to this. One is to always uninit the padding on the typed copy -- that's the more ideal solution, but it's believed to be expensive. The other is to always copy the provenance of the bytes during the typed copy. There were questions of whether that would be too expensive, but in testing, it doesn't seem to be. (Discussion of various things about typed copies and UB.) TC: We recently improved our documentation about typed copies with `MaybeUninit`: https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#validity scottmcm: I think I can write up an example of the typed/untyped copy thing I'm thinking about. I'll do that and put it in the thread. TC: To enumerate the options here: - We can always do a mem-to-mem copy, i.e. all destination bytes are overwritten by source bytes. - We can do a typed copy such that destination padding bytes already initialized are preserved. - We can do a typed copy such that destination padding bytes already initialized become uninitialized. scottmcm: Here's my example, which I also commented: <https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=6eaa98357d3bdc1534f4b3cd5b1629f5> ```rust use std::mem::MaybeUninit; #[derive(Debug, Copy, Clone)] struct Demo(u8, u16); let first = MaybeUninit::<Demo>::zeroed(); let mut second = MaybeUninit::<Demo>::uninit(); *second.as_mut_ptr() = *first.as_ptr(); // <-- HERE let demo: u32 = std::mem::transmute(second); dbg!(demo); ``` Nadri: I'm quite confused, this seems to be asking to change opsem lightly between const-eval and runtime Rust? Josh, TC: Not quite. Nadri: rephrased: If I evaluate the code using _some valid Rust evaluator_, which today is allowed to reset padding on typed copies, then this would not match what rustc computes? seems bad. TC: We're at the point here where it'd make sense to comment on the issue with our questions and a clear statement of what we're doing here. Nadri: I'll chat with Ralf to clarify ### "`cfg_select` should check for `unexpected_cfgs` on other arms" rust#149090 **Link:** https://github.com/rust-lang/rust/issues/149090 Josh: This is about extending the `unexpected_cfgs` check to all arms. TC: That makes sense; anyone think it doesn't? tmandry: There was an interesting discussion, on something else related to `cfg_version`, about whether we should always be short-circuiting. We'd want `cfg_select` to be consistent with `all`, `any`, etc. tmandry: I agree with the consistency argument for now. Josh: I've left a comment. ### "Add a new lint `UNCONSTRUCTABLE_PUB_STRUCT` to detect unconstructable public structs" rust#146440 **Link:** https://github.com/rust-lang/rust/pull/146440 TC: This lint should be named in the plural, if we do it at all. Mark: It looks like this was unnominated some weeks ago originally. In the later work, this is moving toward an allow-by-default lint based on limits of what we can catch. Based on that, I'm not sure this actually carries its weight. Mark: It seems this should just be considered part of the dead code lint. Josh: That seems sensible. scottmcm: The part we could argue could be separate is that it's not dead, it just should be `pub(crate)`. Josh: If you did that, then it would be marked as dead, as it would never be constructed. scottmcm: So it's not unconstructable, it's unconstructed. Tyler: Example of code where you might want this... ```rust pub struct Mut(!); pub struct NonMut(!); pub trait Mutness { type Ref<'a, T> where Self: 'a; } impl Mutness for Mut { ... } impl Mutness for NonMut { ... } ``` scottmcm: Could always write that as `pub enum Mut {} pub enum NonMut {}`, though I don't know that's better *enough* (if it's even better at all) to bother linting about. Josh: What I'd propose we do is respond and say that we feel this should be folded into the dead_code lint, i.e. with respect to public things that can never be constructed. TC: I'd want to see a more clear articulation of what "this" is and an answer, from the author, about what the motivation is. tmandry: +1. I'd want to know about how this would not lint on my example. Josh: I'll leave a reply. ### "Not linting irrefutable_let_patterns on let chains" rust#146832 **Link:** https://github.com/rust-lang/rust/pull/146832 scottmcm: Do you want to check a box here, **Tyler**? Nadri: For pattern guards, there are cases where we want to know whether it's irrefutable enough. ```rust! // I want this to be considered exhaustive match ... { Some(x) if let y = foo(x) => ... None => ..., } // so for consistency the else should be linted as unreachable if let x = 42 && let y = 0 {} else { ... } ``` TC: Agreed we should fire `dead_code` there. Nadri: OK, sounds consistent to me. tmandry: The worry I had here was about someone coming from another language (Swift) and thinking that `if let x = foo()` where `foo(): Option<T>` might mean something else. tmandry: I'll write something up and likely check a box here. ### "Add `cargo_cfg_target_family_multivalued` FCW" rust#147545 **Link:** https://github.com/rust-lang/rust/pull/147545 ### "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 ### "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