---
title: Triage meeting 2025-10-29
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2025-10-29
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-10-29/
url: https://hackmd.io/Oo0T829rSfeGYTdZixvI_Q
---

# T-lang meeting agenda

- Meeting date: 2025-10-29

## Attendance

- People: TC, Tyler, Eric, Tomas, Niko, Jack, Josh, Scott, Amanieu

## Meeting roles

- Driver: TC
- Minutes: Tomas

## Scheduled meetings

- 2025-10-29: Extended triage

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-11-05 to review the status of RfL project goals.

https://github.com/rust-lang/rfcs/pull/3614

## Nominated RFCs, PRs, and issues

### "Implement pin-project in pattern matching for `&pin mut|const T`" rust#139751

**Link:** https://github.com/rust-lang/rust/pull/139751

TC: Fully reviewed by Nadri. Part of the pin projection experiment. We're landing a piece that includes an attribute. It's not stable, but we own the namespace for all attributes. Even the ones on nightly can have stable effects. The proposed `pin_v2` attribute name has no breakage in crater. Lang checkboxes are up. I propose waiving the 10 day period.

Niko: I want to note my desire to understand where the design's at.

TC: It's on our list of items for our checkin.

Josh: In the last design meeting we had an aside with Yosh about the various approaches of pin vs. projection vs. other things. I assume there's a conversation underway to handle these (is anything going to supplant the other). Some future stabilization should not be blocked on the bases we already had the conversation.

TC: That's four checkboxes.

### "Stabilize `const_mul_add`" rust#148052

**Link:** https://github.com/rust-lang/rust/pull/148052

TC: There's a libs api stabilization of constification of mul_add. Ralf said under the hood there's an intrinsic that needs to be const stabilized. And said it should be good. Scott agreed. There's an FCP here for our being OK with the stabilization of the intrinsic.

Josh: Added the third checkbox.

tmandry: Added the fourth.

Tracking issue: https://github.com/rust-lang/rust/issues/146724

TC: Burntsushi may have misunderstood and added us to the Libs API FCP as well.

Josh: Given previous mild friction about whether Lang needs to be on a given FCP, I'd prefer for Lang to overtly say we don't need to be on this.

TC: I already made the comment that we don't need to be on this: https://github.com/rust-lang/rust/issues/146724#issuecomment-3438828770

TC: Josh, to confirm, you don't want us to check the checkboxe, and you'll handle this.

Josh: Yes. I'll cancel the FCP, start it again without Lang and re-add the checkboxes.

TC: Good. You can reference my comment.

Josh: Will do.

### "Make deref_nullptr deny by default instead of warn" rust#148122

**Link:** https://github.com/rust-lang/rust/pull/148122

Scott: The only thing that comes to mind: What are the places that opsem's ??. ZSTs are okay I think.

Scott: I think this is still useless so it's fine to complain about it?

Niko: Define useless?

Scott: Reading a ZST from a pointer to null.

Niko: Deny doesn't seem appropriate

Tyler: +1, if it's defined behavior

Scott: Would we need a second lint to warn in non-ZST cases and warn in ZST cases?

Josh: Do we want the current deref null pointer to be the thing that happens on a non-ZST or on ZST? I'd assume we want to introduce a new lint for what happens on the ZST.

Scott: How much do we care about linting on that?

Josh: We're making the attempt to allow the cases that are widespread in the ecosystem and provide a way to improve that. A ZST is not really from memory and you're still writing ??

Scott: Did we say "no, you're absolutelly allowed to read memory a ZST from a pointer?"

Josh: I think we said we allowed to read from a pointer. But I don't recall we said you're allowed to read from a null pointer.

Tyler: Sounds like we need more facts. I think we should align the lint with whatever the rules are for ZSTs.

TC: I'm checking the Reference. A reference pointer is dangling if not all the bytes are part of an allocation. If the size is zero then the pointer is never dangling even if the pointer is null.

https://doc.rust-lang.org/1.90.0/reference/behavior-considered-undefined.html#r-undefined.dangling.zero-size

Tyler: Then I think we should align the lint with that.

Scott: Would we then say we're inclined to move this to deny as long as we don't deny on ZSTs?

Josh: That's fine though null pointer reference is still quirky so there's value to lint for ZST even if we're not denying it.

Scott: There's never any value in reading a ZST through a pointer.

