Triage meeting 2025-09-10

--- title: Triage meeting 2025-09-10 tags: ["T-lang", "triage-meeting", "minutes"] date: 2025-09-10 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-09-10/ url: https://hackmd.io/WXCjQqzqSYKqTzLKYmIhyg --- # T-lang meeting agenda - Meeting date: 2025-09-10 ## Attendance - People: TC, Tyler Mandry, Santiago, Taylor (cramertj), Tomas Sedovic, Yosh, Amanieu, RustyYato, Josh ## Meeting roles - Driver: TC - Minutes: Tomas Sedovic ## Scheduled meetings - 2025-09-10: "Design meeting: Extending const generics -- temperature check" [#341](https://github.com/rust-lang/lang-team/issues/341) - 2025-09-17: "Design meeting: Unsafe fields RFC review" [#344](https://github.com/rust-lang/lang-team/issues/344) - 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!) ### Appointments for Project Directors TC: I'm planning to stand for that. Want to run it by the meeting. We're missing most of Lang though. ### 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-09-10 (today). https://github.com/rust-lang/rfcs/pull/3614 ## Nominated RFCs, PRs, and issues ### "Document MaybeUninit bit validity" rust#140463 **Link:** https://github.com/rust-lang/rust/pull/140463 TC: Ralf nominated it for us. TC: I think I may need to read this when not in the meeting. Tyler? Tyler: I'm about halfway through. So far what I've seen is unsurprising to me but I haven't read through everything. TC: We'll look at this async. ### "Allow `&raw [mut | const]` for union field in safe code" rust#141469 **Link:** https://github.com/rust-lang/rust/pull/141469 TC: It has a proposed FCP. It will go into FCP with your checkbox, Tyler. Tyler: Why not, I guess. TC: This is one of those changes that makes the Reference more correct, because it says we already do this. (Tyler and Josh checked the box.) Tyler: Interested in compiler-errors's UB comment: https://github.com/rust-lang/rust/pull/141469#pullrequestreview-3171710534 Tyler: I see, that's just a bug. TC: Yes, just a bug. ### "Allow specifying multiple bounds for same associated item (remove E0719)" rust#143146 **Link:** https://github.com/rust-lang/rust/pull/143146 TC: I proposed an FCP on this and filed a concern pending the answer to lcnr's question. Josh: Makes sense. So instead of writing this with a plus you can write multiple bounds of the same thing which I can see uses for. The test seems pretty self-explanatory. Josh: I've checked my box on that. Tyler: I'm supporting this overall. I agree with lcnr's idea. We can do that later. TC: lcnr is referring specifically to the use in dyn. Tyler: I'm referring to the second lcnr's comment. TC: Right. In Jules's comment, the part he was quoting was referring to the dyn iterator and all the code examples referred to the dyn iterator too. Tyler: I don't really see how it's specific to dyn. TC: If it is, it would be because of its existential nature. It may matter differently if it's unsatisfiable. Tyler: Interesting point. I'd think of it as: this is a function that can't exist and you can't call it. TC: I'm expecting either Jules is going to come back with a great answer to the question, or he'll hold off on that part of the PR, I'll resolve the concern, and we'll go to FCP. Tyler: Which part of this PR is actually separable? What can be changed about it exactly? TC: The second part, the part lcnr commented on. TC: There's the first part where you have `T: Iterator<Item = u32, Item = u64>` that it means `T: Iterator<Item = u32> + Iterator<Item = u64>`. (https://github.com/rust-lang/rust/pull/143146#issuecomment-3274421752) Tyler: You're saying that's separate from the dyn part? TC: Yes, as lcnr said, we're already allowing that. Allowing it under a different syntax doesn't raise any problems. Josh: Right now you can't declare a dyn bound on something that has two completely different traits. In this particular case I'm wondering what would happen if you declare that an item has a trait bound for a trait and then a trait bound for a different trait that's not a marker train? TC: That's related to lcnr's question. Josh: That's what I'm asking. I saw the question about two different concrete types. I'm asking what would happen if we had two separate trait bounds. Tyler: We don't support ATB on dyn. TC: Right. It goes back to that existential specialness. TC: We'll see what Jules says. ### "Allow borrowing array elements from packed structs with ABI align <= packed align" rust#145419 **Link:** https://github.com/rust-lang/rust/pull/145419 TC: I proposed FCP three weeks ago. Scott and I checked a box, Scott filed a concern asking for the exact rules list. The PR was updated with that 2 weeks ago. There's a [reference PR](https://github.com/rust-lang/reference/pull/1984). Josh: I've just checked my box. Tyler: This looks good to me. Is there any possibility of relying on non-public properties of a type? Let's say you embed a struct in your type and that type happens to have a certain alignment but it's not a local type and that definition changes to have a higher alignment and that can cause a semver hazard. I'll post a comment on the PR. Tyler: I'll leave that as a comment. TC: I'll have a second look too as part of reviewing the Reference PR. ### "Opportunistically split `!=` to successfully parse never type" rust#145536 **Link:** https://github.com/rust-lang/rust/pull/145536 TC: There are some interesting comments to read here, including the one from Eric Huss. He opened a Reference issue (https://github.com/rust-lang/reference/issues/1983). As [petrochenkov said](https://github.com/rust-lang/rust/pull/145536#issuecomment-3271973950), we don't want to be whitespace-sensitive in general, so all these tokens should be treated separately, and when we don't that's a bug. That's the general idea of what fmease is trying to achieve here. Josh: That seems like a good-enough reason by itsefl. We use the same logic when we use the left shit and right shift byte operators. This avoids the issue C++ has where you'd have to add extra whitespace so the lexer doesn't misinterpret templating code with bitshift operations. So this seems sensible. TC: There's an FCP proposal at the bottom. Josh: Checked the box. Tyler: How can I be confident we won't regret this in the future? TC: We do this everywhere else. The design concept of the language is that we're not whitespace sensitive. Each of these tokens are processed separately -- conceptually -- unless we have a specific rule which we don't have here. Josh: Petrochenkov pointed out that we should always lex them as independent tokens, but what currently happens is we parse a binary operator and there's logic handling the binary operator, and if the next token is a left-shift operator and we expect a less-than, we eat the first character as a less-than and let the next token be a less-than. That's a hack and it'd be improved if we stopped having two-character operators and only had single character operators in the parser. But this is what we already do for other two-character operators where each character is a valid token. Josh: At least in theory, this should be transparent to macros. Tyler: Alright, good enough for me. Josh: The usual caveat: if we make something parse that didn't parse before, then a multi-arm macro can tell whether it parsed as an expr or a tt, but other than that I don't expect this to be detectable. ### "Prevent downstream `impl DerefMut for Pin<LocalType>`" rust#145608 **Link:** https://github.com/rust-lang/rust/pull/145608 TC: Alice Ryhl came up with a clever solution to a soundness problem. I proposed a dual FCP for Lang and Libs API, cc Types. Tyler: This prevents you from writing a DerefMut of Pin of a LocalType. All we're FCP-ing is a breaking change that no one should write this impl anyway. TC: Yes. And fortunately we got back a clean crater run too. Josh: Checked my box. Niko: I think this makes sense. Trying to put my finger on what exactly it's doing. I can see how it works. I'ts obviously really hacky. Something's bugging me about it, not in a way that would prevent us going forward but something's missing. Tyler: Seems like this isn't the fundamental abstraction we want here. Niko: I'm writing a comment. Tyler: I just posted a comment and checked my box. ### "Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro" rust#145656 **Link:** https://github.com/rust-lang/rust/pull/145656 TC: Another dual lang/libs FCP. Niko and Josh checked a box. Amanieu: The main issue is the vector issue which has the impact on the ABI but I can't remember what the actual impact is. Josh: Is it the usual issue that vector support affects how you pass and return values (specifically, whether you use the vector registers)? Amanieu: It's like SSE where 128-bit vertors are passed in ?? if you have the feature enableeed and are passed in memory if you don't have the feature enabled. Amanieu: Vector is blocked in other things, notably the scalable vector types. I think we blocked the fnd for float and double float features. Tyler: You said we didn't stabilize those? Amanieu: No. Amanieu: This one only affect `extern "C"`. For `extern "Rust"` we only pass these via memory. Josh: Shouldn't be doing better tahn that for efficiency? Amanieu: Only if this is enabled as a base feature in the target spec. Josh: Sure. Amanieu: I don't know if we do that for x86. I know it's specified but I don't know if we do it yet. Tyler: You were saying we blocked the RISC-V float extension because of the impact on the ABI. This sounds analogous to me. Seems here may be spooky interactions here. Like we had with some of the x86 extensions. I want to make sure we're not getting ourselves to another mess here. Amanieu: The mess is not something we can fix. It's the C ABI that is broken -- it depends on target features. Tyler: We've never actually stabilized "is feature detected" macro inside `core::arch`. Amanieu: The feature detection was always in std. Tyler: The stabilization PR says feature detection is in `core::arch`. Amanieu: That's a typo, it should be in `std::arch`. Tyler: I'm going to check my box and bring up my concern about the ABI. ### "Deny-by-default never type lints" rust#146167 **Link:** https://github.com/rust-lang/rust/pull/146167 TC: I've proposed FCP. We have a plan, created before Rust 2024, on how we're going to stabilize the never type (https://github.com/rust-lang/rust/pull/146167#issuecomment-3275551187). We changed the fallback to `!` in 2024. To do that we created some lints. They went out in Rust 1.80. This PR would land in Rust 1.92, 12 releases later. It will be three releases since we bumped them to report in deps. That seems like enough to me, even given the crater results here. Tyler: I see 474 regressed crates but only one root crate? TC: These are the crates that need to actualy change. Niko: Are you saying the 474 are the ones that need to change? TC: That's right. Or they're abandoned crates that will never change. They've already been ignoring the warnings for 10 releases. TC: When we bump something to deny-by-default, because of the way cap-lints works, we don't break someones's build in their dependencies. So there's nothing further down the chain. So the only thing we're going to have in this crater run is root results. Niko: If you had two crates, where one is a dependency on the other. And they both fail. I think crater might assume that the downstream crate si failying because the upstream crate is failing. When I click on regressed dependencies I see one thing. But when I click on root results it shows a lot of crates. Niko: I think the ones falling into unsafe are very defensible. The other ones less so. I don't see anything major in this. Do we display if these are the most recent crates? TC: That'd be nice if crater did track that. Niko: There's a fair number in wasmer. Tyler: Is this warn-in-deps? TC: Yeah, we bumped it. Niko: I'm good with it. Tyler: We're already doing the new fallback behavior in Rust 2024 so this is just to fulsh out the old behavior in the older editions. To me it's unclear when we should do the breaking change. TC: A part of making us ready to do that is bumping this up. Niko: Anyone building these crates as the leaf crates will start getting deny-by-default but anyone using these crates will not be affected yet. They'll see the warnings but they won't be denied. TC: That's right. (The meeting ended here.) --- ### "the `#[track_caller]` shim should not inherit `#[no_mangle]`" rust#145724 **Link:** https://github.com/rust-lang/rust/pull/145724 ### "Stabilize 28 RISC-V target features (`riscv_ratified_v2`)" rust#145948 **Link:** https://github.com/rust-lang/rust/pull/145948 ### "`dangerous_implicit_autorefs` suggestion is wrong" rust#140721 **Link:** https://github.com/rust-lang/rust/issues/140721 ### "error out when `repr(align)` exceeds COFF limit" rust#142638 **Link:** https://github.com/rust-lang/rust/pull/142638 ### "Tracking Issue for Reborrow trait lang experiment" rust#145612 **Link:** https://github.com/rust-lang/rust/issues/145612 ### "initial implementation of the darwin_objc unstable feature" rust#145660 **Link:** https://github.com/rust-lang/rust/pull/145660 ### "Uplifts and extends `clippy::needless-maybe-sized` into rustc" rust#145924 **Link:** https://github.com/rust-lang/rust/pull/145924 ### "compiler and language documentation disagree on lifetime extension for array expressions" rust#146092 **Link:** https://github.com/rust-lang/rust/issues/146092 ### "Extend format_args implicit arguments to allow field access" rfcs#3626 **Link:** https://github.com/rust-lang/rfcs/pull/3626 ### "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