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

# T-lang meeting agenda

- Meeting date: 2025-11-05

## Attendance

- People: TC, elle, Jack, Niko, Tomas, Eric Holk, Josh, Yosh, Scott

## Meeting roles

- Driver: TC
- Minutes: Tomas Sedovic

## Scheduled meetings

- 2025-11-05: Triage, etc.

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 today (on 2025-11-05) to review the status of RfL project goals.

The meeting agenda: https://hackmd.io/YrqLUjjRQZGfimvv9lj3Bw

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

## Nominated RFCs, PRs, and issues

### "const-eval: fix and re-enable pointer fragment support" rust#148259

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

TC: We approved doing this. After that theemathas found a good case; Ralf reverted the stabilization. And now he's re-proposing it after the fix. I've proposed FCP merge.

Niko: I put in my checkbox. I think our role is to evaluate this from the usability angle and let Ralf handle the nitty-gritty. I think the user experience here hasn't changed much.

TC: What Scott said earlier makes sense to me: if reverting the change would be a breaking change then it's a lang decision unless we've made a specific delegation.

Niko: I think the Types team makes a lot of decisions. I'd like to streamline our role with the opsem team.

TC: I think we need to have that discussion regarding the types team too. You had a nominated item for this we never got to.

Niko: We can have that discussion.

Josh: +1 for the discussion.

### "parser/lexer: bump to Unicode 17, use faster unicode-ident" rust#148321

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

TC: I think adopting a new Unicode version is a lang decision; we should FCP this unless we've previously made a very specific delegation.

Scott: It does hit the "this could be a breaking change if reverted" rule. Might not necessarily be Lang, could be Compiler.

Josh: We're delegating to the combination of Unicode as the standard and the Compiler team implementing this to tell us if there's anything strange here. But other than that, we should just sign off on that. For Lang, someone needs to have a look at the xid-start and xid-continue and possibly update the "confusables" lint.

TC: That to me sounds like a good reason for us to be involved.

TC: On a meta note, this is why it's important for us to keep our queue short. It's not a big deal for us to need to sign off on these things if we're getting to them in a week. It's a big deal if it takes months.

TC: Josh, how do you want to handle this? FCP and file a concern?

Josh: No need for a concern, I'm typing out a comment on the issue. I think we should delegate making this decision to someone in a better position to review unicode.

Scott: Procedurally, anything lint-related is not something we have to have an FCP for. I don't think updating the confusables lint is something we need to FCP.

Josh: Yes.

Niko: I agree with Scott. I do not want to have to nitty gritty review each of the unicode bumps, it doesn't seem like a good use of the lang team's time to look at this unless there's something new.

TC: For the moment, I'll fire an FCP.

Jack: Is the consensus that Lang wants this to be FCPd? What does FCP mean here.

Josh: We should delegate it for the future. In the meantime, unicode is part of the language so we shough sign off since it's a stability issue.

Scott: Because reverting it is a breaking change, it should be FCPd by *someone*. The purpose of the FCP is that it's going to be on This Week in Rust so someone can notice and point out something weird. I'd like for that to not be us.

Jack: Makes sense.

TC: `fcp merge` is fired.

TC: When we do delegations on this, I want to make sure we delegate responsibility for other matters of the lang process (e.g. standards for doing and reviewing crater runs, ensuring the Reference gets updated etc.).

### "Mention `infer_static_outlives_requirements` removal" rfcs#3278

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

TC: This is an old PR from a member of lang-docs proposing to add language to an existing RFC 2093.

Scott: I read this as just "this happened, we've put the notes on top of RFCs before".

TC: I don't think it needs an FCP; just someone on lang to review it.

Niko: I'd suggest an alternative wording, but otherwise it's fine.

Josh: Is this a proposed lint that was removed?

Niko: No. If the thing you wrote is `'static` and not a lifetime requirement, we don't infer that. The RFC originally didn't distinguish that.

Josh: The original RFC would infer any lifetime annotation and we later decided that inferring `'static` to be annotated?

Niko: Yes, we decided to require the static annotation manually.

TC: If you could fill in the history and suggest rewording, one of the rest of us can probably take it from there and get it merged.

Josh: We should reflect reality. Someone filed this three years ago and we never merged it. Plus, this feature seems nice and useful. Why did we decide not to do it?