Niko: That's not true I think. Maybe you're using it as a signal you have a permission to construct a ZST.

Scott: the "right" way to do this will be https://doc.rust-lang.org/nightly/std/mem/fn.conjure_zst.html

Scott: I'll write up a comment here. And maybe I'll drop a thing in the Conjure ZST tracking issue that once this exists, other ZSTs tracking this might be interested?

### "Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint" rust#148214

**Link:** https://github.com/rust-lang/rust/pull/148214

TC: Josh, this is an extension to the one you did earlier.

Josh: I think this is worth some discussion. I added a PR that said that a `Result` with uninhabited Error type or a control flow with uninhabited Break type is something you don't need `must_use` for if the type is unit.

Josh: What Waffle is proposing here is that , so if you had `Result<u32, !>` that would never be must_use and would not post any warnings. I'd oppose that because you may have a function that's `Result<T, E>` where `E` may sometimes be `!`. I would argue in that case for it to always be must_use.

Josh: Making this change would lead to ignoring a lot of things as "no longer must_use" when the Error type can't happen. But that doesn't necessarily mean that you can ignore the Ok value.

Scott: I was going to ask about into_ok and friends. They're not stable right now.

Josh: My understanding was that they're waiting on `never` and some confidence that `never` is in its final state. But we could stabilize into_ok and into_err and we could stabilize those.

Scott: They're only relying on the Into impls of the types, not any special aspects of `!`.

pub const fn into_ok(self) -> T
where
    E: Into<!>,
{ ... }

Tyler: What trait are you proposing exactly?

Josh: The bound on into_ok / into_error is the bound is `Into<!>`.

Tyler: So you're saying it should be `Into<Infallible>` instead.

`E: Into<core::convert::Infallible>`

TC: Josh, do you have example of code where you'd want the lint to still fire even when the error type is inhabited?

Josh: Today `Result` is always considered to be must_use. The exception to that is I added a suppression for `Result<(), Uninhabited>` which will always be `Ok(())`.

Josh: This is about what if your result type will be `Result<T, Uninhabited>`. For example you could imagine a String method that returns `Result<String, E>` and `E` could sometimes be uninhabited.

Niko: I think what you're saying is that you might want the must_use of the Result to apply to the Ok as well?

Josh: Not quite. Today, because `Result` is always must_use, when you write a function that returns a `Result` it would always be must_use.

Niko: I think you're saying is there's still a question for why Result is must_use. One of the options is to make sure that the Error is handled. Or it's because the Ok might be must_use. Or, people leverage the case that it's always must_use for the case where people should observe the Ok value as well.

Josh: Something like the third case, yes.

Josh: My concern is: if you have a function that returns `u32`, you can ignore it. If you have a function that returns `u32` and you mark it `must_use` then you must use the result. If you have a function that returns `Result<u32, E>` and `E ` can sometimes be `!`, you have it by default.

Josh: If we had a way to mark the `u32` in the `Result` as `must_use` then I'd be fine with this. Until we get that, we're silencing a warning that people are relying on today.

TC: While I agree there are other more precise `must_use` features we could add, I don't necessarily want to see the ask here in that light. There's an obvious interpretation of `must_use` -- it's the first case Niko brought up where you're doing the `must_use` to ensure the enum is destructured. Therefore if one of the invariants is uninhabited, that doesn't apply. I feel the other case is not what we intended it for, and that we shouldn't design around that.

Josh: To be explicit, I think this PR represeents a state we should eventually try to get to. My only argument here is I think we should recognize the fact that historically we had a must_use here that people relied on. So we should have some transition strategy for doing what people intended to do here.

Niko: I'm not convinced we need a transition plan. Not without at least one real-world example. There's always been ambiguity, but the intention was about that there may be an error you should see. I think it's a good point and a subtle distinction.

Josh: +1 to having real-world examlpes.

Jack: We could get the data. We could do a crater run, figure out all the cases where you have `T -> !`. It's a pretty simple experiment to do.

Josh: The change that's proposed here will only ever remove warnings. It sounds like you're proposing you'd find out every case of warning that goes away with the PR. I'm a huge fan of collecting that data.

Jack: Yeah. And I can also work with Waffle to collect it.

Josh: Let's collect the data and let's state that we want

Jack: I'll post the comment, give my thoughts on data and help out if needed.

Scott: Crater is likely to hide code that people did to hide the must_use warning. Might be difficult to find the situations where the linting was useful because people saw the lint and changed the code.

