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

# T-lang meeting agenda

- Meeting date: 2025-10-22

## Attendance

- People: Niko, Tomas, Tyler, Yosh, Jack, TC, Josh, scottmcm, Aapo

## Meeting roles

- Driver: TC
- Minutes: Tomas Sedovic

## Scheduled meetings

- 2025-10-22: Extended triage + champion updates.

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!)

Tomas: All hands 2026: if you plan to attend, please fill out this form: https://forms.gle/GhkvDSfdBaYHUrRJ7 (Mara's request)

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

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

## Nominated RFCs, PRs, and issues

### "Make closure capturing have consistent and correct behaviour around patterns" rust#138961

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

TC: We have a proposed FCP. We accepted it earlier this year; it then got held up in review. It came back as being almost ready; that prompted us to put the Reference docs in order, which they now are. In doing that, we discovered there's a piece of stabilization we didn't end up approving from the lang side earler. That's what we should discuss here for visibility.

https://github.com/rust-lang/rust/pull/138961#issuecomment-3419178287

TC: What we accept today is this:

fn f<'l: 's, 's>(x: &'s mut &'l [u8]) -> impl Fn() + 'l {
    || match **x {
        [] => (),
        _ => (),
    }
}

And today we reject this:

fn f<'l: 's, 's>(x: &'s mut &'l [u8]) -> impl Fn() + 'l {
    || match *x {
        &[] => (),
        _ => (),
    }
}

And that will accepted under this PR.

You'd expect either both to be accepted or rejected, so it's good that this PR will make these consistent.

TC: The interesting bit is whether the closure captures the pointer or pointee of a slice like this when reading the length. Do we act as though we're reading the slice or act as reading the wide pointer (that has the length)?

TC: Niko can you perhaps discuss the history here?

Niko: I think we're capturing places. The place we're capturing here is `**x` by reference. So it's capturing a place in a certain mode. And here, the only action taken is to read the length of `**x`. Since it's not a move closure, that'll correspond to a by-reference read.

Niko: If `x` was owned (e.g. in a box) it would be rejected because the box is owned by the stack frame. It's falling out from us not capturing the root of the place and recreating it when you execute the match. But rather capturing the place directly. We can traverse the pointers in some cases. Not when you're moving/copying. If you're referencing, it's not a concern.

TC: The interesting thing is: we're not reading the slice, we're reading the length.

Niko: the closure desugar (I believe) decides this is a "read" and therefore it should use "ref" mode. This means that you introduce a `let x = &$place` and you replace references to `$place` with `*x`, so something like this. We sometimes truncate the place that you capture but not in this case because there's no harm in it.

fn f<'l: 's, 's>(x: &'s mut &'l [u8]) -> impl Fn() + 'l {
    let c = &**x; // effectively equivalent to `*x`
    move || match *c {
        [] => (),
        _ => (),
    }
}

Niko: conceptually, you're borrowing the contents.

scottmcm: Len used to look at the whole place: <https://github.com/rust-lang/rust/pull/146564/files#diff-3a6077a453e9ef35b5b85b4419025066cc7a0f3bad1207ae98860902c817a252L1418>