Scott: I think it was that `'static` is special. We don't infer it in lifetime elision. We've said that it's special enough that maybe that's not what you wanted. I guess this hit the same thing and inferring it could surprise you.

Josh: We probably shouldn't get into all the details in this meeting to do a design. I was expressing that it would be great to happen if someone's enthusiastic.

### "Revert "Do not check privacy for RPITIT."" rust#146470

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

Josh: PResumably this makes it start checking privacy for RPITIT.

TC: This was nominated, but there's no nominating explanation here.

Josh: It's not clear what the ask on us is here. Propose we leave a comment and mention that if they add comment in the next hour, we'll take a look at it today.

TC: This needs an FCP. I agree with asking for better context.

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

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

TC: There's a proposed `fcp merge`.

TC: I said I wanted to see the Reference PR because I was concerned about the specifics of the semantics there. There is now a reference PR: https://github.com/rust-lang/reference/pull/2063

TC: There's a discussion with petrochenkov in the Reference PR.

TC: I've read the back-and-forth of the Reference discussion. It's now clear to me what this is doing. I'll check a box, and that will put it into FCP.

Josh: I think I see the nature of what's wrong in the Reference PR, but it's obvious how it needs to change. It should say it only accepts cfg and cfg_addr.

### "Replace OffsetOf by an actual sum of calls to intrinsic." rust#148151

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

TC: At the bottom cjgillot says:

> There should be no user-facing change because of the `offset_of` manipulation. Maybe some diagnostics, but not more.
> However, there are 2 user-facing changes in this PR that t-lang may want to know:
>
> 1. const-stability of intrinsics now takes allow_internal_unstable into account;
> 2. we get an additional intrinsic with rustc_intrinsic_const_stable_indirect.

Josh: The lang ask for an intrinsic that can be used stably when part of a macro? We're approving the new intrinsic?

TC: I think so.

Scott: I think the const stability part is extra important. We've accidentally stabilized things before. We need to be extra careful with that. Has Ralf replied here? He's been pinged.

Scott: This was a MIR primitive. I think the macro has useful things, but if you do multiple levels of traversal with the macro, it will produce multiple levels of intrinsic. That seems reasonable to me.

Josh: This is const-level indirect but it will stay permanently unstable?

Scott: Yes, it being an intrinsic we expect for it to be unstable forever. The `NullOp` enum now goes back to being an ordinary C-style enum.

TC: So we're adding a new intrinsic and then relying on it in stable code?

Scott: True. It's not that different from the magic macro that we were using that.

Scott will post a comment and trigger an FCP.

### "Guarantee the binary representation of `isize` explicitly" reference#2064

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

(in FCP, with 4 checkboxes already)

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

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

Needs checkbox from Scott, as well as more libs checkboxes.

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

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

Josh proposed FCP, needs checkboxes.

Josh: There's a hard limit on the PE format on Windows on section alignment. This is a restriction that let us to avoid doing that. We can always lift it if there's a new format without that limit.

Scott: When do we want to check this? Do we want to handle it post mono vs. checking the alignment attribute?

Scott: This is an implementation-specific limit. Do we check it at align attribute time or when someone uses the type?

TC: Do you expect this needs to be documented in the Reference?

Scott: If we're not checking the macro, we're checking the types that you actually use, then it depends on what it means to use a type. That's complicated with const. It would be observable -- you could write code with big alignment and never use it.

TC: Could you write this question on the issue and also mention that we'll need a Reference PR?

TC: Procedurally, I'm becoming hesitant to check a box without a Reference PR. It's not about the PR being there; it's about the contents of that PR being part of how we understand the change to the language.

Scott: I did leave a comment about this on 2025-09-18: https://github.com/rust-lang/rust/pull/142638#issuecomment-3309677099

Scott: 8k seems high enough that I don't think why people would be setting the alignment that high. So it's okay to fail statically. If it were much lower, we'd have to add more logic there.

### "Tracking Issue for `darwin_objc`" rust#145496

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

TC: Tyler volunteered to champion this. This is for our awareness the proposal for a lang experiment. Does anyone else have context?

Josh: It's a proposed lang experiment for integrating with ObjectiveC. I think there's enough information in the proposed issue to for us to say whether we want to go ahead with the experient. Tyler is championing it I think we should go ahead with it.