Jack: The approach I'm thinking is: if we ever see a return type of `Result<T, !>` that would used to error out and not now.

Scott: Got it.

Jack: I'll post the comment.

TC: Are we happy with that?

Niko: +1

### "Tracking Issue for RFC: Supertrait Item Shadowing" rust#89151

**Link:** https://github.com/rust-lang/rust/issues/89151

TC: Amanieu was asking. Stabilizing is blocked on lang, what do we want to do? We should vibe check. If no issue, reply that stabilization PR is welcome.

Amanieu: I think there's still an unresolved question around lint levels.

Josh: The concern is something coming to the standard library that could shadow an existing item in the code. Should we deny or allow?

Scott: How do people think about making some sort of syntax for people to clarify which method they meant in the shadowing cases. In the use site? Not something that should block this.

Josh: Are you talking about the lint to tell you "there's a method that tell you the function you should be using".

Scott: Yes. Even if though I'm using itertools I've done the migration and I want to use the one used in the standard library.

Tyler: I'd love to be able to write `iter.Itertools::intersperse(a)`. I don't want to block this feature on that. But positive to me.

Josh: +1 on having syntax for this. I used to be an advocate of "I think we should lint on these cases to help people transition" however, we've had some more recent discussions around the idea of "should we have a family of lints that primarirly exist for people they want to be extra careful about convenience features that could bring issue". We could have this be allow-by-default and then set this as "please nitpick this for my library".

Tyler: Josh, are you proposing making both lints allow by default?

Josh: Yeah, both could by allow-by-default. And we could see if one of them could go into a future nitpick lint group.

Tyler: I think we should make the call site allow by default and the definition one warn by default. But I'm not against having both allow by default.

Josh: I'd be happy with either of those.

Scott: I liked what Josh said about the lint group. The dev site being warn makes sense to me. That's most useful to us for cap-lints. Especialy if it's accidental that would be a good warning. But for shipping I'd be fine with either way and not block it on the syntax that would make it easier to disambiguate.

TC: I'd be happy to want at the def-site; the use site, in my view, should always be allow-by-default. We broke it out for that reason.

TC: Does anyone think the def-site should be allow-by-default?

TC: Amanieu, what do you think?

Amaineu: I'm personally inclined to allow both. I think realistically this is only going to affect crates like itertools. But I guess those specific crates could just allow the lint.

Josh: That's the expectation. And also: we want to think it's just these crates. But I also think that there'd be value in catching cases where we didn't know that we picked the obvious name and someone in the ecosystem had already done it.

Tyler: My argument for warn-by-default is: yes, itertools can allow it. And it prevents new instances for things like this coming up in the ecosystem.

Scott: I think it's particularly nice for having my own iterator traits and warn on once it's shadows somethnig. Anyone with a supretrait, especially with a large trait from an external crate, this would be useful.

Josh: We could have a lint tat's allow by default that's "you're shadowing something and it's got the same signature" and "you're shadowing something and it's got a different signature". Not saying we should switch to that, but that might be a compromise position if we'er getting too much noise.

TC: I do wonder, once we stabilize this, whether people are going to do this intentionally. Is there a usecase we're going to discover where people will say that they really want to shadow the supertrait. That's where I could see the warn-by-default people finding that onerous.

Scott: In a language like C# where you can override or shadow a method, at least conventionally it requires you put the `new` or `override` keyword on the shadowing/overriding definition. So there is an expected way to say this. If it becomes common we could create a new attribute. But the languages where I've used this generally required explicitly saying you're doing this.

Scott: also we have `[expect]` now, so `#[expect(shadows_supertrait)] fn foo(self)` seems like a very clear, albeit non-terse, way to clarifying this.

Niko: Folks on the Lang team seme pretty aligned on this. Am I correct in that? Amanieu I know you fellt differently. I'd summarise that as YAGNI?

Amanieu: Yes.

Niko: in that case we I propose we go with warn-by-default. There we'll see how much of a noise this is. We could also do a crater run. And we can then relax the lint later if that is an issue.

Jack: Do we want a quick crater run with the error?

TC: We're not in the situation now since we don't allow supertrait shadowing at this point.

Josh: since we currently don't allow it, no one in the ecosystem should be able to use it.

Niko: We do allow you to define it. But it's probably unlikely people would do it given you can't really use it without the ambiguity.

