Triage meeting 2025-10-01

--- title: Triage meeting 2025-10-01 tags: ["T-lang", "triage-meeting", "minutes"] date: 2025-10-01 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-10-01/ url: https://hackmd.io/f_pVDH91Q4OkUd6fxDpjnQ --- # T-lang meeting agenda - Meeting date: 2025-10-01 ## Attendance - People: Eugene, dianne, Amanieu, Niko, TC, Taylor Cramer, Tomas Sedovic, Urgau, Tyler Mandry, Yosh, Josh, Mark, scottmcm ## Meeting roles - Driver: TC - Minutes: Tomas Sedovic ## Scheduled meetings - 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!) ### 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-10-08 to review the status of RfL project goals. https://github.com/rust-lang/rfcs/pull/3614 ## Nominated RFCs, PRs, and issues ### "Lint regression: `dead_code` ignores `#[allow(dead_code)]` on traits" rust#144060 **Link:** https://github.com/rust-lang/rust/issues/144060 TC: Would we expect dead_code to suppress the list in this example? Niko: I don't know where we have the behavior of our allow system and dead_code documented. But I think it's useful that when a trait is live, its impls are also live, at least those in the current crate. TC: We have other rules where where applying something to the trait doesn't affect the impl items. Things like inline. You apply them to the impl items and applying them on the trait doesn't do anything. We should write down our rules on how these things work on traits. Niko: This is about: when you allow dead_code, are you saying treat this item as is if it were used? Or "don't give me warnings in this lexical scope". And I think the first one is more useful. Josh: This is a useful distinction. But I also love that Rust shows you all the dead code warnings at once. So it's not a situation where you fix the only reported one and then another ten show up. For example, you don't get a warning that `Foo` is never used. But I'd find it surprising that allowing dead_code on `Foo`, ... This example shows trait Foo and impl Foo right next to each other. But there's a risk of spooky action at a distance when Niko: I think the issue needs to be more clarified. But the proposal sounds that allowing dead_code on a trait allows it on the impls of the trait. When is an trait impl declared dead? It might be if the trait is private we have to see it get used for example. Josh: And if the trait is public, every public impl must be used. Niko: Then there's the question of: "when I put `allow(dead_code)` on a function that's impl" ?? TC: Running these examples, I really don't think it should suppress the lint. I think allowing dead_code on a function that calls another function, it should .. I think this is a bug. Niko: I don't like that we have all the warnings about dead_code. It's hard for me to get it to go away. It's also really hard for me to figure out why something is dead. I see a dead code on a function and there's a caller to it. And then I have to go all the way up the call chain. It would be nice if tere was a way to address those usabliity issues. Taylor: Niko, do you think it makes sense that the behavior here should match the behavior of the functions. And revisit the behavior of dead code later? There are other things about the dead_code passes e.g. the behavior of `pub` items in a binary that we might like to revisit. But for now, it makes sense to match the behavior here. Tyler: I thought allowing on a function did suppress lints on a callee. Niko: It does: Niko: I'm confused: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=6b76a8f2585d60c88593356b3c77a261 ```rust // #[allow(dead_code)] fn foo() { bar(); } fn bar() { } fn main() { } ``` gives two warnings. But put `allow(dead_code)` and you get none. TC: Interesting. I was testing something different. Tyler: I think it's useful in the case where you want to remove all the instances of unused. But not in other instances. Josh: In terms of the value of the unused_code lint, what I find often is it let me in the habit of adding my API first so I start getting dead_code warnings. Then call the APIs and that is a signal my code is close to ready. Similarly to how I add the a new item in an enum first. As long as I still have those warnings, I'm not ready to push yet. Josh: That said, for consistency I checked if you drop the `allow(dead_code)` on this and add a `pub` to `trait Foo` the warnings goes away. I think that's the correct behavior modulo the previously mentioned suggestion of not showing dead code on all pub items. If we do want to still lint in this proposed case, we should start linting for `pub` in this case. TC: What about: ```rust! #[allow(dead_code)] trait Foo { fn f(); } impl Foo for u32 { fn f() { g(); } } fn g() {} //[1.89]~ WARN fn main() {} ``` TC: This warns in 1.89 but not 1.88. nikomatsakis: nit to what josh said, I would like a warning for `impl PublicTrait for PrivateType`, I'm not sure whether I think that `#[allow(dead_code)]` should change that. scottmcm: Time check. This seems like we need someone to come up with a proposal. The discussion is good but too long for triage. TC: --- notes from chat josh: +1, would be awesome to have things like "is this unused, counting my testsuite" or "is this unused, counting the users in my workspace". scottmcm: TBH I often use `#![cfg_attr(test, allow(dead_code))]` or similar to make it shut up until I `c r` and not just `c t`. No strong opinions without needing a bunch more thought about exactly what rule I'd want. ### "[beta-1.91] Warn on future errors from temporary lifetimes shortening in Rust 1.92" rust#147056 **Link:** https://github.com/rust-lang/rust/pull/147056 TC: We have a breaking change regarding to super let. We've realized that what we did does not align to the behavior in super let. We're going to have a fix in 1.92. We originally hoped to ship this for 1.90 beta. There is a kind of thing we know people are falling into. It was raised in the compiler thread: maybe we want the FCW backported to 1.91. Dianne wrote up such a compatibility warning -- it's not clear the compiler will accept it. TC: Do we want this future compatibility warning if Compiler wants it? scottmcm: It's a big change but it's trying to be a lint-style change that doesn't affect the guts? TC: Correct scottmcm: But it does make changes to the AST. Josh: Is this straightforward change that we can backport or is it different from what's not on top of tree? Tyler: Is this fixing the bug for super let that we released in the 2024 edition, right? We found 5 crates breaking. TC: We released the bug in 1.88 and 1.89 for Pin and format_args respectively. We're not seeing Pin breakage, but the 1.89 is a tempting thing for people to do. Tyler: So the question is: do we want this lint to exist? TC: Yes, we still have to approve it and see if Compiler wants a backport. Tyler: I'm fine with linting on future breakage. scottmcm: I might want to run it by Types or someone to double check. But also it's a lint. Lints are one-way doors. If the compiler says this is reasonable and we expect it to help, let's do it. dianne: Jack Huey is assigned and in the backport thread lcnr is looking. They're from Types. TC: I'm going to fire an FCP merge on it. scottmcm: Glad to hear people have looked at it. ### "Document MaybeUninit bit validity" rust#140463 **Link:** https://github.com/rust-lang/rust/pull/140463 TC: Scott you're the only one who's missing a checkbox. ### "Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro" rust#145656 **Link:** https://github.com/rust-lang/rust/pull/145656 TC: Scott, these are dual FCPs we have to pick up almost all the checkboxes. ### "the `#[track_caller]` shim should not inherit `#[no_mangle]`" rust#145724 **Link:** https://github.com/rust-lang/rust/pull/145724 TC: Scott and Josh, we're picking up your checkboxes. It's better to have more than three. We talked about this. ### "Stabilize 29 RISC-V target features (`riscv_ratified_v2`)" rust#145948 **Link:** https://github.com/rust-lang/rust/pull/145948 TC: Once again, we're picking up checkboxes. Scott, we need your checkbox. ### "arbitrary_self_types: Split the Autoderef chain" rust#146095 **Link:** https://github.com/rust-lang/rust/pull/146095 TC: This is a vibe check -- we're not making a binding decision. This is about separating the `Receiver` trait target's associated type from `Deref` trait's target associated type. This allows us to stabilize arbitrary self types without needing to rely on trait hierarchy. We want to merge it so Ding can proceed with experimentation. TC: I think it's reasonable to experiemnt with this. Tyler and I talked about it. We need to do a deep analysis to see if this is okay. I want to see the experimentation to figure out whether it is okay. I want to support Ding to experiment with this on Nightly. Tyler: I'm not opposed to lang experimentation here. The only reservation is that there might be other ways to move forward towards stabilizing arbitrarry self types. And it's hard to see how we implement both this and another path at the same time. The other thing is: in terms of the vibe check, I'm kind of leaning negatively on this. I think it's weird to allow a single type to implement `Deref` and `Receiver` with different target types. People brought up usecases where that's useful but I'm not convinced we can't support those another way. That's not a reason we can't experiment with this. TC: Some of the things Tyler's concerned about is: other features like reborrowing, projections and other stuff along that path. And ther's a worry whether doing this would make things more difficult. And the usecase for breaking this apart for programmerjake where he's using it in his programmer implementation. But then Tyler is saying we can just do a projection feature and sort this. Niko: Who's the champion for this? TC: This is before we figured it out, but I was working closely with Adrien and Ding. Niko: From a tactical point of view to what Tyler said to me. But I'm open to experimentation. I'd leave this to the champion. And I'd love to see the examples. TC: Ding has a document on zulip. Josh: Vibe check on doing an experiment: awesome, ship it. Thhis is what I'd want to learn from the experiment: what precisely are we losing from having two separate traits and separate associated types. What might be surprising behavior from this model if you had the same underlying associated type and the same chain. Also, what goes horribly pear-shaped if you implement the same type for Receiver and Deref and have different Target types, and if we need to check for and flag that somehow. Tyler: This is strictly more expressive in allowing divergence. There's nothing you can express in the curent moddel you can't express here. If you have one type that implemenths both traits with the different targets. TC: If it's without objection, I'll put on my champion hat and make the judgement call here that the way to get the evidence is to let Ding run with it, try to answer all these questions, write good documents and have a design meeting. ### "Temporary lifetime extension for blocks" rust#146098 **Link:** https://github.com/rust-lang/rust/pull/146098 TC: We talked about this last week, gave positive vibe. We kicked off the crater run. dianne: I haven't looked at the run yet. The only thing I've seen so far that hasn't been spurious is an unrelated-looking diagnostics ICE that regressed from an out of memory. I don't know whether that's related or exposed some problem with the diagnostics so I think that's probably spurious but I need to check. TC: The one that jumped out to me was the W lambda. I'll be interested in your analysis. ### "Add the `cpuid` target feature" rust#146560 **Link:** https://github.com/rust-lang/rust/pull/146560 TC: We have checkboxes, missing Josh, Scott and myself. TC: We were a little bit unsure whether this actually needed a target feature or not. Everything from 586 and later is always safe to call cpuid. And SGX has this interesting nuance where you can call cpuid but you can't run that safely from the sgx safe box. Tyler: I think the issue for SGX was you can call cpuid but it returns an untrustworthy result. If you rely on the result and then execude an instructruttion, you get. Josh: It's safe from the undefined behavior perspective to call. It won't crash. But it's not safe in terms of checking the results. The results can be garbage. scottmcm: I feel strongly that "this might give you garbage" is not sufficient reason to declare something unsafe. Tyler: The target feature is the way we make certin CPU intrinsics available on some targets and not others. And it is a valid way of expressing that especially for older CPUs (none of which are supported by the Rust compiler today). If there's another mechanism that works for this, then we can just not make it not callable in SGX. TC: I think it would be callable in SGX, they just want to make it unsafe to call on platforms without the feature (including SGX) and it would be safe otherwise. Josh: That highlights that using target feature is not the right way to handle this. All the x86 CPUs we support do support this. SGX also supports this but you have to be careful with what you want to do with it. In this case, we sholud not make everyone deal with quirks with SGX's cpuid just because SGX does. You should either say you don't have it or if you do have it, your constraints shouldn't affect other platforms. TC: I'm not certain enough about this to check the box. Josh doesn't want to check a box. Tyler: Reading through this discussion I'm becoming more convinced that this doesn't seem like the right mechanism. We can just make the intrinsic unavailable for the really old targets. And for SGX probably just document it. It's always going to be platform-specific code that's taking the result of the cpuid. Josh: There's another process item I want to raise: if SGX was still a concern on an ongoing basis, I'd be open to the discussion. But at this point, SGX has been deprecated for several years. SGX is now essentially a retrocomputing technology and we shouldn't be ?? Mark: I'm confused by the references to SGX. The way I'm reading the RFC is making cpuid available on all of x86. Josh: Broadly speaking, the existence of target feature implies the existence of targets that don't have that target feature. Assuming we don't have any plans of shipping 386 or 486 in Rust (which I don't think we should), cpuid is the standard way. I'm saying it should just be safe, not using target feature. But if people want to use target feature for this, I'm not going to block it. I just don't think it's the right mechanism. Niko: I don't really have a strong opinion. But what's missing a bit is: what is the counter proposal? Can we put that on there? Josh: The counter proposal would be to transition this to being (universally) safe. TC: Josh, you want to write this counter proposal on the issue? Josh: I can write that up but I'd appreciate not being the only person holding up that. TC: I'll see the notification and +1 it. ### "Allow specifying multiple bounds for same associated item, except in trait objects" rust#146593 **Link:** https://github.com/rust-lang/rust/pull/146593 TC: It finished FCP but want to be sure Niko saw it. And maybe pick up the other checkboxes. Niko: reviewed ### "RFC: `#[export_visibility = ...]` attribute" rfcs#3834 **Link:** https://github.com/rust-lang/rfcs/pull/3834 Tyler: You can put the attribute on a function/static. It controls whether we export that symbol as public, overridable, private, hidden. There's a couple of approaches we can take here, each with differnt tradeoffs. The one here roughly corresponds to symbol visibility in ELF and other formats. The other is to do in the compiler today: there's Rust visibility and C visibility and that an `extern(C)` function should be what the Rust visibility is. Josh: With experience of linker ELF stuff. Big fan of separating no_mangle and exporting symbols. There are good reasons for exporting a symbol without no_mangle etc. Tyler: +1. TC: Tyler, is it plausible for this knob to become a part of `no_mangle`? Is it tied enough to `no_mangle` to do that or does it have to be a completely separate axis? Tyler: I can't think of a good reason you'd want one of the other. Josh: There's no reason you can't combine them. But it's confusing from the user concept that the way to control visibility is via passing an argument to no_mangle. scottmcm: If it's visible and we make it visible to the linker, that could still be potentially fine, right? Tyler: Yeah, technically that's something you may want to express but I'm not sure why you would. Josh: With a large amount of care it's possible to use Rust shared libraries that use Rust APIs. (The meeting ended here.) --- ### "Decide about future of `rustc_legacy_const_generics`" rust#146613 **Link:** https://github.com/rust-lang/rust/issues/146613 ### "Allow passing `expr` metavariable to `cfg`" rust#146961 **Link:** https://github.com/rust-lang/rust/pull/146961 ### "FCW for repr(C) enums whose discriminant values do not fit into a c_int" rust#147017 **Link:** https://github.com/rust-lang/rust/pull/147017 ### "-Zfused-futures" rust#147129 **Link:** https://github.com/rust-lang/rust/pull/147129 ### "Add warn-by-default lint for visibility on `const _` declarations" rust#147136 **Link:** https://github.com/rust-lang/rust/pull/147136 ### "`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 ### "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 ### "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 ### "Not linting irrefutable_let_patterns on let chains" rust#146832 **Link:** https://github.com/rust-lang/rust/pull/146832 ### "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