Niko: Technically speaking experiments don't have to be approved. It's more: if you have concerns, you should talk to Tyler.

Josh: It should be nominated so people can say whether they have concerns or objections. But we can now unnominate this.

Niko: The goal of the nomination is that everyone knows it's happening. Now we know.

TC: To confirm procedurally: We treat them as accepted as soon as we have a champion and then we nominate it to build context among the team.

### "Tracking Issue for Reborrow trait lang experiment" rust#145612

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

TC: Same deal. This is an experiment, nominated for visibility. Tyler is the champion.

## Nominated RFCs, PRs, and issues

People: TC, Niko, Josh, Jack, Yosh, elle, Tomas, Urgau, Eric Holk

### "compiler and language documentation disagree on lifetime extension for array expressions" rust#146092

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

TC: There's a note in the Reference now that calls this out and links to this issue.

TC: When we're doing specification work we find areas where the compiler and the reference disagree. And then we'll have to raise them to figure out which is right. This is one of those items.

Josh: There's a mismatch, the question is: which one is correct?

TC: The Reference admonition about this is in:

https://doc.rust-lang.org/1.91.0/reference/destructors.html?highlight=destructo#r-destructors.scope.lifetime-extension.exprs

Niko: I'd expect it to be extended.

Josh: I would as well.

Niko: I'd expect the following kinds of expressions to all be equivalent in terms of the lifetimes of the values involved (where `X` stands in for some expression):

let tmp = TupleStruct { a: X, b: X };
let tmp = (X, X);
let tmp = [X, X];
let tmp = [X; 2]; // <-- this one is different

Niko: The original intention of the rules was any reference to a temporary that will be stored in a value will have extended lifetime.

Josh: Any objections to make the lifetime extending and posting a comment?

TC: I agree with Niko, this should be extending.

Josh: I will post the comment.

Jack: In an ideal world, Lang would say that the Reference is what we want. And the compiler would implement what's in the Referenec, does there need to be a second FCP?

TC: As an ideal far future, the lang team could be responsible for the Reference and that's it. We define the language, FCP Reference changes, and pretty much everything else is a compiler delegation. We're not there today. Today we become responsible for e.g. accidental stabilizations. We have a broader responsibility and end up needing to navigate how we fix mistakes. That's why we have the process of lang FCPing PRs rather than tracking issues. We're responsible for what ends up shipping in a rustc release; those things end up being de-facto language behavior.

### "Add a new lint `UNCONSTRUCTABLE_PUB_STRUCT` to detect unconstructable public structs" rust#146440

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

Josh: I don't think thisis quite as trivial. If you have an impl of `Default` or a new constructor that's callable publicly, right?

Niko: Correct. Did this identify any existing instances or is it jus theoretical?

Scott: This seems to say it has to look at every trait the type is implementing. Souns like a very complicated check.

Josh: It may be taking advantage of the existing "deadness" checking. It's just showing it's potentially dead if there's no way to get one from the crate. If you have a single item in the crate that can give you a value of the struct, reference of the struct etc. that should work. This should only fire if you have a public struct with private fields and no reference in the rest of the code.

Scott: If I make a transparent struct with a slice as its only field that's not constructable. But you can have that behind a reference.

Josh: It's not a public field though. The way they're doing that is: "you can't construct it externally and internally you have no invocation of the constructor"

Scott: We have things that we don't call constructing for (e.g. unsave + transmute)

Josh: I think they're doing this by "do you ever create one of these anywhere in your crate"?

Josh: Proposal: in principle this potentially make sense. But there are corner cases for building things via e.g. transmute and add tests that make sure that suppresses this lint.

TC: The lint is marked allow-by-default. Does that change the analysis?

Josh: Somewhat, it often signals it's a half-baked lint.

Scott: To me allow-by-default in rustc should be a warn-by-default in Clippy.

Josh: Before we consider making this warn-by-default I'd love to see a run over crates.io (mark it deny by thedault and run by crater run).

TC: I don't think all our allow-by-default lints should be warn-by-default clippy lints; I don't think we're expressing all those things are necessarily bad. They might just have particular utility to some people or circumstances.