TC: Amanieu, does this clear a way for the stabilization for you?

Amanieu: Sure. What about the lint levels?

TC: you want to do this before the stabilization PR. People in the Compiler get cranky if the stabilization PR does more than just flip the feature.

## Nominations (part 2)

People: TC, Niko, tmandry, Josh, Amanieu, Jack, Aapo, Tomas

### Meeting roles

- Driver: TC
- Minutes: Tomas

### "Add new `function_casts_as_integer` lint" rust#141470

**Link:** https://github.com/rust-lang/rust/pull/141470

TC: We talked about this last week. We said, "where's libs api on the stabilization of the fn pointer trait?"

Amanieu: The fn pointer trait wouldn't help -- it implements Fn for a pointer.

TC: Is there an appetite for it?

Amanieu: It's nice to have. We're in favor of adding this.

Josh: If we added `FnStatic` and did the work, would we be okay there or would there be an issue with provenance?

Amanieu: There is an issue with provenance. The behaviour of casting a pointer from integer exposes provenance.

Josh: FnPointer and FnStatic have a `.addr` method return a `*const ()` so if we have a `addr` that returns a const pointer to unit and return the same thing for ?? and

Amanieu: I wouldrn't call it `.addr`.

Amanieu: There's another concern: you might want to not take `self`. But then you can't use the . syntax with it.

Tyler: A function that returns `*const ()` .., it seems like one of those things we might regret it one day. It would be nice if we could be more conscientious about keeping our code and data pointers represented separately.

Josh: Today you are allowed to cast a code pointer to a "data" pointer using `as`. It would be great if we could get rid of that by introducing `.something().expose_provenance()`. That's separate from completely disallowing this on architectures that completely separate code and data pointers. But that seems orthogonal.

Josh: Making it using a single regular trait rather than `as` cast seems like it moves us in the right direction.

Tyler: I'd prefer if the trait didn't force you to go through a data pointer.

Josh: So going through an `usize` would be okay with you? You just don't want to go though a data pointer (`*const ()`)?

Tyler: Yes. We already support `as` casts but we also frown upon doing that for pointers. As part of that, can we also be conscious of this distinction?

TC: In the context of converting something to `usize`, what would be your expectation about Harvard architecture?

Tyler: Once you've got a `usize` it's your responsibility to use it in the code context again rather than think of it as being in the same address space as a data pointer.

Josh: We could consider to add features for address space similar to C extensions.

Josh: No objections to having a trait that returns a `usize` with or without provenance. And if we had those two methods we could have a lint recommend people use `expose_provenance`.

Amanieu: A real example is the CHERI platform where function pointers are twice the size of `usize` because they contain the pointer and metadata. And you can't get a function pointer from the usize.

Amanieu: From expose provenance already isn't supported on CHERI.

Amanieu: one potential option to do this: https://github.com/rust-lang/libs-team/issues/589#issuecomment-2981331798

Josh: The point of this warning is to catch cases of code that create bugs that expose CVEs. E.g. comparing against `u32::max` vs. `u32::max()`.

Josh: We should do the broader design, but we should find some way of speeding up getting the lint.

TC: I like having a trait for it. I'd also be happy to suggest desuggaring what the trait does (as cast to `*const ()`). We could change this aspect of this later. It correctly represents the semantics we have today.

Tyler: I'm not suggesting we design something to represent different code segments. I'm saying that if/when we stabilize the `FnPtr` trait concretely, I'd rather have methods that directly return a `usize` rather than roundtripping through a data pointer. I'm not saying we need to do that before enabling this lint. But that seems a better design to me.

Josh: Two concrete proposals:

Proposal A: ship `FnPtr` and `FnStatic`, with methods `addr` and `expose_provenance`, ship the lint, and have the lint suggest `.expose_provenance()` for the "you really did want the address of `u32::max` as a `usize`" case.

Proposal B: ship the lint and have it suggest `as *const () as usize` for that case.

TC: On proposal A, if we have two methods, one that exposes provenance and the other just exposes the addr, how do we know which one the user wants when making a suggestion?

Josh: There's no fundamental way to know, but if you want to be able to round trip it, they need the provenance. If they don't intend to round-trip it, they may skip provenance, but it won't hurt to have provenance there.

Tyler: The main usecase for not needing provenance is the optimization to tell if two function pointers would be the same function.

