Triage meeting 2025-09-24

--- title: Triage meeting 2025-09-24 tags: ["T-lang", "triage-meeting", "minutes"] date: 2025-09-24 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-09-24/ url: https://hackmd.io/RLw05Xb8S7G8zW35cK1hVg --- # T-lang meeting agenda - Meeting date: 2025-09-24 ## Attendance - People: TC, Amanieu, RustyYato, davidtwco, dianne, Niko, Aapo Alasuutari, theemathas, Taylor Cramer, Josh, Tyler Mandry ## Meeting roles - Driver: TC - Minutes: Tomas Sedovic ## Scheduled meetings - 2025-09-24: "Design meeting: `cfg_version`" [#337](https://github.com/rust-lang/lang-team/issues/337) - 2025-10-01: "Design meeting: Wasmtime team sync" [#342](https://github.com/rust-lang/lang-team/issues/342) - 2025-10-08: "Design meeting: Review RFC 3848 (Pass pointers to `const` in assembly)" [#347](https://github.com/rust-lang/lang-team/issues/347) 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!) ### Brief update on rust-project-goals, champion program (nikomatsakis) The rust-project-goals slate is live. [Blog post going up soon.](https://github.com/rust-lang/blog.rust-lang.org/pull/1700) I am setting up the new champions process which will work like this: * During design meetings, we will review an automatically generated document that collects the updates from all tracking issues assigned a lang-team champion * I will shame you if your issue does not have updates. --nikomatsakis * We will have some discussion during planning meeting and then use that to also decide what needs follow-up. Tyler: We've only been having planning meetings every two months. Niko: I think we should shift to monthly. I plan for the meetings to have value. Spend the first 30/40 minutes diving into these issues, getting up-to-date and then the rest for scheduling. Tyler: We'd end up with one fewer slot for design meeting every few months. Niko: That's true. I'm hoping we'd be able to reduce some of the need for the design meeting. Or we could make the planning meeting being an extra meeting. TC: Note that we're going to need to allocate some design meetings to catch up on our triage queue. Niko: Let's move this to zulip and sort this out there. TC: Regarding champions, and Niko and I talked about this yesterday, I'd like to see us move toward the champion for each feature being responsible for getting the Reference PR into great shape. ### 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. davidtwco: Would like to quickly discuss *"Uplifts and extends `clippy::needless-maybe-sized` into rustc" [rust#145924](https://github.com/rust-lang/rust/pull/145924)* from the agenda, being worked on by an intern in my team and would like to move it forward. Should be a really quick one. dianne, theemathas: temporary lifetimes Aapo: Reborrow and in general Amanieu: stdarch / target features ### 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 today to review the status of RfL project goals. https://github.com/rust-lang/rfcs/pull/3614 ## Nominated RFCs, PRs, and issues ### "Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro" rust#145656 **Link:** https://github.com/rust-lang/rust/pull/145656 Amanieu: This was previously discussed previously. TC: We need a checkbox from scottmcm. Josh: We need scottmcm to check a box and then chase down the Libs people. ### "Stabilize 29 RISC-V target features (`riscv_ratified_v2`)" rust#145948 **Link:** https://github.com/rust-lang/rust/pull/145948 TC: We need Nico and scottmcm from our side. Amanieu: I guess this is mostly on me to chase down people on the Lib side. Amanieu: This doesn't include any problematic features. ### "Add the `cpuid` target feature" rust#146560 **Link:** https://github.com/rust-lang/rust/pull/146560 Josh: cpuid is the instruction for detecting processor features. But it is itself a processor feature introduced in 586. So if we were to suport 386 or 486, we'd need such a target to hasdle this. The only targets we suport is SGX. cpuid exists there but is not to be trusted and you're not supposed to use it. On that basis, I don't want to add the target feature. Amanieu: I think we should add it. We have intrinsic std arch. Currently this is an unsafe function. We want it to make it safe and add a target featuer. On our built-in targets we would only enable it. We would disable it on SGX targets and possibly 386 etc. Josh: So your rationalle is future-proofing for potential retrocomputing targets for 386/486 and cover the SGX case? Amanieu: Or any other feature we may add in the future. TC: Josh, what would you do instead for SGX. Josh: SGX has a lot of other issues. There are already safe things you can do in the standard library that SGX says you shouldn't call. CPUID would be one more such feature. TC: When you call it, you would get UB? Josh: Not UB, but it would not be trusting the data as a result if you called it. TC: That'd be kind of a weird use of `unsafe` though right? Josh: Agreed. Tyler: If you do trust the result, would that crash your program? Josh: Nothing you do by calling cpuid is going to crash your progrem. It's more: if you call cpuid, look at it and make decisions to what other features the CPU support, you may be wrong. Tyler: Where do we depend on cpuid in the standard library? Is that function unsafe because we call cpuid? Amanieu: This has nothing to do with the feature detection code. If the cpuid feature is not present, there is a code that can be detected. But we can hide that behind std::arch feature detection code. If it's there we would use it. Tyler: And that feature can essentially be enabled on most targets? Amaniep: Yes. Tyler: I'm fine with this. Josh: So am I. I'm not objecting to it, it just seems not optimal. Tyler: I checked my box. TC: I feel even if we had the target feature, it should be a safe call in SGX. Unless we're using `unsafe` everywhere else in SGX. But it's outside of SGX's security model which is a weird use of unsafe. Amanieu: cpuid returns the cpu features it supports, but it's outside of SGX's safety area so it won't return trusted data. It's essentially as if it returned random data. Tyler: It's not intrinsically unsafe, but it's once-removed. TC: It would be interesting to have a list of everything else that differs like that on SGX. ### "Decide about future of `rustc_legacy_const_generics`" rust#146613 **Link:** https://github.com/rust-lang/rust/issues/146613 TC: In 2021 we converted standard const generics, we left the question of how strongly we want to deprecate it. Our intrinsic documentation still points people to the legacy syntax. But recently we made the legacy syntax less functional. Based on the minutes, we were trying to deprecate it. But looking back at the original discussion it's unclear for me what the plan was. TC: What *is* our plan for legacy const generics? The compiler people want to get rid of it. Should we be lang FCPing these stabilizations? Should rustdoc be suggesting legacy syntax? Amanieu: rustdoc was changed to show the ??. TC: That was a change you told people to make. The motivation was MSRV; the intrinsics are supported further back than the const generic syntax. Tyler: Rust for Linux folks really want this. They hate the turbofish wrapping const, it's not a nice syntax. Whether we can support it I can't speak to. Personally I'm open to this direction from Lang perspective. It'd be nice to have a nicer syntax than the one we have in stable right now. Josh: Last time we discussed this, the general feeling was we appreciate the feeling from compiler that it sucks to support this. At the same time, Ralf's comment here in this issue, "fwiw I agree that ergonomically speaking the legacy syntax is nicer". And that if we can make this less awful in compiler, it would be really nice for other uses. We never followed-up on that. But there was a feeling that we could pursue this further and make it more widely available. TC: There's a separable question to whether we think this would be a language feature with better design. But what do we want to do about it as it stands? Right now, what we have is not that. We made a decision in October 2024 where it now doesn't support most things that are supported in `const` context. There's now this crippled const context that's suppported in legacy_costn_generics. Someone now supports expanding this feature for consistency. Is that a consistency we want? Or are we going in an opposite direction? Do we want to add this to new APIs we stabilize? Josh: This is something that people would be disapponited if they tried to use it this way. You can't use it to get arbitrary const expression and expecti t o work. But these intrinsics were originally desigend for C/C++ and the only thing you could pass to it is a literal or a preprocessor expression that turns into a literal. To that extent, these still work fine the same way in Rust. You can pass the literal constant you're trying to use. But you can't use this to have this be computed or processed. This is awkward to const generics, but its what peple used to this system would expect. TC: To that exact thing, is this a feature we're committed to? If we are, we should take off the legacy label, not deprecate it, and document in the Reference that we have two separate kinds of const contexts. Josh: Agreed we need to pick a path here. As an alternative to what we're doing, it's worth asking whether it would make sense to potentially introduce macros instead. To a first approximation this is almost as if you're calling a macro that repositions this to be a const generic. The macro would conver this and rewrite it in the turbofish syntax. Tyler: I feel we're not going to resolve it in this meeting. TC: Agreed. Should be lang-FCPing these intrinsic stabilizations? Like AVX512 not crossing our desks? Josh: I believe we did delegate that. Tyler: We FPCd the target features and not the intrinsics. Josh: The reason we're kept in the loop for target features is they may have lang semantics or ABI impacts. The intrinsics we've not tried to be kept in the loop for, we've handed those to stdarch. I think that if we really want to deprecate this, we should say "don't use this in anything new". But so far we haven't said that and I don't thing anything wrong was done by shipping the intrinsic. TC: The fact we didn't notice this is the issue. This was an example where it had this thing on that nobody noticed it. That's why we FCP intrinsic language stabilizsation. Josh: If we want to deprecate it, we should make a decision to deprecate it; we shouldn't handwring about its use in new intrinsics. But I'd agree with the point of us settling this in the meeting. Tyler: +1 to what Josh said. Libs-API is capable of catching it once we make it clear that's what we want. TC: When I talk about FCPing intrinsics, I'm talking about not just this. There's a lot of other things the intrinsics can do. Josh: For the most part I don't thin we have the expertise of doing point by point reviews of target-specific intrinsics. But we should lay down the broad parameters and have them talk to us if something goes beyond those. TC: I'd like to find what the bounds are for delegation. Josh: And if we haven't formalized it we should do that. But we should try to formalize them and then delegate it rather than inserting ourselves into the review process. Tyler: +1. ### "Uplifts and extends `clippy::needless-maybe-sized` into rustc" rust#145924 **Link:** https://github.com/rust-lang/rust/pull/145924 David: We discovered this during the redundant_sizedness_bound work. The `?Sized` is redundant, we'd like to move it tu rustc. Tyler: Sounds good to me. I filed FCP. TC: Is this going to be a problem for macros anywhere? Tyler: I think the general approach for macros is you use them with a healthy dose of allows. David: If the macros are a problem, we can always disable the lint from the macros. Niko: In what way is this blocking anything? David: It's nice to have. Josh: It's helpful for ABI reasons. For built-in things like Clone, those aren't going to change. But if you're writing your own traits and building somethnig on top of traits, this could identify cases where your traid failed to be `?Sized`. If you see this on your own trait, you might see this and realise you may need to fix it to not need `?Sized` Tyler: The meaning of `<T: Clone + ?Sized>` will likely change over an edition. When we do an edition migration, we'll likely change how some bounds are written. David: We'll do the corect thing for the hierarchy of traits not just `?Sized`. TC: I'm leaving a comment about the wording: https://github.com/rust-lang/rust/pull/145924#discussion_r2376252969 ### "Document MaybeUninit bit validity" rust#140463 **Link:** https://github.com/rust-lang/rust/pull/140463 TC: This asks us to make or confirm language guarantees: > 1. `MaybeUninit<T>` has no validity requirements –- any sequence of bytes of the appropriate length, initialized or uninitialized, are a valid representation. > 2. Moving or copying a value of type `MaybeUninit<T>` (i.e., performing a "typed copy") will exactly preserve the contents, including the provenance, of all non-padding bytes of type T in the value's representation. Josh: We make the same guarantees for unions as well, right? Tyler: It is a union internally. It would be good to check if that's just the same as unions and reference that section. Still good to have the documentation directly there though. Tyler: I don't see anything about this in the reference. TC: There's a section about reading and writing union fields that says something maybe like this but not quite. Josh: I remember we had a long discussion about the two potential representations of unions. Whether to allow unions any possible bit pattern or only a possible bit pattern for one of those fields. We've decided on the former. I believe that went to somewhere in the unsafe code guidelines. TC: If you can find that FCP, that would be great. The unsafe code guidelines are not normative. Josh: I believe the decision ended up extensive discussed at the last Mozilla-run Rust All Hands. And it was continued in whatever the unsafe code guidelines were. I believe there was an FCP but I've no idea where it is. Josh: Some discussion of this happened in: https://github.com/rust-lang/unsafe-code-guidelines/issues/73 TC: Do we like these two guarantees? Niko: I think they seem good. I do recall the conversation Josh is mentioning it. A big part of the discussion was about the first guarantee and the idea that if you had a single-field union with a box you couldn't do anything with the niche. I believe Ralf strongly said we shouldn't touch the union bit patterns. Niko: Unsafe sort of inverts the usual tradeoffs. With safe code you want to be optimized smartly but with unsafe you want the safe thing and only optimize things carefully. The compiler should be as unclever as it can to avoid surprising people. Josh: Agreed. Tyler: It's a useful principle. ### "Temporary lifetime extension for blocks" rust#146098 **Link:** https://github.com/rust-lang/rust/pull/146098 TC: In Rust 2024 we made a change so that the tail expression of a block is now a temporary scope. Temporary scope is the smallest scope where temporaries are dropped. Unless the block is in an extending context -- you've got let and as you walk down the expressions in the initializer and if everything is an extending expression, then a block is an extending expression and then the tail expression becomens extending and the temporaries get extended. This creates some unexpected behavior. TC: What dianne proposes is a clever solution: what if we walked back our change in 2024 just a bit. And say "an extending expression in the tail expression of a block is alwasy extending". That means you'd be extending the tail temporaries to the nearest extending temporary scope. It would not extend beyond the block, just the nearest extending temporary scope. Josh: This has the virtue that a number of good language changes has: my immediate reaction was "I thought this how it already worked". Niko: I disagree. This violates the expectation of "I put this in a block, it should be released in the block" TC: I've been struggling ot think of cases weher tihs would be a problem. Niko: just like we say in the let statement that we say "if it's syntactically evident that this would result in referencing a dropped value, we extend the lifetime" (e.g., `let x = &vec![]`) -- we are applying that same principle to the tail expression of a block: ```rust // This `temp()` is now extended past the block tail in all contexts. { &temp() } ``` dianne: So this is exactly as the let statement, it only applies to borrow expressions in the block conetxt where you'd end up with a borrow-check error. The idea is to make it consistent with the let statement. Currently, those have different semantics because they have different drop orders. TC: There are a number of virtues. If you sit down and you try and think about the drop order. You can, but it's really surprising in some cases. This makes a lot of those cases more the same. So it makes our drop order more predictable. And mostly it's making code that would otherwise fail borrowchecker work. dianne: The other thing I'd like ta add is that asidefrom fixing drop order inconsistencies, this lets you look at an an expression and you can tell just from looking which temporary are in it. Which has impact on macros where we saw e.g. recently some bugs in the implementation of super let in the `pin` and `format_args` macros. TC: This change undoes the breaking chaneg we're making in 1.91. Our breaking change is correct without this. But this then makes it uncecessary. Niko: I'm in favor of it. I'm curious what themaathas said: > Exception to "borrowcheck error is obvious": a cast from reference to pointer. But the new extension rules would make a dangling pointer become valid. TC: The one question where this wouldn't work is if you took a raw borrow. Niko: I see, that makes sense. TC: I meant to crater run this. dianne are you ready to for me to run the bors try and run the crater run? dianne: I'd like to optimize the implementation before merging, was waiting for a vibe check. But I think it's ready for crater run. ### "the `#[track_caller]` shim should not inherit `#[no_mangle]`" rust#145724 **Link:** https://github.com/rust-lang/rust/pull/145724 ### "Allow specifying multiple bounds for same associated item, except in trait objects" rust#146593 **Link:** https://github.com/rust-lang/rust/pull/146593 ### "Allow passing `expr` metavariable to `cfg`" rust#146961 **Link:** https://github.com/rust-lang/rust/pull/146961 ### "`dangerous_implicit_autorefs` suggestion is wrong" rust#140721 **Link:** https://github.com/rust-lang/rust/issues/140721 ### "`rustc_const_eval`: respect `target.min_global_align`" rust#142198 **Link:** https://github.com/rust-lang/rust/pull/142198 ### "error out when `repr(align)` exceeds COFF limit" rust#142638 **Link:** https://github.com/rust-lang/rust/pull/142638 ### "Tracking Issue for `darwin_objc`" rust#145496 **Link:** https://github.com/rust-lang/rust/issues/145496 ### "Tracking Issue for Reborrow trait lang experiment" rust#145612 **Link:** https://github.com/rust-lang/rust/issues/145612 ### "compiler and language documentation disagree on lifetime extension for array expressions" rust#146092 **Link:** https://github.com/rust-lang/rust/issues/146092 ### "Add a new lint `UNCONSTRUCTABLE_PUB_STRUCT` to detect unconstructable public structs" rust#146440 **Link:** https://github.com/rust-lang/rust/pull/146440 ### "Add lint about redefining runtime symbols" rust#146505 **Link:** https://github.com/rust-lang/rust/pull/146505 ### "Extend format_args implicit arguments to allow field access" rfcs#3626 **Link:** https://github.com/rust-lang/rfcs/pull/3626 ### "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 ### "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