Scott: The only case I can come up with is where we're using a lint as a language marker. To add a lint to an `_arm` to make sure it's reachable. We use it as an opt-int to scope a particular place. The rest are things no one's done something useful for yet. E.g. `unused_results` people always ask for and then often don't turn them on when they find out they exist.

Scott: If we had a lint group that's "pedantic about semver breakage", libraries could add them and then we could extend them.

Niko: I agree with what you said. But I don't think this is catching real bugs. I buy TC's case but for most of these cases there should be a lint group. This brings us back to some variation on a profile. It's not really about the individual lints.

TC: Agreed I see this in the context of profiles, and I agree that lint groups would improve discoverability. At the same time, our lint docs are good, which one would think would help discoverability:

https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html

Josh: I agree with Niko's point to make sure this is catching real bugs. We want to make sure this doesn't have a wild amounts of positives for corner cases (dynamically sized, repr_transparent, etc.) and once you've done that we'd like to see the results of a crater run with this lint set to deny.

TC: I'd ask more in terms of motivation. If this were well-motivated, maybe we'd be OK with more.

### "Add lint about redefining runtime symbols" rust#146505

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

TC: I made a proposal for renaming it (and an alternate one), Urgau adapted my rename (thi first one). I proposed `redefining_runtime_symbols` (and `redefined_runtime_symbols`).

Josh: That seems reasonable. This is a case where if you're doing this, people may be doing this legitimately. And if they do, there's no way around this other than allowing the lint. Anyone doing this should be asked to allow the list. I think it's legitimate, I just want to flag that the only recourse people have is to allow the lint.

Josh: If not for peopple reporting this, then I'd have been surprised to see this triggered by default. But apparently people have a no_mangle C function called `read` or `open` and that conflicts with libc.

Scott: Knowing the list of what these things are is interesting.

Josh: I don't think we can ever make this more than a lint. The exact list of the names rustc uses is not an API.

Scott: 100% agree it should be a lint. I think it might be worth deny by default?

Josh: I wouldn't go that far. 9/10 people will hit this lint and realise they should change the name of the function. 1/10 will say "yes, that's what I'm trying to do". If you're already writing no_mangle, you're already trying to export a function with a C symbol name.

Josh: If had a function that matches the name but not the expected signature the function, that I would deny by default.

Scott: Can we move this later in the compilation process somehow? 100% agreed weird signatures is particularly the problem. Can we at some point in rustc look at all the things that std has `extern fn`d and your crate has `extern fn`d and blow up there?

Josh: If we can detect these functions by standard library using rmeta that would be nice. But some of these are used by dlopen, dlsym, other are used literally by opening by name.

TC: You could also be writing a `no_std` crate (e.g. using Rust in the kernel) so the list is relevant to some but not all scenarios.

Scott: Which hits the "It'd be really nice if we could see all the crates you're linking".

Josh: We could make sure you don't get the warnings from std if you're no_std.

Scott: Yes.

TC: I see it as important to the statement of what Rust is that you can use it in kernels -- that it's a C competitor in that sense. If it's not carving out `no_std` or certain that it's detecting UB, I wouldn't want to do these lints as deny-by-default, as I don't want to suggest "Rust isn't the language for you if you want to do this kind of work".

Urgau: `no_std` crates can be imported in std crates, we would have to look at dependencies of std crates to know if we should lint on a dependency, that's tricky

Josh: I'm wondering if it make sense to allow the lint in the freestanding/standalone context.

Scott: I was looking for the list of things we're going to call and that you better not call by the same name. Those could be deny-by-open. But things like `fopen` wouldn't make sense to deny.

Scott: This is a great usecase for crate-level allows. The number of crates that do this is going to be quite small.

Josh: I suggested three potential improvements: around deny-by-default, suppressing it when std is not being linked and allow-by-default for standalone cases.

Scott: TC, I'd suggest posting your point about ensuring that it's clear Rust is a good language for this kind of work. I thought that was a good point.

TC: I'll write it up.

Urgau: Regarding suppressing the lint when not linking std I wrote in the zulip discussion that that's a bit tricky. We'd have to emit a lint in a future crate about something that a dependency crate did. Could be done but it's a bit weird.

TC: That is the situation though, right? It's the interaction between the crates that will cause the undefined behavior.

Urgau: That's a good point.