TC: It's a libs-api matter, but if the one you want most of the time is the one with the provenance, why is it the one with the longer name?

Josh: Historically, we had the `addr` method and then added `expose_provenance`. So it's consistent.

TC: What do people think about Josh's proprosals?

Amanieu: I prefer proposal B because there's a lot of unresolved questions around the traits. And they're not even implemented in nightly.

Josh: We could fix the latter, but what are the unresolved questions?

Amanieu: Do we want to use an extern type? The `FnStatic` trait should have the `addr` and `expose_provenance` methods not take `Self` so in generic context you should be able to get an address of the function without having an instance of the object. But that means not having access to the `.` syntax.
(Some further discussion about whether you might want to use `FnStatic` to conjure something out of thin air.)
... disregard that.

Amanieu: I could see this working, but it would take a few months to get into nightly at best.

Amanieu: We have the lint available now so I'd still go with Option B.

Josh: I have no objection with shipping the lint now and providing a better suggestion later. For most of the people triggering this lint it will be "oops, I didn't mean to do that now" and the rest will want it and so they will write the uglier as cast.

Tyler: `as` cast are things we want to get rid of in the future so we could close this and

TC: Sounds like we're leaning towards the proposal B, the suggestion to cast to a unit pointer.

Niko: I think it makes sense. My only concern is: will we actually add the traits? This situation comes up regularly, where it's easier to add the hack but it would be great to have the traits. We should encourage Option A at some point.

Tyler: Is there a tracking issue for the fn pointer traits?

Amanieu: No.

Tyler: To me, the first step is making a tracking issue and referencing some of the commentary we made in this meeting.

Josh: I'll write up the proposal B.

Josh: The proposal to discussing the function pointer traits is a separate thing to discuss. What we'd do for this lint would be to suggest the lint to do `as *const ()` for usize?

Tyler: Amanieu, is it okay if I open up a tracking issue for this even though we don't have an RFC?

Amanieu: We have an ACP: https://github.com/rust-lang/libs-team/issues/589. You can open the tracking issue.

Tyler: Do we have consensus for keeping code and data pointers in the future?

Josh: I think we should build the infrastructure on making it possible.

Niko: I'd go a bit further and steer people towards that distinction.

Josh: Part of the reason I'm hedging here is that not everyone targets CHERI / wasm. And I wouldn't want warnings on huge swatch on systems code where this is perfectly okay.

Amanieu: On all platforms we support code pointers and function pointers have the same size. It may be not be `usize` -- even in CHERI and wasm.

Josh: That's what we'd take into consideration for this: do the pointer have the same size, alignment, etc. +1 for exploring a design for this.

Josh: There was another broader question: whether usize and pointers are the same thing. And whether usize and C `size_t` are the same thing. At some point we should make make an actual decision there.

Amanieu: In CHERI, the decision has already been made.

Josh: For the question of CHERI, the question should be: is the type they're using something that should be `usize` or something else?

Josh: Just observing that there's a massive amount of code out there that assumes `usize` and `size_t` are the same thing.

TC: As an observation, this is another case that shows how lints can take a lot of lang team bandwidth. This is, I think, because it forces us to come to an agreement of how people should write code and what direction we're going with the language. People often ask, "why is it taking two months for the lang team to discuss a lint?" This is why.

### "Uplifts and extends `clippy::needless-maybe-sized` into rustc" rust#145924

**Link:** https://github.com/rust-lang/rust/pull/145924

Josh: ??

TC: There are three cases: 1) explicit relaxation (`+ ?Sized`), 2) implicit relaxation (`+ Pointee`), and 3) where a bound is already implied by being a supertrait of another trait in the bound.

Every instance of case 2 is also an instance of case 3. Even case 1 can, loosely, be seen as an instance of case 3 (if we treat `?Sized`, somewhat incorrectly, as being a supertrait of `Sized`).

Josh: Niko had a great proposal of labeling traits that imply relaxation with some sigil. That would collapse your case 1 and case 2.

Niko: There's been some pretty productive discussion in the project goal channel. There's design work that needs to happen first; let's defer this for that.

TC: We'll bump up the drag.

### "stabilize extern_system_varargs" rust#145954

**Link:** https://github.com/rust-lang/rust/pull/145954

Josh: The comment from Jubilee was that she was hesitent to stabilize "system". The follow-up on this issue is whether our FCP covered this. And folkert said that they didn't think the test coverage has improved since the PR was opened.