scottmcm: It was changed relatively recently for len to look not at the place (see `Rvalue::Len` above), but at the [`PtrMetadata`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.UnOp.html#variant.PtrMetadata) of the pointer (or reference or ...) instead.

Josh: Is there ever a circumstance where you might be able to change that length in a fashion that would be conflicting with the fact we've snapshotted it here and don't have to account for the pointer?

Josh: We store a thing outside of the physical auspices where the pointer points, what makes it so the compile tries it to have the corrent runtime. What happens when the length changes?

Niko: It can't change because you as a programmer don't have access to the length.

Josh: You can create a new slice but you can't change the length of the current slice.

Josh: I see: so even if you had a mutable reference to the slice and you could replace it with a slice with a different length, the length in the pointer would be replaced.

Josh: Understanding that changing it changes the inner thing and what lifetime is tied to the reference.

Niko: Yeah, this is the magic of shared references. If you have `&mut &mut` you can't access the long lifetime. It's as if you have nested locks. And you can only access the short lifetimes.

Josh: If you have exclusive reference you can change the associated length of the wide pointer.

Niko: You can't change the length really, you can only replace it with a new pointer. It's really as if it were a longer pointer.

Niko: Think of it like a struct with two fields but they're private.

Josh: So the key distinction that's potentially confusing if you just think about a reference as a pointer and don't think about the length being "floated" to the top is that you can't have a pointer-to-wide-pointer, you have a wide-pointer-to-pointer.

Niko: I'm in favour of this change from the outside. We do generally try to be smart about the place. We approach the place semantically not syntactically.

TC: I think it's fortuitous accident of this PR that it makes things work the same as they should.

TC: We'll say we looked at it for visibility and say it's still good by us.

Josh: Is there any expected degree to which it takes accepted code reject?

TC: There was a breaking change that was part of stabilization.

Josh: That's separate from the changes you were describing here?

TC: Yes. We just want to double check since it's been a while since we ran it last.

### "Impls and impl items inherit `dead_code` lint level of the corresponding traits and trait items" rust#144113

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

TC: We have a FCP and we're picking up checkboxes.

TC: Niko, you proposed a model for how it should work. The author said it does align with your model. I checked a box given that. Does that sound right to you as well?

Niko: Sounds good to me.

### "Stabilize s390x `vector` target feature and `is_s390x_feature_detected!` macro" rust#145656

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

TC: It just went into FCP.

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

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

TC: There's an interesting angle here given our "ask for what you need" model for the hierarchy of `Sized` traits work. Consider:

// Case 1.
trait Tr: const Sized {}
fn f<T: Sized + Tr>() {}

// Case 2.
trait Tr: MetaSized {}
fn f<T: Pointee + Tr>() {}

// Case 3.
trait Tr: Sized {}
fn f<T: ?Sized + Tr>() {}

We had considered trying to separate an "unused relaxations" lint from a lint about bounds that were unused due to already being implied by being a supertrait of another trait in the bound. But for something like case 2, that would fall under both cases.

It's also, from a user perspective, not so clear to me that case 1 and case 2 are that different. And of course case 2 and case 3 are related.

Josh: It sounds like an "unused this is sized bound" and "unused this is unsized bound" they're both effectively unused.

Josh: There is a slight concern where someone may be more confused by an ignored `?Sized` than `Sized` bound. Because with an unused `Sized` they got what they wanted, whereas with an unused `?Sized` they *didn't* get what they wanted (and there's no way to get what they wanted).

TC: In thinking about case 1 and case 2, the question is, "did you get what you wanted?" In some sense you did -- you got at least as much as you wanted. But you maybe didn't get as little as you wanted.

Josh: This is like unions of feature flags, where we can't do less than the union of what everyone asked for.

Niko: If you ignore the fact that there's a default, it behaves like any other combination of traits. But `?Sized` is saying "turn off the default" and that's completely redundant.

Josh: Is the proposal to put all of them under the same lint? Or a lint group with potentially two separate lints?

TC: This is coming up in the context of the hierarchy of `Sized` traits work, so it considers case 2 and case 3 to be similar, but it doesn't lint on case 1.

Niko: I expect that `T: Sized` is fully redundant. In my original proposal the default applied not only to the trait but any subtrait of it. If you `T: MetaSized` and `T: R` then you had R: Metasized as well. Otherwise you have to repeat yourself any time you reference T: R. But it has some confusion as well.

Niko: Putting the `Pointee` there is needed because you want to disable the automatic `Sized` one. You could also use `MetaSized` instead. It all makes sense to me. I think it's consistent.

Niko: There's a question separate from the lint of: are we happy with this model and in particular how the supertraits work?