Urgau: Allowing it in standalone target makes sense.

Josh: What are the chances of detecting a different signature?

Urgau: Depends if we hardcode it or not. If it's a small list the lint is wired into, that's easy.

Josh: I expect this to be hardcoded.

Urgau: I don't think it'd be difficult. But the compiler would have to handle all the architectures.

Josh: And targets. I can imagine some unusual architectures where these would vary easily.

Scott: We have a list of the core documentation of things that have to exist with the expected signature. So those have to be the same, no platform-specific weirdness allowed.

Josh: I think it's worth a try. Having some quirky false positives is not the end of the world. We could refine that. And have a message that's saying what we're encouraging people to do the right thing not to stop them from doing something clever.

TC: The more we can exactly prevent undefined behavior, the better. And if do that, do we even want the warn case?

Josh: We may still want the warn cases for things like `open` where the name is so generic, because people can make that mistake by accident. If we get to a point that our deny catches everything, then we can drop it.

Scott: Often we don't even deny UB, but these are compile-time UB we want to be extra strong about those.

Urgau: So you want a second lint that's deny-by-default that detects a mismatched signature.

Josh: Yes for mismatched signatures deny-by-default. If you define the name compatibly with a signature that might work, we want to warn to catch these and see what they're doing and help them to do it right.

TC: What's our dependency tree for FCP here?

Josh: I think we can FCP this and if it turns out what we asked for isn't possible we should block this FCP.

Josh: The deny by default we don't have to check the environment for.

TC: So on the warn by default one what are we asking for?

Josh: we ask for it to be suppressed by default if you're not linking std. We check if we're freestanding.

TC: Then I agree we should not propose FCP to allow Urgau to try this and then bring it up then.

*We'll un-nominate and Urgau will re-nominate once they've tried to make these changes*

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

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

TC: We signaled this is the direction we wanted to go. Someone brought up the PR. I proposed `fcp merged`. Waiting for at least one more box.

Scott: Why is it not fine to just move the leading binding out of the `if`.

Josh: What if you have `if else` and you don't want the scope to be the whole function but rather just the body of the if? You could always use a separate braced block but that's clunky and cumbersome. This lint is only trying to catch cases for using `if let` where you should be using `let`.

Josh: In Rust with shadowing the standard approach is multiple `let x = ...`. Given that, it's not uncomon to have an if-let and put the binding there. We encourage shadowing.

TC: Another case is you destructure something, then you destructure on something inside; it allows you to flatten the structure.

Scott: You can have irrefutable patterns in the middle of that if-let chain. We only lint about the beginning and the end. For the beginning, the arguments about drop types makes sense. If you have an irrefutable pattern at the end of the chain I think we should move it into the block.

TC: Niko also mentioned how `if let` in Rust is kind of a weird way (in a good sense) to write `let in` in languages like Haskell.

Scott: It says if there multiple irrefutable bindings it doesn't lint?

TC: Yes. The only time we lint is when there's exactly one thing and it's irrefutable.

Scott: It's not obvious to me that's consistent.

Josh: Right now I think it's reasonable to say we don't want to lint on multiple cases.

TC: Originally we wanted to drop this lint. Then someone brought up what Swift does and that convinced Tyler on narrowing it. I think we should go further still, but we landed on this partial compromise.

Scott: I think I need to think about the trailing case.

TC: Here was one case we had observed on the original issue, not about trailing ones specifically.

if let x = op_one()
&& check_one(x)
&& let y = op_two(x)
&& check_two(y)
&& let z = op_three(y)
&& check_three(z)
{
    ..
}

Scott: you've convinced me that the leading irrefutable patterns are useful. But look at the trailing irrefutable patterns:

if let x = op_one()
    && check_one(x)
    && let y = op_two(x)
    && check_two(y)
    && let z = op_three(y)
    && check_three(z)
    && let w = x * 2
{
    ..
}

why do that instead of this?

if let x = op_one()
    && check_one(x)
    && let y = op_two(x)
    && check_two(y)
    && let z = op_three(y)
    && check_three(z)
{
    let w = x * 2
    ..
}

TC: I agree, but maybe you have a good reason to write it the first way, e.g. matching stylistically a particular pattern you're using over and over again. This falls short of warn-by-default for me.