Josh: We can respon saying that we can ask for more test coverage.

Tyler: Ralf is saying that "system" is just C ABI with varags.

Josh: We could have a test that's equivalent to stdcall and have it run on Windows. That seems like sufficient coverage.

Josh: "system" is identical to C on every platform except 32-bit windows where it's stdcall instead. Varargs "system" is always the C calling convention. So the thing we want to verify is that on a platform where 'varargs is stdcall' we want to verify that varags is C.

TC: On the procedural question, here's my analysis. Even though the FCP did include what's in this PR, the fact that it landed without it puts it back in our court, just as it would if something we stabilized was later reverted. We'd FCP the restabilization.

Josh: Even if we thought we were FCPing something stronger than what was merged, we should reFCP.

Tyler: I think I'm fine stabilizing with or without more tests. I don't get the sense Jubilee's concern is very strong. I would check a box. But it's fine if someone wants to file a concern about more testing.

Niko: Is this widely used?

Josh: System is widely used. Varargs are widely used. Varargs for stdcall we just merged

Niko: We always have bugs. We're not questioning the interface, just the quality of the implementation?

Josh: Lang could say: "we're FCPing the fact that this calling convention sholud be shipped as part of the language, it's compiler's call is if they want additional tests or not"

Niko: Yeah, we call for tests only if they resolve semantic ambiguity.

Josh: If that's our consensus, I can write up a quick summary and do the FCP. This is a confirmation on that we should ship this as stabilized and we'll defer to the Compiler to see if they require more tests.

TC: To the degree that we need tests to ensure we understand what we're stabilizing as a lang matter, we would block on that. When we're happy on that front and instead the ask for more tests is due to a matter of implementation correctness, we can leave that to compiler.

Tyler: Sounds good to me.

### "Emit error when using path-segment keyword as cfg pred" rust#146978

**Link:** https://github.com/rust-lang/rust/pull/146978

TC: Eric Huss and I talked about this yesterday related to some Reference work; petrochenkov has a nomination for us at the bottom.

Josh: This makes sense. `cfg` always rejected keywords but cfg always parsed paths and something like `super` or `crate` is a path. No objections in crater, let's ship it?

Josh: You should not be able to write `cfg(super)`. Those aren't predicates that should be treated as true or false. It's a path segment keyword.

Tyler: Seems like a bugfix.

Josh: Yes, and zero issues in crater.

TC: Were we accepting all keywords?

Josh: We were rejecting all keywords. But we were accepting paths, and some path segments were keywords.

TC: Looking at the Reference: a configuration option is an identifier (non keyword or raw identifier).

https://doc.rust-lang.org/1.90.0/reference/conditional-compilation.html#r-cfg.syntax

TC: I've updated the labels and I've kicked off the proposed FCP.

### "cmse: lint on unions crossing the secure boundary" rust#147697

**Link:** https://github.com/rust-lang/rust/pull/147697

Josh: I asked the question of how we detect the case that this is done correctly and not linting in that case. Folkert responded with the process I'd follow to do this correctly.

Josh: Folkert, you mentioned how you'd write this if you were to do it corectly. The question is how do we arrange the lint to not trigger if you do this correctly.

Folkert: that's tricky. In practise the lint is meant for this case to not to occur. The only reasonable thing to do on the boundary that's this strict is to not send usions or partially uninitialized values.

Josh: And this is just working on unions, not trying to catch padding?

Folkert: Curretly, yes. But padding falls into the same category. And that's something you want to prevent too.

Josh: I'm also familiar with this from the Linux kernel as well where you want to be sure you don't send anything unitialized to the userspace. That may be useful for the Rust for Linux folks.

Josh: Is there any pattern where we can say "if you do this, we won't lint"?

Folkert: I understand the idea, I just don't see how you'd do that without trakcing how the value was created.

Josh: The other approach we could take is: GCC and Clang have a concrete mechanism where you can set a compiler flag and they will initialize all things on the stack including padding. And Linux turns that on. It initializes everything so you can't leak something even if you screw up. That sounds like something CMSE would be interested in.

Folkert: Yes. Clang lints on all unions. That's what we're mirroring here. But if you have a compiler flag that just zeroes that out, that'd be even better.

Tyler: If we take a view that returning a union or padding is a bug, I think that justifies the lint. And then the question of making the lint going away is "don't do that".