Tyler: I feel it should be acceptable to write a trait bound you need and rely on. And not have a lint saying that it's implied by a supertrait bound. It might make the code a lot clearer even if the bound is redundant. So it makes sense to me to have two separate lints (one for the redundant case and the other totally unusable). The `T: Pointee` (or Metasized) bound is positively ??.

Tyler: I was talking with Taylor Cramer whether we should introduce some kind of keyword that says you're relaxing the default bound:

`T: only Pointee`

Tyler: It's a useful property to be able to say "it's okay to have a redundant bound", and that's different from an unusable bound. The way we're currently framing it doesn't give us that.

Jack: Sounds like Scott's almost saying we shouldn't be linting on this at all. Even the `?Sized` is essentially the same as `Sized`. You can imagine the supertrait of `Sized` be `?Sized`. It's not queite right because it's a relaxation. But if you have a negative bound (that's not MetaSized), you don't care that the trait bound is more strict. I think it's okay to say we don't want to lint because you can just write `Pointee`.

Jack: `Pointee` is different than any other trait because of the specific relaxation bounds. But `Sized` maybe isn't. The negative bounds make more sense when you're trying to say you don't want a function that's more strict than what you need. But we don't have that and that's not what these are.

Josh: We should focus on what we're being asked for. TC, you said line 195 is not a relaxation, line 198 is. The proposal is to lint on 198. We may want to lint on 195 in the future, but that can be a separate lint. If the PR is currently proposing that we only lint on 198, that's fine, we can ship it as proposed.

Scott: I can imagine writing `T: Clone + SomeForignTrait` even if the foreign trait includes `Clone`. I think there's a meaningful distinction between "those two bounds are incompatible" vs. "you didn't need to say that because it's been brought in by something else". I'd be happy for this PR to be just in the conflict form and worry about what the rules for a redundant thing is later. If we can avoid those conversations and move more complicated questions makes sense to me.

TC: Are you thinking about `T: Pointee` here or just when the question mark is written out?

Scott: The question mark is obvious, I don't know about the `T: Pointee`.

Niko: I think we should just rule on `?Sized` and leave the rest for later.

Tyler: We're trying to make decisions based on an unmerged RFC. Is that essential for the PR? If it's essential, we should push the RFC merged and have those questions answered.

TC: It is why they're doing it, as I understand. This is part of the hierarchy of sized traits work.

Niko: It's not clear how that supports that work in any particular way. As champion I'll reach out and understand why this is important.

TC: Going back to the example, I don't want to lint on just one of case 1 or case 2. I think that would be surprising. At the same time, I agree with Scott on why we may not want to do it in general. Scott, I'd make your point as being a static assertion.

Scott: I'd phrase it more in terms of implied bounds. If I'm making Clone, I want it to be there even if I have a complicated bound that has that bound. It's about showing locally too.

Jack: I wonder if `Sized` things are just special here because they have default bounds. I.e. would we want to lint for other traits? Probably less of a reason too, For sized things, I can imagine having these lints help with "avoiding surprise", whereas with other traits, there isn't much surprise.

TC: We'll table this for now, and Niko is going to follow up as champion on this to better understand the motivation.

### "Stabilize 29 RISC-V target features (`riscv_ratified_v2`)" rust#145948

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

TC: We're collecting checkboxes here.

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

TC: Ralf said: "we didn't discuss the lint name; I will presume repr_c_enums_larger_than_int is fine unless I hear otherwise." are we happy with it? I'm happy with it.

Josh: Seems fine.

Tyle: Seems fine, I'll resolve my concern.

Scott: Yep. Plausible and not a one-way door, we have the ability to change it later if we really have to.

### "Add warn-by-default lint for visibility on `const _` declarations" rust#147136

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

TC: We're picking up checkboxes.

Scott: Do people have strong opinions on whether we'd eventually make this disallowed?

TC: I agree strongly with you that we shouldn't.

Josh: This is a minor redundancy, worth flagging but not worth excessive.

TC: We FCW things we want to take out of the language when we want to simplify the language. In this case it would make the language more complicated.

### "repr(transparent): do not consider repr(C) types to be 1-ZST" rust#147185

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

TC: Picking up checkboxes...

Scott: I don't think you can even have ZST in C.

Josh: They do kind of exist in practice in many practical implementations of C, you can have a zero-sized structure. But I can't imagine you'd put one in a repr-transparent type in addition to the type you're trying to be transparent to.

### "Do not consider uninhabited 1-ZST "trivial" for the purpose of repr(transparent)?" rust#147588

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

TC: We talked about it and we agreed with Ralf that we prefer for this to be a static error. There are almost no regressions except for hyper. Sean filed an issue on hyper and they'll fix it but it'll probably going to take a while.

Josh: This seems like something where what we're trying to solve is not worth the huge breakage in the ecosystem. We should wait months.

Scott: Do we want to add something explicit about being allowed in a transparent type like this? We've had a lot of these. It would be nice to find a better answer here.

Scott (later): started a thread at <https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/.60repr.28transparent.29.60.20restriction.20improvements/near/546499911>.

(The first part of the triage meeting ended here.)

---

## Champion review

September updates: https://rust-lang.github.io/rust-project-goals/lang/2025-09.html

October updates: https://rust-lang.github.io/rust-project-goals/lang/2025-10.html

Niko: Champions will try to make sure updates are in there. Topics of interest, design, other pivots are documented with a rationale. And the point of this meting is to make sure the team as a whole is informed and flag any disagreements early. In the future we'll go from this to design meetings.

---

Bugs:

* Rendering is rendering `@foo` wrong (see Field Projections September update, the Syntax section)
* "Comment by" also has wonky formatting "Comment by [Aapo Alasuutari][] posted on 2025-10-22".
* It'd be nice to have github issue status and include the name
* It'd be nice to have the september issues link to october

Josh: It might make sense to have a rendered version of "everything since last update has been reviewed", since our reviews may not be perfectly in sync with calendar months.

Josh: Unlike the GH page this doesn't show "this is closed/merged/etc."

TC: Github also renders the actual name of the issue rather than just the issue link.

TC: Process feedback. I'm finding it difficult to read through and engage with all of them during the 30 minutes we have. It's a lot of jumping between disparate things. I wonder if there's not some more engaging way we could do this, e.g. having the champion talk through each item.

Josh: I was feeling something very similar. It could work to do this, but the process of "sit and read the document quietly" here is not effectively. We're effectively reading 30 short documents.

Niko: It's working for me, I enjoy being able to sit and read through these. But I'd be up for trying something different.

Josh: Might help to have section for each goal so we can group comments by goal?

Niko: I think it's less about the grouping of comments and more about all of us being in the same spot to read and discuss the same topic.

TC: When I'm looking at the updates of the goals where I'm a champion, I'm happy the full updates are here. But I could compress it to the important highlights, and that would seem more time efficient for the others here.

Niko: Are you saying: "live compress"? We could do tl;dr comments -- they're highlighted. Whatever we can put into github is that much easier to generate into the blog post.

TC: We know the state of mind of the other people on lang and what they're familiar with and what they aren't. That's a different compression than what would work for a wider audience.

Niko: Next time we'll go goal by goal and I'll put a timer on it.

Tyler: I think we should highlight all the relevant updates, flag any lingering questions and concerns and move on.

Tyler: There's a fair amount of feedback that was dropped here that we didn't discuss. How are we going to get it back to the champions?

Niko: I think we (Tomas or me) can open some topics to drop it into zulip and drop it to people.

---

Comments:

* nikomatsakis: I'm having a hard time understanding the ["splitting projections into containers and projections" section in this comment](https://github.com/rust-lang/rust-project-goals/issues/390#issuecomment-3326839670); I get the containers vs projections split, but I don't get much else
* nikomatsakis: interaction with negative marker traits ([here](https://github.com/rust-lang/rust-project-goals/issues/390#issuecomment-3326839670)) is interesting* Josh: Helpful updates on projections and pin, makes it clear they're talking and trying to align.
* Josh: cargo-script seems mostly on track.
* nikomatsakis: in the [evolving trait hierarchies](https://github.com/rust-lang/rust-project-goals/issues/393#issuecomment-3354114815) September update, I'm ... feeling unhappy about the idea of suppressing the supertrait explicitly. But maybe I just need to sit with it. I guess in cases where the trait doesn't have any members, it makes sense, and hence for uniformity it is probably nice all of the time.
* "However, this is in conflict with the goal of allowing auto impls to be added to existing trait hierarchies." -- hmm, is it? The *goal* was to allow an existing trait hierarchy to be split into two, right?
* I'm also feeling a bit nervous about the distinction of "auto impl" vs "auto trait" being rather confusing.
* tmandry: Pin ergonomics: I would prioritize stabilizing reborrowing for pin. We should also discuss the interaction with the [`Move` experiment](https://github.com/rust-lang/lang-team/issues/354).
* TC: Eric, is reborrow the first thing we implemented?
* Eric: we do have a nightly implementation of reborrowing. I'm not sure how relevant it is fro the project goal
* TC: I'm for pushing these pieces for stabilization
* Aapo: we have a generalized reborrow in a branch, not yet done. But for the purpose of implementing Pin reborrowing I'd guess 1-2 weeks before it's done.
* Assumption: `&pin mut T` must be desugared into `Pin<&mut T>` by the time we're in the THIR.
* EDIT: Nope, Aapo was wrong. Pin<&mut T> general reborrowing requires the Reborrow trait to properly recurse into the type's fields to perform reborrowing field-by-field. Our current implementation doesn't do this.
* TC: I don't think we have any degrees of freedom on how reborrowing would work for pin stuff. That's a very simple one to stabilize.
* Niko: I don't quite follow the update that well. It discusses alternative A and B. There's a mention of a pin-project attribute.
* TC: The tracking issue (not project goal) defines the proposal. Alternative B is the main proposal now.
* Tyler: I don't think the pin-project trait is part of the alternative.
* TC: You have to annotate that the type is opting into a new contract WRT Pin because you have to opt into a new unsafe contract. We can change it over an edition. It should be a default but it's hard to do that without an edition.
* Yosh: I second what Tyler said about the interaction between Move and pin ergonomics. It would be a good experiment.
* TC: I don't think it is an alternative. There's no way of getting pin out of the language today. It's not trying to increase the surface area; it's making what we have now better.
* Yosh: I respect you sharing that but I disagree.
* Josh: I think we should not discuss it right now, but it's worth having a discussion. We should figure out what the future looks like, and it's not obvious that the future only looks like a somewhat more ergonomic version of the present.
* nikomatsakis: I'm not understanding the pin update. I would appreciate seeing some code examples for how such structs look. I see for example Alternative B is described here, https://github.com/rust-lang/rust/pull/139751, but it says sometnig about `#[pin_project]`.
* Tracking issue: https://github.com/rust-lang/rust/issues/130494
* Josh: "SVE and SME on AArch64": really enthusiastic about the sizedness hierarchy, much more so from this project goal than from previous sizedness hierarchy proposals.
* Re the updates on sizedness traits, the proposed naming changes seem like an improvement over e.g. "MetaSized" but still confusing.
* Re the "implicit trait supertrait bounds", "Just change it, breakage will be small (have to test that).", I suspect it won't be small, I think it might affect most traits that have default method implementations.
* Josh: The name `SizeOfVal` confuses me but it's also growing on me. Having seen `Sized` for so long, it feels like I wanting to see e.g. `SizedFromValue`, but again, `SizeOfVal` is growing on me. `Pointee` on the other hand is not...
* Tyler: We should prioritize getting the Sized hierarchy merged without the `const` piece. The const is highly motivated by SVE and SME but the Sized hierarchy is more relevant broadly.
* Niko: I agree with all that. Shall we plan for a design meeting for this stuff?
* Josh: And we should discuss associated bits such as proposal for ??
* Tyler: The scope should be RFC excluding `const`
* TC: I think we're pretty close; I think we can use editions to narrow the syntactic footprint on this.
* Niko: The plan is to prioritize the non-const half. I think we're unblocked to get the crater feedback on the breaking changes. I'll see what the timeline is there.
* tmandry: Sized hierachy: I think we should prioritize getting the RFC merged without the `const`. I obviously like the `SizeOfVal` name since I proposed it. `SizeOf` would be nice too, especially if we support structs whose size is not a multiple of their alignment (that involves adding a new rung, `DataSizeOf`). We can approach a rename as part of that proposal.
* nikomatsakis: one thing I wanted to highlight from our triage is the use of the `=Bound` sigil as a way to flag "a default is being suppressed here" <https://github.com/rust-lang/rust-project-goals/issues/270#issuecomment-3432823824>

* Yosh: the biggest open task for the in-place init proposal as I see it is to evaluate `impl Init` vs out-pointers. We don't yet agree on all the facts / tradeoffs between the two. I've taken tmandry's suggestion to heart and am rebasing my placing functions proposal as a high-level notation that desugars to one of the other two proposals.

## Nominated items, part 2

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

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

Josh: This is about the security hole of potentially leaking uninitialized memory across the security boundary. cmse is a security boundary. If you have a union you could potentially leak bits that you didn't initialize. This lint is trying to catch the fact that you might be leaking information. It wasn't clear to me if this is a limitation of LLVM where you can't notice this because you've started

Tyler: What is CMSE?

Josh: It's an Arm security mechanism for building secure code that act as a security boundary.

TC: From the lint:

> The cmse calling conventions normally take care of clearing registers to make sure that
> stale secure information is not observable from non-secure code. Uninitialized memory may
> still contain secret information, so the programmer must be careful when (partially)
> uninitialized values cross the secure boundary. This lint fires when a partially
> uninitialized value (e.g. a `union` value or a type with a niche) crosses the secure
> boundary, i.e.:
>
> - when returned from a `cmse-nonsecure-entry` function
> - when passed as an argument to a `cmse-nonsecure-call` function
>
> This lint is a best effort: not all cases of (partially) uninitialized data crossing the
> secure boundary are caught.

Josh: I'm more familiar from this from an OS view where you could create a structure that had padding that wasn't initialised to zero and leak data. The kernel now tries to initialise this. But the question is: if you did initialise this, but we should be able to communicate that we have initialised it properly.

TC: It says here that "the calling convention takes care of clearing registers". What's the register caveat?

Josh: Normally, a calling convention doesn't scratching out registers that are "callee-saved". This is saying that any registry that is potentially being used for a result value, it will scrub them. We need to handle the cases when the structure is not sent via the register.

TC: What would the user do to avoid the warning?

Josh: That's what I'm trying to see. In C you would initialise the struct to setting it to 0. What's the equivalent of that in Rust and how do we notice you've done that to make sure you don't have to suppress this lint.

Tyler: Is this a stable ABI?

Josh: It is, yes.

Tyler: I thought we should have lang-FCPd it. I couldn't find it.

Tyler: It says the ABI is experimental.

Josh: I thought we stabilised that but apparently we have not.

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

TC: I'm happy to wait for an answer to the question Josh asked on the issue about what the user would do to avoid the warning.

### "stabilize `asm_cfg`" rust#147736

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

TC: This is about allowing attributes on the arguments of an `asm!` invocation. We talked about this a while ago, gave a vibe that of course it should work. Now it comes to us as a stabilization.

Josh: Sounds good. Ship it.

Niko: +1

Tyler: Looks good to me.

Josh: I expect cfg to work everywhere.

Jack: I'm looing at the unresolved questions. There's the operand before template but you can always do that in the future.

TC: I'm looking at the Reference if it needs to specify this. We've been going through the attributes and specifying where they're allowed. We say "the cfg attribute can be used anywhere attributes are allowed". Does this allow an attribute macro to appear in this position?

Josh: As far as I know, this is only covering cfg specifically.

Tyler: If we've created a parallel / consistency in the language, it'd be valuable to preserve that.

TC: We don't document any places where we allow attributes and not a macro.

TC: I'll ask on this and wait for an answer.

### "Add LLVM realtime sanitizer" rust#147935

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

TC: This just came in. Anyone have context?

Josh: Petrochenkov mentioned the lang context is to mark things as blocking or non-blocking.

#[sanitize(realtime = "nonblocking")]

Tyler: It's extending the sanitized attribute

Josh: Instead of `sanitized` it's sanitized with a bunch of attributes.

Tyler: So it's extending an existing feature with a bunch of new options. That sounds reasonable. This could be useful for async took. But a solution that's scoped to the sanitizer is a good place to start.

Josh: Assuming we can confirm `sanitize` itself is not stable yet, we can say this is fine for now and then review in detail when we sanitize.

Tyler: Given that, maybe we should be taking a closer look now. I don't believe we'll take a closer look at all the attributes of sanitise.

Josh: That was my proposal: each individual flag to `sanitize` should be a separate feature-gated option that we'll stabilise individually.

Jack: Is it worth making sure that happens now or put it in the tracking issue?

TC: I'm writing an update that says we don't need to do it now, but it's on our mind before we stabilize it.

Jack: I want to make it clear that until they're ready to move toward stabilisation, they don't need separate flags. We should also make sure that this gets into the tracking issue for sanitize too.

Tomas: Added that comment here: https://github.com/rust-lang/rust/issues/39699#issuecomment-3436585685

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

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

TC: I think we're just picking up checkboxes.

Josh: We have a proposed FCP started. We need lang checkboxes from Niko and Scott.

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

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

TC: The concern is that people might write, e.g., `u32::min as usize`. The original proposal was to push people to use the `as fn()`, but then the type has to be elaborated.

Josh: I remember we weren't super thrilled with having to write out a complicated intermediate type.

TC: We had been hoping from something from libs-api here; I think it was something like `.fn_addr`.

TC: Amanieu is now saying that might take a long time. I made a counter proposal to push people to do the cast through `*const ()`. If you're expecting to have started with an integer, you wouldn't ever cast through a unit pointer here.

Tyler: My issue with that is that it conflates data pointers with code pointers and that turns out to be an important distinction on certain platforms (none of which we're supporting today). I'm more confortable with something that preserves the fact that it's a code pointer before converting it to a usize.

Tyler: Someone cited a platform where it might be possible.

TC: It'd be interesting to know, even on such platforms, whether casting through a data pointer would affect the resulting integer.

Niko: If the concern is writing signatures, is there some intermediate form (e.g. `fn(..)`) that we could use?

Tyler: I was thinking casting as `fn()`.

TC: You need to write out the arguments (or `_`), otherwise it's a non-primitive cast.

Josh: We have a trait we've added for this specifically that has the `.addr` method that would give you exactly what you want here. And what Amanieu said the only issue stabilising it is a question about provenance. And if I understanding it correctly, this use case is actually doing the right thing.

Josh: I'd suggest getting the relevant people together and ship the lint soon please. Rather than passing questions between Libs and Lang.

Josh: Do we have to have a specific thing to recommend here? Or could we just say that we'll provide an ergonomic feature in the future and for now either do it the unergonomic way or allow the lint.

TC: I don't like telling people to expect the lint. We prefer there to be a way to write the code in a way we consider to be ergonomic to avoid the lint in most cases.

Niko: That has been our position. I think the difference here might be the hope that it's temporary.

(Tomas had to drop for another meeting)

TC: Let's invite Amanieu to the meeting next week and see what we need to do to stabilize `fn_addr`.

### "`rustc_const_eval`: respect `target.min_global_align`" rust#142198

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

TC: Let's ask for a Reference PR here. That will likely help to clarify the ask.

(The meeting ended here.)

---

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

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