Josh: I feel like this is unlikely to catch bugs. It will catch style matters where Clippy might be appropriate. I do think there's room in rustc for some stylistic lints. I just don't think this passes that threshold.

Josh: Scott, if you'd like some time to think about it, let's do that async and we can move on?

Scott: Sounds good to me.

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

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

Josh: Do we have any other lints where we're trying to catch semantic bugs ??

Josh: This is catching a legitimate bug in interaction with cargo. I think this should be an allow-by-default lint that cargo changes to warn-by-default lint when compiling the build script.

Josh: When you're building your build script, Cargo exports several env vars (e.g. CARGO_CONFIG_TARGET_FAMILY). A multi-valued thing taht's comma separated. Calling `==` on it is incorrect. This is trying to catch it. If we had custom lints, this would go into a custom lint Cargo would supply to built lints. We don't have that, but then Cargo can change this lint to warn-by-default when build.rs

TC: Is this only running on `build.rs` right now?

Josh: It's currently warn-by-default but it shouldn't run on arbitrary code. I propose we allow-by-default and Cargo warns on it in build-rs.

TC: Want to make a proposal for a better name for this?

Josh: `cargo_cfg_target_family_incorrect_comparisons`?

TC: Maybe this is a good place to use the word "suspicious". We don't even know if it's wrong.

Josh: `suspicious_cargo_cfg_target_family_comparisons`.

Scott: There is the possibility that stable MIR could be a way to do this. If it's doing data flow it shouldn't be looking at the AST. It may not be practical now.

Josh: We talked about multiple ways that to write macros. Having a way to register lint to accept AST would work.

Scott: I don't think it should be AST if it's doing data flow.

Josh: You're right.

Scott: But maybe that's not practical right now.

### "Warn against calls which mutates an interior mutable `const`-item" rust#148407

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

TC: I prereviewed it and made a name proposal which Urgau adopted. I proposed an FCP, then camsteffen proposed a different name.

TC: We talked about something kind of like this before -- to warn on const items that were interior mutable. I had concerns about doing that. That resulted in Urgau making this proposal. It warns on a reference being taken in cases where we know a mutation will likely occur.

Niko: I prefer `const_item_interior_mutations`.

TC: I'm good with that too. Any concerns?

Scott: I'd propose we don't worry too much about the name in terms of the FCP.

TC: I think the name is part of what we're proposing. We're trying, in terms of processs, to be clear what it is the lang team agreeing to exactly.

### "Extend format_args implicit arguments to allow field access" rfcs#3626

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

Josh: This is a preliminary vibe check. The single biggest extensions people ask for is adding dotted field accesses (e.g. `format!("var.another_field")`). People complanied about that supporting `.await`. I removed that and renominated.

Scott: I 100% agree that field access is the thing that actually matters here. The only piece I'd be tempted to carve out to say this is explicitly for field projections without deref. If we say "you can use format! in const but then there's a deref to involve"

Josh: I don't think it's a problem but we should mention this in the RFC.

Scott: If it's deref, should it be going through derefs? How often are these boxes vs. something else? All the `Display` cases don't need `Deref`.

Josh: A lot of usecases do want Deref. It's common to have a data structure that has an internal ??

TC: Related to this, I'd highlight my comment at the bottom:

https://github.com/rust-lang/rfcs/pull/3626#issuecomment-3219068939

TC: Since it's running drop and deref, we need to think carefully about the desugaring. There's also a question about behavior when we step on keywords that I identified.

Niko: I want to push back a bit on Scott's concern. We should think of this as a desugaring. People will want this to be the same as `format!("{x}", x=a.b)`. If something subtle makes that not behave the same, that would be confusing. Format is already embedding expressions.

Scott: That's a fair point. Maybe we should just explicitly flag that in the discussion. That said, I don't know how that doesn't apply on `.await` too.

Josh: I had `.await` in there, then removed it because of a lot of people had objections. So I removed the contentious parts. TC, would you be up for an async conversation to work throught the exact semantics?

TC: And specifying the desugaring carefully would make it easier to add things like `.await` later too; it would make people feel more comfortable with exactly what it means.

Scott: My compiler wants to find a well-scoped construct here so we don't "boil the frog". But fields are so obvious, so let's do those.

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

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

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

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