Folkert: Or you specifically allow the lint on a specific argument or return at use-site.

Tyler: That does seem better.

Folkert: It can be a really subtle way of leaking information on a system whose whole point is to not leak any information.

Josh: The rationale is clear. The question is what do we want people to do. If the answer is "never use a union" then this lint is fine.

Josh: If we want this to lint when people are not using the lint correctly then this lint doesn't do that.

Folkert: Annotating the type (saying you must always initialize this) is interesting.

Josh: You could also imagine having a method or macro or similar that would fully initialise all the padding etc. And if you call that method right before return we wouldn't lint.

Folker: I think this is good. I'll submit an RFC hopefully for the whole cmse thing. The lint can wait until then.

Josh: If you feel the lint is urgent in the way that we previously discussed a security sensitive lint. If you think it's security sensitive, please raise it again to us. If you don't need to rush, then let's take a look at the RFC.

Folkert: I don't see the reason to rush this.

Tyler: Is the RFC for cmse in general?

Folkret: Yes, and the design includes a lint.

Josh: Can you get in touch with the Rust for Linux folks and ask whether they're interested?

Folkert: Yes.

### "Fix ICE when applying test macro to crate root" rust#147841

**Link:** https://github.com/rust-lang/rust/pull/147841

TC: Nora gives the relevant part of the description: https://github.com/rust-lang/rust/pull/147841#issuecomment-3458849282

> The fix now first does target checking, and only if the target is valid discards the item when --test isn't applied. The discarding is, I think, important for perf.

> The problem with this PR is that it means that #[test] applied to structs previously would give no errors unless --test is applied! That sounds like a bug to me, but maybe we should crater run it just in case, since technically that's a breaking change. Errors in such items wouldn't be reported previously.

TC: Looks like there was one real regression in crater.

Tyler: Seems like an easy decision in my view. Applying `#[test]` attribute to something other than a function, that thing will be configed out when it's not a test. It effectively acts like `cfg(test)`. This is probably a bug. And the only crate this breaks is a crate that's already broken.

Josh: And it sounds like the error already has a suggestion saying "did you meant to use `cfg(test)`?"

TC: Makes sense. I'm looking at the Reference:

https://doc.rust-lang.org/nightly/reference/attributes/testing.html#r-attributes.testing.test.allowed-positions

TC: It says: "`#[test]` attribute can only be applied to free functions that are monomorphic, that take no arguments..."

TC: This will be bringing it more in line with the Reference. Let's FCP it.

Tyler: I noticed this lint to say "non associated function" and I think we should call it "free function". I don't think that should block stabilization.

Josh: In theory there's no reason it couldn't work on associated functions that aren't methods. Not suggesting that we do that, just saying there's no reason it couldn't.

### "resolve: Preserve ambiguous glob reexports in crate metadata" rust#147984

**Link:** https://github.com/rust-lang/rust/pull/147984

Josh: There's a very good description for this here: https://github.com/rust-lang/rust/pull/147984#issuecomment-3455514826

Josh: The main reason this needs feedback from us, it breaks a number of crates. Do we want to allow this to break those crates? Soften the lint to soften the transition? Something else?

Josh: I think this is an acceptable amount of breakage. Fixes for the crates were already sent.

Tyler: Why aren't we making it an error to export an ambiguous re-export from your crate? Sounds like we're jumping through a lot of hoops to shift the error to the end user.

Josh: That sounds like a reasonable idea. But glob imports are already a giant semver hazard. But the more you error on them the more of a semver hazard you create.

Niko: If you ahve non-private use and you import two globs that overlap but you don't use the members that overlap it's nice that it works. The mentality is that if you extend it to public scope then the error should occur where you use it.

Niko: I think a pub use is a different kind and I'd arguably expect different behaviour there.

Josh: +1. I propose we FCP this as proposed. It's consistent with the existing ambiguous glob export lisnt and extend it to the public case.

Josh: I'd love to see a lint that shows you're re-exporting two globs that have conflicts. We could at least lint on the case where they are local globs. Those are under your control.

Tyler: This seems strictly better than what we currently do where we silently fail to include the ambiguous export in the crate. But now I'm wondering why it creates breakage.

Tyler: I see, it can contribute to ambiguity at the higher level.

Tyler: Today, if you have an ambiguous re-export using globs (you re-export two items named `S`) we simply don't include `S` at all. And if your users want to look up `S` we say we can't resolve it. The proposal is to bring in both `S` and tell you the import is ambiguous rather than saying it's not there.

TC: This is making it more correct in the model Niko described, and we're pushing it even further down that path.

Niko: I'm feeling a little reluctant to land this change. It seems like it's strictly less useful to users. I'd be tempted to instead go the other awy and if you have an overlapping pub use, warn at that module and note this entry is being ignored. I don't know how hard that would be to implement but I think that would be a better user experience. When you push this to the end users you can only make errors, you can't help them. They can't use your name anyway.

Niko: So I'd warn at the definition site. I'd rather know as the author.

TC: Eventually, shouldn't this be an error at the definition site?

Niko: Maybe? That's a separate escalation from silently ignoring to warning to error. At minimum it should be a warning.

Tyler: I agree with that. This change is positive in that it creates clearer error messages than we have today. But it still warns at the use-site rather than the def-site.

Niko: Yeah, it better aligns with the current model, but I don't think the model is the right one.

TC: This looks like it may have been an intentional point we decided. It has that feel. That is, the behaviour that where there's overlap we don't export it at all.

Niko: I think we decided it in the private use and the pub use came out of that. I don't remember us discussing it.

Josh: I don't remember us making an explicit decision about this property.

TC: The current behaviour has a convenience to it. It seems like the sort of thing the implementer might have done, realizing the complexity and picking the most useful of the choices.

Niko: I could see that. I don't recall us on ever deciding this as a lang team.

TC: The issues is said to be a blocker to: <https://github.com/rust-lang/rust/pull/145108>.

Niko: I can't imagine how that can be true. I wonder if the reason it's blocked is because it doesn't have a convenient way of finding out where there's more than one pub use. I'd love to see petrochenkov explain that more.

TC: Let's say that we warn at the def-site. Are we OK with this PR in that case?

Niko: To me it seems like a wart but not a fatal one. It does have some nice semver properties. I'm pub using two crates, they don't overlap. At some point they may add something that conflict, it doesn't break.

TC: As long as they both add it at the same time. If one crate has it and people are relying on it, and then another crate adds it, then it magically disappears entirely.

Niko: That's a good point. Either way your users break.

Niko: Today, we don't have a way to disambiguate these kind of cases. But you could imagine in the future some form of disambiguation. So it would no longer be a breaking change. We talked about compiling rust source to a fully qualified form.

Tyler: My proposal is that we accept the change and request a warning at the def-site.

TC: Yes.

Niko: I agree.

TC: I think of this in terms of "ambiguity monotonicity". Adding ambiguity should never reduce ambiguity warnings.

Josh: Making it worse should never make your warning go away.

Tyler: Or ambiguity error, in this case.

Niko: I think that's consistent with the fully qualified thing I mentioned.

Niko: We should probably just lint if you have two globs anyway.

TC: How do we handle this? Do we want them to not land this until they add the warning?

Tyler: I would like to pair them. I'm not going to personally block them if that's hard to do. But we should ask for it and be open to pushbakc.

Niko: Sounds good.

Josh: We've also talked about a possibility of warning any time you blob import anything that's not called prelude. That would be more agressive but I honestly think that would be a good thing.

Tyler: Might be a clippy lint already.

(The meeting ended here.)

---

### "feat: guarantee the binary representation of `isize` explicitly" reference#2064

**Link:** https://github.com/rust-lang/reference/pull/2064

TC: This is something that's easy and isn't in the Reference yet. It must be true.

Tyler: Sure. I can kick off an FCP on that.

### "Make `cpuid` safe and update docs" stdarch#1935

**Link:** https://github.com/rust-lang/stdarch/pull/1935

This is here for checkboxes.

### "error out when `repr(align)` exceeds COFF limit" rust#142638

**Link:** https://github.com/rust-lang/rust/pull/142638

Let's ask for a Reference PR for this.

### "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

### "Not linting irrefutable_let_patterns on let chains" rust#146832

**Link:** https://github.com/rust-lang/rust/pull/146832

### "Add `cargo_cfg_target_family_multivalued` FCW" rust#147545

**Link:** https://github.com/rust-lang/rust/pull/147545

### "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

### "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

### "Stabilize `asm_cfg`" rust#147736

**Link:** https://github.com/rust-lang/rust/pull/147736