---
title: Triage meeting 2024-03-20
tags: ["T-lang", "triage-meeting", "minutes"]
date: 2024-03-20
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings
url: https://hackmd.io/7r0i-EWyR8yO6po2LnS2rA
---

# T-lang meeting agenda

- Meeting date: 2024-03-20

## Attendance

- People: TC, Connor Horman, Urgau, Santiago, CE, Ben Kimock, Mara Bos, Nadri, pnkfelix, tmandry, eholk, Armanieu, scottmcm

## Meeting roles

- Minutes, driver: TC

## Scheduled meetings

- 2024-03-20: "Extended triage meeting 2024-03-20" [#257](https://github.com/rust-lang/lang-team/issues/257)

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 our design meetings start half an hour earlier than in the past. For Europeans, note that for all of this month, all of our meetings start an hour earlier where you are.

### RTN

TC: We had a call 2024-03-04 to discuss the syntax of RTN. There was no explicit consensus from that meeting, but the general mood was that there were two axes along which we might find consensus:

- Axis 1: Whether to say `()` or `(..)` as sugar for `::Output`.
- Axis 2: Whether and how to distinguish the type namespace from the value namespace.

The next steps, per NM, are:

- Author the RFC and kick-start public conversation.
- Revise write-up focusing on the final decision space (the axes you mentioned above, for example).
- ...and highlight the shared values that seemed to be popping up in people's write-ups.
- Niko is mildly curious about gathering up some data -- e.g., doing some interviewing, I'm doing some thinking about this.

## Rust 2024 review

Project board: https://github.com/orgs/rust-lang/projects/43/views/5

### Tracking Issue for Lifetime Capture Rules 2024 (RFC 3498) #117587

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

TC: We accepted the RFC and the implementation has landed for Rust 2024. We do need to stabilize some way of expressing precise capturing. That probably means stabilizing TAIT. We're starting with stabilizing ATPIT.

TC: That stabilization now on track. We're finishing some final items and are hopeful this may go into FCP soon.

### Reserve gen keyword in 2024 edition for Iterator generators #3513

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

TC: This RFC is now in FCP.

### Tracking issue for promoting `!` to a type (RFC 1216) #35121

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

TC: We discussed this in the design meeting on 2024-03-13. We then agreed to meet with Waffle on Tuesday to follow up. We stood him up though.

TC: Separately, though, Waffle and I have been discussing some steps in the path forward. He's making it possible to test the effect of various options discussed in the playground, e.g.:

#![allow(internal_features)]
#![feature(rustc_attrs)]
#![rustc_never_type_mode = "no_fallback"]

fn main() {
    match () {
        _ => return,
    };
    //~^ ERROR type annotations needed
    //~| NOTE cannot infer type
}

TC: He's also working to do crater runs for some of these options. These steps seem likely to be useful input to the follow on discussions that we'll have.

## Nominated RFCs, PRs, and issues (meeting 1)

### "Arbitrary self types v2" rfcs#3519

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

TC: We had a design meeting about this on 2024-02-28. The identified next step was to write up a list of the available options. That document is here:

https://hackmd.io/eXfrzrR7T1-3HVh6w5JMqA

The general mood in the meeting tended in the direction of doing the simpler thing for now (supporting only newtype wrappers) and saving space by giving a hard error on resolution ambiguity, but there were various concerns.

TC: This issue also relates to the subject of the 2024-03-06 RfL meeting on `KernelArc`:

https://hackmd.io/OCz8EfzrRXeogXEDcOrL2w

TC: The feeling in that meeting was that the `newtype` approach would probably work for `RfL` along with the `derive(SmartPointer)` approach that CE had proposed.

TC: I'm writing up a document to bring together the situation and the various views. So I may reach out to you to set up a call to be sure your views and concerns are faithfully represented.

### "Tracking issue: deref patterns" rust#87121

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

TC: Nadri has restarted work on deref patterns. We have a project repo for this:

https://github.com/rust-lang/project-deref-patterns

And we have an issue for the initiative / project group:

https://github.com/rust-lang/lang-team/issues/88

Apparently cramertj was the liaison for this. Nadri is looking for a new liaison.

TC: I've been working with Nadri on various things recently, so I'd be happy to take this (with the T-lang-op hat on) if this would be useful.

tmandry: Be good if you'd take this on.

pnkfelix: +1.

CE: We first want to get this all working.

*Consensus*: TC will take this one.

### "Add `REDUNDANT_LIFETIMES` lint to detect lifetimes which are semantically redundant" rust#118391

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

TC: We discussed this on 2023-12-13 and made a request for the lint to be broken into separate lints for *unnecessary* and *unused* lifetimes.

TC: This was done, and in the 2023-12-20 meeting, we discussed and the feeling was that we should do this, resulting in a proposal for FCP merge.

TC: We've been holding people out on this pending one last checkbox, so lcnr has renominated this for us.

pnkfelix: I've checked off.

*Consensus*: Now in FCP.

### "Stop skewing inference in ?'s desugaring" rust#122412

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

TC: Waffle nominates this breaking change for us:

> This changes `expr?`'s desugaring like so (simplified, see code for more info):
>

// old
match expr {
    Ok(val) => val,
    Err(err) => return Err(err),
}

// new
match expr {
    Ok(val) => val,
    Err(err) => core::convert::absurd(return Err(err)),
}

// core::convert
pub const fn absurd<T>(x: !) -> T { x }

This prevents `!` from the `return` from skewing inference:

// previously: ok (never type spontaneous decay skews inference, `T = ()`)
// with this pr: can't infer the type for `T`
Err(())?;

TC: This seems a clear case of testing our RFC 1122 rules of whether we can in fact make certain changes to inference behavior.

TC: What do we think?

scottmcm: Maybe rather than changing the desugaring is an indication that we should just go ahead and change `return` to do this.

scottmcm: It'd make me happy if we could do something more general so as to keep the desugaring of `?`.

tmandry: I agree with scottmcm's inclinations. It'd be unfortunate to have to special-case `?` in this way. So making `return` evaluate to an unbound type variable makes sense to me.

pnkfelix: Could we go ahead with the `?` change anyway rather than blocking on the hypothetical?

tmandry: I'm probably worried that we end up having to live with this special case forever.

TC: Part of the context here is that this is the smallest possible breaking change that moves us toward what we probably want to do to enable the never type.

tmandry: Part of me wants to kick this to the types team, but maybe they'd have the same answer.

scottmcm: This is a very subtle breaking change. I don't disagree that we could do this.

pnkfelix: It's odd to hesitate on changing this but support changing `return` generally.

scottmcm: This seems to raise the same questions for me as the larger changes, e.g. with respect to subtle breakage. This feels a bit like a hack. If we already have a project looking at changing how `!` works, maybe we should do the larger change.

tmandry: If this is an incremental change as part of that larger project, then this makes sense to me.

TC: That is the idea.

scottmcm: Maybe I can leave a comment asking about changing the behavior of `return` generally.

pnkfelix: Based on https://github.com/rust-lang/rust/issues/51125, I am under the impression that changing `?` is meant to *address* known footguns with unsafe code.

pnkfelix: I feel like we're in the state we're in because of earlier decisions. So I'm skeptical that blocking makes sense here.

*Consensus*: Let's wait for the crater run and ask Waffle about the possible change to `return`, and when we reapproach this, we'll pull in those examples that pnkfelix linked.

tmandry: I definitely want to encourage this work. I want the never type to happen.

scottmcm: +1.

### "recursively evaluate the constants in everything that is 'mentioned'" rust#122568

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

TC: We had an in-progress proposed FCP on this issue, which is a blocker to inline `const`:

"Report monomorphization time errors in dead code, too" - #112879

https://github.com/rust-lang/rust/pull/112879

This proposed FCP had 4 boxes checked, but it never actually completed due to a concern we filed over a regression in incremental build times.

RalfJ analyzed that regression, so we now understand the cause of it:

https://github.com/rust-lang/rust/pull/112879#issuecomment-1987198783

This resulted in the present PR that solves the issue blocking inline `const` with a much more modest (and expected) performance regression.

TC: Since the only thing that stopped the #112879 FCP is a concern over performance, and this solves it, do we want to treat the question in #112879 as having been decided, or do we want to start a new FCP on this PR?

TC: We could also decide that this question was fully decided by RFC 3477:

https://rust-lang.github.io/rfcs/3477-cargo-check-lang-policy.html

tmandry: As I recall, the reason we had the FCP was due to the perf regression. What's the case here?

TC: It's on the order of magnitude of 3% worst case, but there are improvements also.

scottmcm: And there are no wall time check regressions.

https://perf.rust-lang.org/compare.html?start=1eb882ef6d8630109c7b7ea5dcc5ef1c504bb976&end=02d1d38e5c2ce4f8986df3c3be1eea8e29d6199d&stat=wall-time&nonRelevant=true

scottmcm: Concretely, I'd say we're fine with this going in without FCP, then we start FCP to stabilize inline const.

tmandry: +1 on that.

scottmcm: We actually already have an in-progress FCP on that.

*Consensus*: We're OK with this one going in without FCP on the basis of the RFC.

scottmcm: inline_const pFCP: https://github.com/rust-lang/rust/pull/104087

### "Const-eval errors in dead functions are optimization-dependent" rust#107503

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

TC: We've been treating optimization-dependent errors as a blocker for inline `const`. We had thought the last of these was addressed by:

https://github.com/rust-lang/rust/pull/122568

TC: However, it's recently been observed that the cross-crate inlining heuristic also exhibits optimization-dependent behavior:

> The optimization level also influences which items are monomorphization roots. In the example below, with optimization enabled, there are no mono items and so no const eval errors:
>

struct Zst<T>(T);

impl<T> Zst<T> {
    const ASSERT: () = if std::mem::size_of::<T>() != 0 {
        panic!();
    };
}

fn f<T>() {
    Zst::<T>::ASSERT;
}

pub fn g() {
    f::<u32>()
}

https://github.com/rust-lang/rust/issues/107503#issuecomment-2008088416

(There is further analysis that follows that comment that is worth reading.)

TC: Do we have thoughts on what next step to take on this?

tmandry: This seems like a bug.

Ben Kimock: Yes.

tmandry: I propose consensus that we fix this bug.

Ben Kimock: Items that have the inline attribute are lazily monomorphized. So if they're never used, they're never included.

Ben Kimock: There's a lot of entanglement in the compiler with these different layers. It's exciting that RalfJ has stepped up to start untangling this.

scottmcm: Certainly anything that's about optimized MIR is a place where I get concerned.

Ben Kimock: What RalfJ is proposing is separating those things.

TC: Do we want to proceed on stabilizing inline const and fix this in parallel or block inline const on this?

tmandry: It does seem like the other things we said we wanted to fix.

scottmcm: This was the original concern we filed in 2023:

<https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210>

Do we feel those have been sufficiently addressed?

scottmcm: Personally, I feel if we get the fix for the first problem, I'd be happy to move forward on inline const at least.

tmandry: My sense is that this is optimization-dependent.

scottmcm: Right, there's a heuristic for whether things get marked inline.

tmandry: That definely concerns me. It seems to fall under the category of things we should definitely fix. But I'm hearing some hesistance for blocking this from moving forward.

scottmcm: At least for me, there's an arguable distinction here. Since it's dead code, that maybe seems less bad. What we cared about was when you had a const that you really were using.

tmandry: Right, the main concern with optimization-dependent errors was that code that compiled one day would stop compiling on another day. Other than directly due to fixing this bug, that wouldn't be the case here.

tmandry: So this seems like a bad bug, but maybe this doesn't need to be a blocker to inline const.

*Consensus*: This seems like a bug that we should fix without FCP.

*Proposed consensus for wider discussion with more attendance*: As soon as Ralf's change is merged in, we're OK with moving forward with inline const.

(The first meeting ended here.)

---

## Nominated RFCs, PRs, and issues (meeting 2)

- People: TC, tmandry, eholk, Nadri, scottmcm, CE, fmease, Urgau, RalfJ

### "Tracking issue for RFC 2102, "Unnamed fields of struct and union type"" rust#49804

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

TC: fmease nominates this for us:

> Nominating Ralf's comment for T-lang discussion. Context for T-lang: There's currently active compiler dev going on to implement this feature (several merged and open PRs by multiple contributors). I don't want them to continue working on it if it gets thrown out in the end.

TC: That comment from RalfJ is:

> Unresolved question: what should `derive` macros do here? This applies both to the built-in ones and user-defined ones. It seems like they all need major overhaul to support types like this. And it is pretty inevitable that people _will_ ask for `derive` to be supported on these types, even if the MVP does not support them.
>
> OTOH I assume many of them don't support unions to begin with, and these unnamed fields only really make sense when there are unions involved I think?
>
> The RFC also explicitly lists anonymous types as a rejected alternative, and yet the implementation that recently began for this RFC does introduce anonymous ADTs to the compiler. Though maybe if it is impossible to write an expression of these types they are less problematic? That said I assume in the internal compiler IRs such expressions will exist -- the unnamed fields are getting an internal name and field accesses are desugared to use those names.
>
> It's that kind of issue that makes me think that adding a new form of unnamed types to Rust (on top of closures/coroutines) is a mistake. The RFC was accepted 6 years ago, our approach to language design and evolution changed since then. I think we need to ensure that this is even still something we want to do in this form.

TC: What do we think?

CE: I'm not a fan of the implementation. I don't think the RFC thought this through. I'd be happy if we were to start from scratch here.

fmease: This could have an ecosystem impact. That's part of what RalfJ's concern probably was.

Nadri: This is an older RFC. We need to recheck whether a language feature of this complexity is still worth it for perhaps a small use case.

CE/fmease: +1.

scottmcm: I like the point about the derive macros. If everyone who uses this complains to their upstreams, then it's hard for me to see that it's worth it.

tmandry: There seem to be two alternatives on the table here. One is generating named types. And the other is using anonymous types in the type.

Nadri: My understanding is that anonymous types don't even solve the problem here. They're not required or useful.

CE: Do we want to de-RFC this?

tmandry: I hesistate as we probably want more context here.

CE: I feel like this is floating without anyone pushing this forward. It's just kind of hanging out there.

scottmcm: I like the idea tmandry raised of using rfcbot as a feedback mechanism here. I'd be happy to see a de-RFC here, e.g. from the compiler people.

Nadri: There seem to be a lot of language problems here. It'd be good to have a design meeting about the problem that we're trying to solve here.

Nadri: it would make sense for the lang team to say "we're interested in solving this problem, but this proposed solution may not make sense in today's rust; let's reevaluate"

RalfJ: It seems worth asking what the current thinking is. It's probably not worth doing this just because C does it.

RalfJ: The libc people are now asking for it, so a case could be made. But it should be made based on Rust today.

tmandry: Looking at the RFC, there are aspects of this that I would like to exist in some form.

fmease: Where should the burden of proof fall here?

tmandry: It would be helpful if someone could summarize the arguments against. Maybe we could use the rfcbot poll feature.

RalfJ: There's a connection with C++ inheritance here.

Oli: People are trying to add that also.

CE: I'll try to summarize the concerns here.

*Consensus*: We have concerns about this. CE will write those out, then we could kick off an rfcbot poll. We'd like to know more about the motivation for this in terms of current Rust. Perhaps this would be good for a design meeting.

### "regression: encountered mutable pointer in final value when "outer scope" rule applies in const/static with interior mutability" rust#121610

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

TC: We discussed this in the meeting on 2024-03-06 but were unclear about the situation, particularly as it pertained to a decision we had earlier made here:

https://github.com/rust-lang/rust/pull/119044

TC: RalfJ has now written up a document for us about this:

https://hackmd.io/3fj1WHGIT7-l8hRHxcKS8A

TC: There is some additional background on promotion and the related problems here:

https://github.com/rust-lang/rfcs/blob/master/text/3027-infallible-promotion.md

RalfJ: We evaluate the constant then put it into the global store. We have to decide what the mutability should be. When it's a constant, not a static, we'd like these all to be completely immutable. We hope to stabilize `const_mut_ref` soon. We want to ensure these can't make their way into constants.

RalfJ: Everything about this worked great in crater except for one regression.

RalfJ: There's a mismatch between how various parts of the compiler look at this.

tmandry: I'm trying to get a sense of the cost of doing value-based reasoning in both cases. Could we have different rules for `const`?

RalfJ: It doesn't work because we do promotion everywhere.

tmandry: And the reason that opsem doesn't want value-based reasoning is that it would make it more difficult to do runtime reasoning like miri does?

RalfJ: There are several reasons. It's bad if we have to only sometimes do value-based reasoning. We should do it everywhere or nowhere. Secondly, we like separating the permissions on the pointer from permissions on the value.

RalfJ: The problem is that even breaking these six crates only solves the less annoying part of the issue. The real problem is the promotion.

Oli: Could we just remove promotion in general over an edition and require people to use inline const? We can in fact run borrow checking twice; we did this for NLL. And the lint we emit would not have to be perfect. Most of the errors here would be quite obvious.

scottmcm: It'd be an interesting experiment. Maybe it's not no promotion at all, but maybe we cut it back to e.g. primitive types.

Oli: We could break promotion over an edition to be entirely type-based reasoning.

RalfJ: There's still the question of what to do about this regression.

TC: We already backported a fix here to turn this into a future-incompat.

- Tracking issue: https://github.com/rust-lang/rust/issues/122153
- The downgrade: https://github.com/rust-lang/rust/pull/122204
- The beta-backport: https://github.com/rust-lang/rust/pull/122524

tmandry: I'd propose we go with that for an edition or two.

RalfJ: The challenge is that I don't want to stabilize `const_mut_ref` until we do something better here.

Oli: We could turn it into a hard error as soon as there's a mutable reference in the constant.

tmandry: I'm also OK with the mut reference hack if that would be temporary.

scottmcm: It would be nice if, on the basis of data, we could do the simpler thing.

RalfJ: It sounds like, in terms of next steps, we should do a crater run for converting to entirely type-based reasoning.

scottmcm: One thing that comes to mind is that if this is about the tail expression bit, there are people looking at that tail expression rule. Maybe it's worth feeding to them the fact that this is awkward. Maybe that could be fit into the other changes being proposed for Rust 2024.

RalfJ: I had thought about that briefly and I don't think that helps. This rule takes effect before we have type information.

TC: To summarize next steps:

- Do a crater run for:
- Converting to type-based reasoning across the board for both tail expressions and promoteds (with some caveats) and fixing the standard library to still build.
- PR that partially implemented something like that: https://github.com/rust-lang/rust/pull/121786 (that only does it for tail exprs, still needed for promotion)
- Look at those results and consider whether we could do that, since that would be the best thing to do.
- Consider whether we could use the edition somehow to enable this.
- Consider putting together a design meeting here.

RalfJ: The vibe here seems more in favor of breaking that crate than adding a special exception with value-based reasoning.

tmandry/scottmcm: +1.

RalfJ: I'm torn between having two ugly things that are consistent versus having two less ugly but inconsistent things.

---

(Post-meeting notes:)

Follow-on discussion of this is here:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Value-based.20interior.20mutability.20in.20promotion.20.2F.20tail.20expr

An older related issue:

"const checking: do not do value-based reasoning for interior mutability" - #121786

https://github.com/rust-lang/rust/pull/121786

An example of promotion introducing UB as discussed above:

https://github.com/rust-lang/unsafe-code-guidelines/issues/493

### "restrict promotion of `const fn` calls" rust#121557

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

TC: RalfJ nominates this for us:

> This PR aims to finally achieve the goal of the [infallible promotion RFC](https://rust-lang.github.io/rfcs/3027-infallible-promotion.html). Originally the RFC said we should never promote operations that may panic or otherwise fail. We almost managed to do that, with one exception:
>

const fn my_function() -> i32 { panic!() }

const C: &'static i32 = {
  let x = &my_function();
  x
};

>
> This would compile because we are promoting all calls to `const fn` in `const`/`static initializers. I tried a while ago to forbid this, which [found 2 regressions](https://github.com/rust-lang/rust/pull/80243#issuecomment-751885520). The regressed code didn't really have great alternatives to switch to (that would require inline consts), so I didn't pursue this further at the time, hoping to pick it up again when inline const get stabilized.
>
> Unfortunately, years later, inline const are still not stable, and the longer the wait the bigger the risk that we'll never be able to fully make this transition and stop promoting function calls in `const`/`static` initializers. So this is my contingency plan: the actual goal of the "infallible promotion" RFC was to ensure that _we can evaluate any const we see in a MIR body without worrying about whether that would lead to incorrect compilation failures_ (i.e., leading compilation to fail when it should not). This property is something we want as it means we can traverse the MIR for analyses and optimizations and just "look at" all consts without worrying about possible side-effects. We even guarantee that all consts one explicitly syntactically mentions in a function get evaluated, even in dead code, which is a pattern some crates rely on for soundnes. Promotion adds new consts, which is why it needs to be restricted, or else we need to carefully skip promoteds when evaluating all consts. The easiest way to achieve this is to ensure we only create promoteds that cannot fail, then they trivially cannot break this property. But there is another way: if we look again at the example above, then that program would fail to compile even if we didn't promote. In other words, promoting the `&my_function()` and then evaluating that promoted does not introduce an incorrect compilation failure! Only creating fallible promoteds _in dead code_ can cause incorrect compilation failure.
>
> So I propose that we achieve the goals of the RFC while maintaining compatibility as much as possible by only promoting function calls in `const`/`static` initializers if they are definitely not in dead code. This PR implements a fairly trivial way to achieve that: we walk the CFG of the initializer from the start block until the first branch (i.e., we walk down the "line" of basic blocks at the top that is formed by `Goto` and function calls), and all these blocks are definitely not dead. We only promote function calls in those blocks. This will miss blocks that are definitely not dead due to merging control flow (i..e, anything after the first `if`). But it turns out this is already sufficient to give us 0 crater regressions, so a more complicated analysis does not seem worth it.
>
> In other words, the code above still compiles after this PR. The following code no longer compiles after this PR, and that is intended:
>

const fn my_function() -> i32 { panic!() }

const C: &'static i32 = {
  if false { // or any other condition
    let x = &my_function();
    x
  } else {
    &42
  }
};

>
> The following code also no longer compiles after this PR, which is unfortunate but doesn't seem worth the effort of making it compile:
>

const fn my_function() -> i32 { panic!() }

const C: &'static i32 = {
  if true {} // or any other condition
  let x = &my_function();
  x
};

>
> Maybe in a future edition we can entirely stop promoting function calls in `const`/`static` initializers. That is blocked on having inline consts. However, to make the desired property of being able to evaluate all consts we see actually useful to compiler developers, we need to achieve this property on _all_ editions, so any such edition-related plan does not substitute a PR like this. Also, edition transitions for promotions are very hard (there is no plan for how one could possibly do automatic migration or future-compat lints), so I wouldn't want to bank on this.
>
> I this pretty? No! Promotion rules are suddenly different in different parts of a `const`/`static` initializer. If I had a time machine I'd just make sure we never promote `const fn` calls to begin with. But mistakes were made and we have to live with them if we want to maintain compatibility. All we can do is mitigate the consequences of those mistakes, so I propose we add this new wart to the language to mitigate the problems caused by that old mistake. We already have value-dependent promotion (`&(0/1)` gets promoted but `&(1/0)` and `&(0/(1*1))` do not, to make sure we do not promote a division by 0) now we add location-dependent promotion. In other words, promotion is already ugly, this just makes it a bit more ugly. I hope users will never run into this, and the fact that crater found no regressions makes me confident that this will at least be extremely rare.
>
> If we ever get inline consts then we can consider cleaning up this mess by entirely stopping to promote function calls in `const`/`static` initializers, and accepting the breaking change. But I don't want to bet on the fact that we'll be able to do that, it's been years since the last crater run and the ecosystem has grown significantly since then. So this PR is forward-compatible with making things nice(r) again, but meanwhile accepting this PR ensures that MIR consumers can finally stop worrying about which consts they can or cannot evaluate.

TC: We discussed this without resolution in the meeting on 2024-03-13. We discussed how having inline `const` blocks could move us in a direction of solving these problems more generally.

Those were blocked on incremental build-time regressions in:

https://github.com/rust-lang/rust/pull/112879

However, RalfJ has now analyzed this here:

https://github.com/rust-lang/rust/pull/112879#issuecomment-1987198783

...and has a superseding PR that solves the problem which a much more modest performance regression:

https://github.com/rust-lang/rust/pull/122568

scottmcm: If the hope here is to go to the simpler thing once we have inline_const, and thus this is sort of temporary (if perhaps not completely temporary because old editions), then I think I'm fine with it. I also don't love it, but if it's a good step, then great.

tmandry: +1.

tmandry: Question is whether Ralf still wants to go forward if inline consts look much closer to stabilizing now.. from the description it sounds like probably yes.

RalfJ: Yes, I'd still want to land this even with inline const.

tmandry: I'll go ahead and start the FCP here then.

(The second meeting ended here.)

---

### "Support ?Trait bounds in supertraits and dyn Trait under a feature gate" rust#121676

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

TC: This is related to this MCP about a path toward async drop and scoped tasks:

https://github.com/rust-lang/compiler-team/issues/727

TC: petrochenkov gives some background:

> Summary:
>
> * [Initial support for auto traits with default bounds #120706](https://github.com/rust-lang/rust/pull/120706) introduces a way to add new auto traits that are appended to all bound lists by default, similarly to existing `Sized`. Such traits may include `Leak`, `SyncDrop` or similar, see [Initial support for auto traits with default bounds #120706 (comment)](https://github.com/rust-lang/rust/pull/120706#issuecomment-1934006762) for more detailed motivation.
> * To opt out from bounds added by default the `?Trait` syntax is used, but such "maybe" bounds are not supported in some contexts like supertrait lists and `dyn Trait + ...` lists, because `Sized` is not added by default in those context.
> * This PR adds a feature for supporting `trait Trait1: ?Trait2`, `dyn Trait1 + ?Trait2` and also multiple maybe bounds in the same list `?Trait1 + ?Trait2`, because the new traits need to be added by default in those contexts too, and `?Sized + ?Leak` may also make sense.
> * We need this to be available in bootstrap compiler, to make experiments on standard library without adding too many `#[cfg(not(bootstrap))]`s
> * Larger compiler team MCP including this feature - [MCP: Low level components for async drop compiler-team#727](https://github.com/rust-lang/compiler-team/issues/727), it gives some more context

TC: The question here is whether we want to charter this as an experiment.

### "Initial support for auto traits with default bounds" rust#120706

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

TC: This is related to this MCP about a path toward async drop and scoped tasks:

https://github.com/rust-lang/compiler-team/issues/727

TC: petrochenkov gives some background:

> So, what are the goals here:
>
> * We want to have a possibility to add new auto traits that are added to _all_ bound lists by default on the current edition. The examples of such traits could be `Leak`, `Move`, `SyncDrop` or something else, it doesn't matter much right now. The desired behavior is similar to the current `Sized` trait. Such behavior is required for introducing `!Leak` or `!SyncDrop` types in a backward compatible way. (Both `Leak` and `SyncDrop` are likely necessary for properly supporting libraries for scoped async tasks and structured concurrency.)
> * It's not clear whether it can be done backward compatibly and without significant perf regressions, but that's exactly what we want to find out. Right now we encounter some cycle errors and exponential blow ups in the trait solver, but there's a chance that they are fixable with the new solver.
> * Then we want to land the change into rustc under an option, so it becomes available in bootstrap compiler. Then we'll be able to do standard library experiments with the aforementioned traits without adding hundreds of `#[cfg(not(bootstrap))]`s.
> * Based on the experiments, we can come up with some scheme for the next edition, in which such bounds are added more conservatively.
> * Relevant blog posts - https://without.boats/blog/changing-the-rules-of-rust/, https://without.boats/blog/follow-up-to-changing-the-rules-of-rust/ and https://without.boats/blog/generic-trait-methods-and-new-auto-traits/, https://without.boats/blog/the-scoped-task-trilemma/
> * Larger compiler team MCP including this feature - [MCP: Low level components for async drop compiler-team#727](https://github.com/rust-lang/compiler-team/issues/727), it gives some more context

TC: The question here is whether we want to charter this as an experiment.

### "Add simple async drop glue generation" rust#121801

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

TC: This is related to this MCP about a path toward async drop and scoped tasks:

https://github.com/rust-lang/compiler-team/issues/727

TC: petrochenkov gives some background:

> * Larger compiler team MCP including this feature - [MCP: Low level components for async drop compiler-team#727](https://github.com/rust-lang/compiler-team/issues/727), it gives some more context
> * "Async drop glue" partially implemented in this PR allows to automatically generate an async drop implementation for a structure, enum, or coroutine (or any other complex type) if some of the fields inside it have async drop.
> * This is analogous to generation of a regular drop glue, that drops a type by first calling its surface destructor, and then dropping all its fields in order, but doing all that with futures is more complex.
> * Possible alternatives for this are to require dropping larger structures manually, if they have `AsyncDrop` fields inside them, or to provide `#[derive(AsyncDrop)]` for doing this semi-automatically.
>
> * This approach won't work on coroutines (or closures) containing `AsyncDrop` types inside them, and coroutines are indeed expected to contain such types.
> * There's always an alternative to reject the async drop feature as a whole, but there's clearly a demand for at least trying to support it and seeing what libraries can do with it. If async drop feature in general goes further in some form (including `finally` blocks or similar), then the async drop glue generation will likely be a part of it.

TC: The question here is whether we want to charter this as an experiment.

### "privacy: Stabilize lint `unnameable_types`" rust#120144

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

TC: petrochenkov implemented the last piece of RFC 2145 ("Type privacy and private-in-public lints"):

https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md

He's seeking to stabilize it. Here's what we're talking about:

#![feature(type_privacy_lints)]
#![deny(unnameable_types)]

mod m {
    pub struct Unnameable;
    //~^ ERROR struct `PubStruct` is reachable but cannot be named
    //~| NOTE reachable at visibility `pub`, but can only be named at visibility `pub(crate)`
}

pub fn leak() -> m::Unnameable {
    m::Unnameable
}

TC: Back on 2024-02-14 we discussed this in a triage meeting and were feeling positive about it, resulting in an FCP merge. This has been waiting on one additional checkbox and petrochenkov has renominated this for us to see if we want to move forward.

TC: There's been some discussion on the name. I have to admit, my first reaction was, "this isn't what we mean by unnameable types in Rust". But then, after I worked through some examples (such as above) and thought about it, I realized that, *yes*, actually this is what we mean by unnameable types. In fact, the accepted RFC even specifically called these "Voldemort types":

https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md#lint-3-voldemort-types-its-reachable-but-i-cant-name-it

...and it suggested `unnameable_types` as the name for the lint.

TC: Do we still want to move forward here?

### "Tracking issue for function attribute `#[coverage]`" rust#84605

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

TC: This is about stabilizing a `#[coverage(off)]` attribute to exclude items from `-Z instrument-coverage`.

Josh proposed FCP merge and nominated this for us.

There are two open questions about applying this automatically to nested functions and to inlined functions.

TC: What do we think?

### "Should Rust still ignore SIGPIPE by default?" rust#62569

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

TC: Prior to `main()` being executed, the Rust startup code makes a syscall to change the handling of `SIGPIPE`. Many believe that this is wrong thing for a low-level language like Rust to do, because 1) it makes it impossible to recover what the original value was, and 2) means things like `seccomp` filters must be adjusted for this.

It's also just, in a practical sense, wrong for most CLI applications.

This seems to have been added back when Rust had green threads and then forgotten about. But it's been an ongoing footgun.

There was discussion in 2019 about fixing this over an edition, but nothing came of it.

TC: Are we interested in fixing it over this one?

### "Stabilize `#[unix_sigpipe = "sig_dfl"]` on `fn main()`" rust#120832

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

TC: This is related to the above, and is a proposal to stabilize an option to have the startup code set `SIGPIPE` to the *other* handler. However, this does not address the problem that the Rust startup code is making this syscall at all, which means that e.g. `seccomp` filters must be correctly adjusted and it's still impossible to recover the original inherited setting of this handler.

There are also the following options to this attribute that are not proposed for stabilization here:

- `sig_ign`: This is the current default behavior.
- `inherent`: This would prevent the startup code from making this syscall at all.

TC: What do we think?

### "`is` operator for pattern-matching and binding" rfcs#3573

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

TC: Josh proposes for us that we should accept:

if an_option is Some(x) && x > 3 {
    println!("{x}");
}

And:

func(x is Some(y) && y > 3);

TC: The main topic discussed in the issue thread so far has been the degree to which Rust should have "two ways to do things". Probably the more interesting issue is how the binding and drop scopes for this should work.

TC: In the 2024-02-21 meeting (with limited attendance), we discussed how we should prioritize stabilizing let chains, and tmandry suggested we may want to allow those to settle first.

TC: What do we think, as a gut check?

### "Policy for lint expansions" rust#122759

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

TC: In the call on 2024-03-13, we discussed this issue raised by tmandry:

"Fallout from expansion of redundant import checking"

https://github.com/rust-lang/rust/issues/121708

During the call, the thoughts expressed included:

- We don't want to create a perverse incentive for people to expand existing lints rather than to create new ones where appropriate just because there's less process for expanding the meaning of an existing lint.
- It would be good if potentially-disruptive expansions of an existing lint either:
- Had a machine-applicable fix.
- Or had a new name.
- We don't want to require a new lint name for each expansion.
- We don't want to require a crater run for each change to a lint.
- There are two ways to prevent disruption worth exploring:
- Prevent potentially-disruptive changes from hitting master.
- Respond quickly to early indications of disruption once the changes hit master.
- Compiler maintainers have a sense of what might be disruptive and are cautious to avoid it. It may be OK to have a policy that is not perfectly measurable.

TC: tmandry volunteered to draft a policy proposal. He's now written up this proposal in this issue.

> ## Background
>
> When a lint is expanded to include many new cases, it adds significant complexity to the rollout of a toolchain to large codebases. Maintainers of these codebases are stuck with the choice of
>
> 1. Disabling the existing lint while the toolchain is updated and new cases are fixed
> 2. Fixing cases manually and updating the toolchain immediately
>
> Both of these come with the problem of _racing_ with other developers in a codebase who may land new code which triggers the expanded lint in a new compiler, but does _not_ trigger the lint in an old compiler.
>
> While it would be nice to solve this "raciness" once and for all, there are other considerations at play. Instead, we propose to support these users by either providing them with a new lint name to temporarily opt out of _OR_ a machine-applicable fix which eases the pain of any races which might occur.
>
> Note that this requirement only applies to _significant_ lint expansions as measured by crater.
>
> ## Policy
>
> When an existing lint is expanded to include many new cases, we must provide either:
>
> 1. A new lint name under the existing group, so that users may opt out of the expansion at least temporarily, or
> 2. A MachineApplicable fix for the lint.
>
> Exceptions to this policy may be made via Language Team FCP.
>
> Here, we define "many new cases" as impacting more than 5% of the top-1000 crates on crates.io. This can be measured by counting the number of regressions from a crater run like the one below.
>
> A crater run is not required before landing for every lint expansion. Reviewers should use their best judgment to decide if one is required. However, if a lint expansion lands that violates this requirement, or is strongly suspected to violate this requirement based on other impact, it should be reverted.
>
> #### Crater command
>
> To measure the impact of a lint as defined by this policy, you can use the following crater command:
>
> `@craterbot run name=<name> start=master#<hash1>+rustflags=-D<lint_name> end=master#<hash2>+rustflags=-D<lint_name> crates=top-1000 mode=check-only p=1`
>
> See the [crater docs](https://github.com/rust-lang/crater/blob/master/docs/bot-usage.md#tutorial-creating-an-experiment-for-a-pr) for more information.

TC: What do we think?

### "Raw Keywords" rfcs#3098

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

TC: We've at various times discussed that we had earlier decided that if we wanted to use a new keyword within an edition, we would write it as `k#keyword`, and for that reason, we prefer to not speculatively reserve keywords ahead of an edition (except, perhaps, when it's clear we plan to use it in the near future).

TC: Somewhat amusingly, however, we never in fact accepted that RFC. Back in 2021, we accepted scottmcm's proposal to **cancel**:

> We discussed this RFC again in the lang team triage meeting today.
>
> For the short-term goal of the reservation for the edition, we'll be moving forward on #3101 instead. As such, we wanted to leave more time for conversations about this one, and maybe use crater results from 3101 to make design changes,
>
> @rfcbot cancel

Instead we accepted RFC 3101 that reserved `ident#foo`, `ident"foo"`, `ident'f'`, and `ident#123` starting in the 2023 edition.

Reading through the history, here's what I see:

- What do we want to do about Rust 2015 and Rust 2021. It's a breaking change to add this there. Is this OK? Do we want to do a crater run on this?
- Would we have the stomach to actually do this? It's one thing to *say* that if we wanted to use a new keyword within an edition, we'd write `k#keyword`, but it's another to actually do it in the face of certain criticism about that being e.g. unergonomic. Would we follow through?

TC: What do we think?

### "offset: allow zero-byte offset on arbitrary pointers" rust#117329

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

TC: RalfJ nominates this for us:

> Nominating for t-lang discussion. This implements the t-opsem consensus from [rust-lang/opsem-team#10](https://github.com/rust-lang/opsem-team/issues/10), [rust-lang/unsafe-code-guidelines#472](https://github.com/rust-lang/unsafe-code-guidelines/issues/472) to generally allow zero-sized accesses on all pointers. Also see the [tracking issue](https://github.com/rust-lang/rust/issues/117945).
>
> * Zero-sized reads and writes are allowed on all sufficiently aligned pointers, including the null pointer
> * Inbounds-offset-by-zero is allowed on all pointers, including the null pointer
> * `offset_from` on two pointers is always allowed when they have the same address (but see the caveat below)
>
> This means the following function is safe to be called on any pointer:
>

fn test_ptr(ptr: *mut ()) { unsafe {
    // Reads and writes.
    let mut val = *ptr;
    *ptr = val;
    ptr.read();
    ptr.write(());
    // Memory access intrinsics.
    // - memcpy (1st and 2nd argument)
    ptr.copy_from_nonoverlapping(&(), 1);
    ptr.copy_to_nonoverlapping(&mut val, 1);
    // - memmove (1st and 2nd argument)
    ptr.copy_from(&(), 1);
    ptr.copy_to(&mut val, 1);
    // - memset
    ptr.write_bytes(0u8, 1);
    // Offset.
    let _ = ptr.offset(0);
    let _ = ptr.offset(1); // this is still 0 bytes
    // Distance.
    let ptr = ptr.cast::<i32>();
    ptr.offset_from(ptr);
} }

>
> Some specific concerns warrant closer scrutiny.
>
> ## LLVM 16
>
> We currently still support LLVM 16, which does not yet have the patches that make `getelementptr inbounds` always well-defined for offset 0. The function above thus generates LLVM IR with UB. No known miscompilations arise from that, and my attempt at just removing the `inbounds` annotation on old versions of LLVM failed (I got segfaults, and Nikic [suggested](https://github.com/rust-lang/rust/pull/117329#issuecomment-1783925317) that keeping these attribute around is actually less risky than removing them). If we want to avoid this, we have to wait until support for LLVM 16 can be dropped (which apparently is in May).
>
> ## Null pointers
> t-opsem decided to allow zero-sized reads and writes on null pointers. This is mostly for consistency: we definitely want to allow zero-sized offsets on null pointers (`ptr::null::<T>().offset(0)`), since this is allowed in C++ (and a proposal is being made to allow it in C) and there's no reason for us to have more UB than C++ here. But if we allow this, and therefore consider the null pointer to have a zero-sized region of "inbounds" memory, then it would be inconsistent to not allow reading from / writing to that region.
>
> ## `offset_from`
>
> This operation is somewhat special as it takes two pointers. We do want `test_ptr` above to be defined on all pointers, so `offset_from` between two identical pointers without provenance must be allowed. But we also want to achieve this property called "provenance monotonicity", whereby adding arbitrary provenance to any no-provenance pointer must never make the program UB.[1](#user-content-fn-mono-e335860ede81d9f8aeed856dbd25a8e3) From these two it follows that calling `offset_from` with two pointers with the same address but arbitrary different provenance must be allowed. This does have some [minor downsides](https://github.com/rust-lang/unsafe-code-guidelines/issues/472#issuecomment-1921686682). So my proposal (and this goes beyond what t-opsem agreed on) is to define the `ptr_offset_from` intrinsic to satisfy provenance monotonicity, but to document the user-facing `ptr.offset_from(...)` as requiring either two pointers without provenance or two pointers with provenance for the same allocation -- therefore, making the case of provenance mismatch library UB, but not language UB.
>
> ## Footnotes
>
> 1. This property should hopefully make some intuitive sense, and it is also crucial to justify optimizations that make the program have more provenance than before -- such as optimizing away provenance-stripping operations. Specifically, `*ptr = *ptr` where `ptr: *mut usize` is likely going to be a provenance-stripping operation, and so optimizing away this redundant assignment requires provenance monotonicity. [↩](#user-content-fnref-mono-e335860ede81d9f8aeed856dbd25a8e3)

TC: What do we think?

### "Let's `#[expect]` some lints: Stabilize `lint_reasons` (RFC 2383) " rust#120924

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

TC: Since the last time this was proposed for stabilization, various unresolved questions have now been resolved, so this is being proposed again.

> Hey everyone, with the `#[expect]` implementation done, I'd like to propose stabilizing this feature. I've crated two stabilization PRs, one updating the documentation and one removing the feature from rustc:
>
> * [Let's `#[expect]` some lints: Stabilize `lint_reasons` (RFC 2383)  #120924](https://github.com/rust-lang/rust/pull/120924)
> * [Document new `#[expect]` attribute and `reasons` parameter (RFC 2383) reference#1237](https://github.com/rust-lang/reference/pull/1237)
>
> The RFC 2383 adds a `reason` parameter to lint attributes and a new `#[expect()]` attribute to expect lint emissions.
>
> * Here is an example how the reason can be added and how it'll be displayed as
> part of the emitted lint message:
>

#![feature(lint_reasons)]
fn main() {
    #[deny(unused_variables, reason = "unused variables, should be removed")]
    let unused = "How much wood would a woodchuck chuck?";
}
error: unused variable: `unused`
 --> src/main.rs:5:9
  |
5 |     let unused = "How much wood would a woodchuck chuck?";
  |         ^^^^^^ help: if this is intentional, prefix it with an underscore: `_unused`
  |
  = note: unused variables, should be removed
note: the lint level is defined here
 --> src/main.rs:4:12
  |
4 |     #[deny(unused_variables, reason = "unused variables, should be removed")]
  |            ^^^^^^^^^^^^^^^^

>
> * Here is an example, that fulfills the expectation and compiles successfully:
>

#![feature(lint_reasons)]
fn main() {
    #[expect(unused_variables, reason = "WIP, I'll use this value later")]
    let message = "How much wood would a woodchuck chuck?";

    #[expect(unused_variables, reason = "is this unused?")]
    let answer = "about 700 pounds";
    println!("A: {answer}")
}
warning: this lint expectation is unfulfilled
 --> src/main.rs:4:14
  |
6 |     #[expect(unused_variables, reason = "is this unused?")]
  |              ^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unfulfilled_lint_expectations)]` on by default
  = note: is this unused?

> ## Changes from the RFC
>
> As part of my implementation, I renamed the `#[expect]` lint from `expectation_missing` to `unfulfilled_lint_expectations`. I think the name works better with other lint attributes and is more descriptive.
>
> ## Resolutions of unresolved questions
>
> 1. Where should the `reason` parameter be allowed?
>
> * The current implementation only allows it as the last parameter in all lint attributes
> 2. How should `#[expect(unfulfilled_lint_expectations)]` be handled?
>
> * In the RFC, it was suggested that the `unfulfilled_lint_expectations` can be expected by outer attributes. However, it was also questioned how useful this would actually be. The current implementation doesn't allow users to expect this lint. For `#[expect(unfulfilled_lint_expectations)]` the lint will be emitted as usual, with a note saying that `unfulfilled_lint_expectations` can't be expected.
>
> 3. How should `#[expect(XYZ)]` and `--force-warn XYZ` work?
>
> * This implementation, will emit the lint XYZ, as the lint level has been defined by `--force-warn` and also track the expectation as it usually would with only the `#[expect]` attribute.
>
> ## Updates
>
> Since the initial report, a few questions have been discussed by the lang team, here is a quick overview of the questions and resolutions:
>
> 1. Should the attribute really be called `#[expect]` or is the name too generic?
>
> * `#[expect]` is good ([Decision](https://hackmd.io/@xFrednet/rust-lang-team191#Q1-Name))
> 2. What are the semantics of the `#[expect]` attribute?
>
> * Decision: An expectation should count as fulfilled, if a `#[warn]` attribute at the same location would result in a lint emission ([Decision](https://github.com/rust-lang/rust/issues/115980))
>
> ## Open issues
>
> * `#[expect(lint)]` currently doesn't work on macros. This is in line with other lint attributes. This bug is tracked in [Specifying lint levels does not work on macros #87391](https://github.com/rust-lang/rust/issues/87391) and tested in [`expect_lint_from_macro.rs`](https://github.com/rust-lang/rust/blob/a9bf9eaef5165067414b33777a2c924e42aab5aa/src/test/ui/lint/rfc-2383-lint-reason/expect_lint_from_macro.rs#L26)

TC: What do we think?

### "Lang discussion: Item-level `const {}` blocks, and `const { assert!(...) }`" lang-team#251

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

TC: This issue was raised due to discussion in a T-libs-api call. Josh gives the context:

> In discussion of [rust-lang/libs-team#325](https://github.com/rust-lang/libs-team/issues/325) (a proposal for a compile-time assert macro), the idea came up to allow `const {}` blocks at item level, and then have people use `const { assert!(...) }`.
>
> @rust-lang/libs-api would like some guidance from @rust-lang/lang about whether lang is open to toplevel `const { ... }` blocks like this, which would influence whether we want to add a compile-time assert macro, as well as what we want to call it (e.g. `static_assert!` vs `const_assert!` vs some other name).
>
> Filing this issue to discuss in a lang meeting. This issue is _not_ seeking any hard commitment to add such a construct, just doing a temperature check.

CAD97 noted:

> To ensure that it's noted: if both item and expression `const` blocks are valid in the same position (i.e. in statement position), a rule to disambiguate would be needed (like for statement versus expression `if`-`else`). IMO it would be quite unfortunate for item-level `const` blocks to be evaluated pre-mono if that same `const` block but statement-level would be evaluated post-mono.
>
> Additionally: since `const { assert!(...) }` is post-mono (due to using the generic context), it's potentially desirable to push people towards using `const _: () = assert!(...);` (which is pre-mono) whenever possible (not capturing generics).

TC: What do we think?

### "Don't make statement nonterminals match pattern nonterminals" rust#120221

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

TC: CE handed this one to us, since it changes the contract of macro matchers:

> Right now, the heuristic we use to check if a token may begin a pattern nonterminal falls back to `may_be_ident`.
>
> This has the unfortunate side effect that a `stmt` nonterminal eagerly matches against a `pat` nonterminal, leading to a parse error:
>

macro_rules! m {
    ($pat:pat) => {};
    ($stmt:stmt) => {};
}

macro_rules! m2 {
    ($stmt:stmt) => {
        m! { $stmt }
    };
}

m2! { let x = 1 }

>
> This PR fixes it by more accurately reflecting the set of nonterminals that may begin a pattern nonterminal.
>
> As a side-effect, I modified `Token::can_begin_pattern` to work correctly and used that in `Parser::nonterminal_may_begin_with`.

TC: What do we think?

### "add float semantics RFC" rfcs#3514

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

TC: In addition to documenting the current behavior carefully, this RFC (per RalfJ)...

> says we should allow float operations in `const fn`, which is currently not stable. This is a somewhat profound decision since it is the first non-deterministic operation we stably allow in `const fn`. (We already allow those operations in `const`/`static` initializers.)

TC: What do we think? tmandry proposed this for FCP merge back in October 2023.

### "RFC: Allow symbol re-export in cdylib crate from linked staticlib" rfcs#3556

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

TC: This seems to be about making the following work:

// kind is optional if it's been specified elsewhere, e.g. via the `-l` flag to rustc
#[link(name="ext", kind="static")]
extern {
    #[no_mangle]
    pub fn foo();

    #[no_mangle]
    pub static bar: std::ffi::c_int;
}

There are apparently use cases for this.

What's interesting is that apparently it already does, but we issue a warning that is wrong:

warning: `#[no_mangle]` has no effect on a foreign function
  --> src/lib.rs:21:5
   |
21 |     #[no_mangle]
   |     ^^^^^^^^^^^^ help: remove this attribute
22 |     pub fn foo_rfc3556_pub_with_no_mangle();
   |     ---------------------------------------- foreign function
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: symbol names in extern blocks are not mangled

TC: One of the author's asks of us is that we don't make this into a hard error (e.g. with the new edition).

TC: What do we think?

### "Tracking Issue for unicode and escape codes in literals" rust#116907

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

TC: nnethercote has implemented most of RFC 3349 ("Mixed UTF-8 literals") and, based on implementation experience, argues that the remainder of the RFC should not be implemented:

> I have a partial implementation of this RFC working locally (EDIT: now at #120286). The RFC proposes five changes to literal syntax. I think three of them are good, and two of them aren't necessary.

TC: What do we think?

### "Better errors with bad/missing identifiers in MBEs" rust#118939

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

TC: The idea here seems to be to improve some diagnostics around `macro_rules`, but this seems to be done by way of reserving the `macro_rules` token more widely, which is a breaking change. Petrochenkov has objected to it on that basis, given that reserving `macro_rules` minimally has been the intention since we hope it will one day disappear in favor of `macro`. What do we think?

### "RFC: Syntax for embedding cargo-script manifests" rfcs#3503

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

TC: This has been changed to use `---` syntax with an optional infostring (that is arbitrary except for forbidding whitespace and commas).

TC: tmandry, Josh, and I are +1. What do we think?

### "Stabilize `extended_varargs_abi_support`" rust#116161

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

TC: This stabilization was nominated for us, with pnkfelix commenting:

> Just to add on to @cjgillot 's comment above: @wesleywiser and I could not remember earlier today whether T-lang _wants_ to own FCP'ing changes like this that are restricted to extending the set of calling-conventions (i.e. the `conv` in `extern "conv" fn foo(...)`), which is largely a detail about what platforms one is interoperating with, and not about changing the expressiveness of the Rust language as a whole in the abstract.
>
> (My own gut reaction is that T-compiler is a more natural owner for this than T-lang, but I wasn't certain and so it seems best to let the nomination stand and let the two teams duke it out.)

TC: What do we think about 1) this stabilization, and 2) whether we want to own this?

### "Uplift `clippy::invalid_null_ptr_usage` lint" rust#119220

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

TC: Urgau proposes this for us:

> This PR aims at uplifting the `clippy::invalid_null_ptr_usage` lint into rustc, this is similar to the [`clippy::invalid_utf8_in_unchecked` uplift](https://github.com/rust-lang/rust/pull/111543) a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one.
>
> ## `invalid_null_ptr_usages`
>
> (deny-by-default)
>
> The `invalid_null_ptr_usages` lint checks for invalid usage of null pointers.
>
> ### Example
>

// Undefined behavior
unsafe { std::slice::from_raw_parts(ptr::null(), 0); }
// Not Undefined behavior
unsafe { std::slice::from_raw_parts(NonNull::dangling().as_ptr(), 0); }

>
> Produces:
>

error: calling this function with a null pointer is undefined behavior, even if the result of the function is unused, consider using a dangling pointer instead
  --> $DIR/invalid_null_ptr_usages.rs:14:23
   |
LL |     let _: &[usize] = std::slice::from_raw_parts(ptr::null(), 0);
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^-----------^^^^
   |                                                  |
   |                                                  help: use a dangling pointer instead: `core::ptr::NonNull::dangling().as_ptr()`

>
> ### Explanation
>
> Calling methods who's safety invariants requires non-null pointer with a null pointer is undefined behavior.
>
> The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a `#[diagnostic]` attribute.

TC: What do we think?

### "#[cold] on match arms" rust#120193

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

TC: Apparently our unstable `likely` and `unlikely` intrinsics don't work. There's a proposal to do some work on fixing that and stabilizing a solution here. The nominated question is whether we want to charter this as an experiment.

### "debuginfo: Stabilize `-Z debug-macros`, `-Z collapse-macro-debuginfo` and `#[collapse_debuginfo]`" rust#120845

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

TC: This finished a T-compiler FCP, but ehuss nominates this for us on the grounds of policy:

> It has been the policy as long as I'm aware that the lang team is responsible for attributes. For example, they recently approved the `debugger_visualizer` attribute. I would not expect them to have any concerns here, but I think we should keep with the precedent unless there is an explicit decision by them to change it.

TC: What do we think?

### "False positives for the new `non_local_definitions` lint" rust#121746

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

TC: There is discussion in the issue in which Urgau explains why this is not a false positive, but the reporter still thinks it's misleading, and Josh nominated this for us.

TC: What do we think?

### "Elaborate on the invariants for references-to-slices" rust#121965

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

TC: scottmcm filed this issue and explains:

> The length limit on slices is clearly a safety invariant, and I'd like it to also be a validity invariant. With [function parameter metadata](https://discourse.llvm.org/t/rfc-metadata-attachments-for-function-arguments/76420?u=scottmcm) making progress in LLVM, I'd really like to be able to use it when `&[_]` is passed as a scalar pair, in particular.
>
> The documentation for references is cagey about what exactly is a validity invariant, so for now just elaborate on the consequences of the existing safety rules on slices -- the length restriction follows from the `size_of_val` restriction -- as a way to help discourage people from trying to violate them.
>
> I also made the existing warning stronger, since I'm fairly sure it's already UB to violate at least the "references must be non-null" rule, rather than it just being that it "might be UB in the future".

Then joboet nominated this for us with:

> Given that `slice::from_raw_parts` already states that "the total size `len * mem::size_of::<T>()` of the slice must be no larger than `isize::MAX`" and that its behaviour is undefined otherwise, I'd say that this is entirely uncontroversial. Still, I'd appreciate some team sign-off on this, I think this concerns lang?

RalfJ thinks this should probably be a dual T-lang / T-opsem FCP.

TC: What do we think?

### "`#![crate_name = EXPR]` semantically allows `EXPR` to be a macro call but otherwise mostly ignores it" rust#122001

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

TC: fmease notes that:

> Contrary to `#![crate_type = EXPR]`, `#![crate_name = EXPR]` does **not** semantically reject _macro calls_ inside `EXPR`. Instead, it eagerly expands them but otherwise **ignores** the result (apart from errors).
>
> ### Examples
>
> The following examples all pass compilation and rustc _completely_ ignores the crate name that comes from the expansion, i.e., `rustc file.rs --print=crate-name` prints `file` (the file name is assumed to be `file.rs`).
>
> #### (A)
> ```rust
> #![crate_name = concat!("alia", "s")] // ignored, crate name is `file`, not `alias`
> fn main() {}
> ```
>
> #### (B)
> ```rust
> #![crate_name = include_str!("crate_name.txt")] // ignored, crate name is `file`, not `alias`
> fn main() {}
> ```
>
> where `crate_name.txt` exists and consists of `alias`.
>
> #### (C)
> ```rust
> #![crate_name = dep::generate!()] // ignored, crate name is `file`, not `alias`
> fn main() {}
> ```
>
> where we compile `file.rs` with `--extern=dep -L --edition=2021` and where `dep.rs` is:
>
> ```rust
> #[macro_export]
> macro_rules! generate { () => { "alias" } }
> ```

TC: pnkfelix nominates this for us:

> I think the question of whether we ever _intended_ to support `#![crate_name = MACRO_CALL]` belongs under T-lang rather than T-compiler.

### "Assert that the first `assert!` expression is `bool`" rust#122661

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

TC: estebank describes this issue for us:

> In the desugaring of `assert!` in 2024 edition, assign the condition expression to a `bool` biding in order to provide better type errors when passed the wrong thing.
>
> The span will point only at the expression, and not the whole `assert!` invocation.
>

error[E0308]: mismatched types
  --> $DIR/issue-14091.rs:2:13
   |
LL |     assert!(1,1);
   |             ^ expected `bool`, found integer

>
> We no longer mention the expression needing to implement the `Not` trait.
>

error[E0308]: mismatched types
  --> $DIR/issue-14091-2.rs:15:13
   |
LL |     assert!(x, x);
   |             ^ expected `bool`, found `BytePos`

>
> In <=2021 edition, we still accept any type that implements `Not<Output = bool>`.

TC: And pnkfelix nominates this for us:

> At the very least, we might need to tie such a change to an edition.
>
> I am not certain whether this decision would be a T-lang matter or a T-libs-api one. I'll nominate for T-lang for now.
>
> (Namely: The question is whether we can start enforcing a rule that the first expression to `assert!` must be of bool type, which is how the [macro is documented](https://doc.rust-lang.org/std/macro.assert.html), but its current behavior is a little bit more general, as demonstrated in my [prior comment](https://github.com/rust-lang/rust/pull/122661#issuecomment-2004197554))

### "Emit a warning if a `match` is too complex" rust#122685

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

TC: Nadri nominates this for us and describes the situation:

> Dear T-lang, this PR adds a warning that cannot be silenced, triggered when a match takes a really long time to analyze (in the order of seconds). This is to help users figure out what's taking so long and fix it.
>
> We _could_ make the limit configurable or the warning `allow`able. I argue that's not necessary because [crater](https://github.com/rust-lang/rust/pull/121979#issuecomment-2003089646) showed zero regressions with the current limit, and it's be pretty easy in general to split up a `match` into smaller `match`es to avoid blowup.
>
> We're still figuring out the exact limit, but does the team approve in principle?

TC: What do we think?

### "Proposal: Remove `i128`/`u128` from the `improper_ctypes` lint" lang-team#255

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

TC: Trevor Gross describes the situation:

> For a while, Rust's 128-bit integer types have been incompatible with those from C. The original issue is here [rust-lang/rust#54341](https://github.com/rust-lang/rust/issues/54341), with some more concise background information at the MCP here [rust-lang/compiler-team#683](https://github.com/rust-lang/compiler-team/issues/683)
>
> The current Beta of 1.77 will have [rust-lang/rust#116672](https://github.com/rust-lang/rust/pull/116672), which manually sets the alignment of `i128` to make it ABI-compliant with any version of LLVM (`clang` does something similar now). 1.78 will have LLVM18 as the vendored version which fixes the source of this error.
>
> Proposal: now that we are ABI-compliant, do not raise `improper_ctypes` on our 128-bit integers. I did some testing with abi-cafe and a more isolated https://github.com/tgross35/quick-abi-check during the time https://reviews.llvm.org/D86310 was being worked on, and verified everything lines up. (It would be great to have some fork of abi-cafe in tree, but that is a separate discussion.)
>
> @joshtriplett mentioned that changing this lint needs a lang FCP https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/LLVM.20alignment.20of.20i128/near/398422037. cc @maurer
>
> Reference change from when I was testing [rust-lang/rust@c742908](https://github.com/rust-lang/rust/commit/c742908c4b9abde264b8c5e9663e31c649a47f2f)

TC: Josh nominates this for our discussion. What do we think?

### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418

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

TC: We discussed this last in the meeting on 2024-03-13. scottmcm has now raised on concern on the issue and is planning to make a counter-proposal:

> I remain concerned about exposing this with no opt-out on an unrestricted generic type @rfcbot concern overly-broad
>
> I'm committing to making an alternative proposal because I shouldn't block without one. Please hold my feet to the fire if that's no up in a week.
>
> Basically, I have an idea for how we might be able to do this, from [#106418 (comment)](https://github.com/rust-lang/rust/pull/106418#issuecomment-1698887324)
>
> > 2. Expose the variant ordering privately, only accessible by the type owner/module.
> >
> > Solution 2. is obviously more desirable, but AFAIK Rust can't do that and there is no proposal to add a feature like that.

https://github.com/rust-lang/rust/pull/106418#issuecomment-1994833151

### "Add lint against function pointer comparisons" rust#118833

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

TC: In the 2024-01-03 call, we developed a tentative consensus to lint against direct function pointer comparison and to push people toward using `ptr::fn_addr_eq`. We decided to ask T-libs-api to add this. There's now an open proposal for that here:

https://github.com/rust-lang/libs-team/issues/323

One question that has come up is whether we would expect this to work like `ptr::addr_eq` and have separate generic parameters, e.g.:

/// Compares the *addresses* of the two pointers for equality,
/// ignoring any metadata in fat pointers.
///
/// If the arguments are thin pointers of the same type,
/// then this is the same as [`eq`].
pub fn addr_eq<T: ?Sized, U: ?Sized>(p: *const T, q: *const U) -> bool { .. }

Or whether we would prefer that `fn_addr_eq` enforced type equality of the function pointers. Since we're the ones asking for this, we probably want to develop a consensus here. We discussed this in the call on 2024-01-10, then we opened a Zulip thread:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Signature.20of.20.60ptr.3A.3Afn_addr_eq.60

TC: On this subject, scottmcm raised this point, with which pnkfelix seemed to concur:

> I do feel like if I saw code that had `fn1.addr() == fn2.addr()` (if `FnPtr` were stabilized), I'd write a comment saying "isn't that what `fn_addr_eq` is for?"
>
> If the answer ends up being "no, actually, because I have different types", that feels unfortunate even if it's rare.
>
> (Like how `addr_eq(a, b)` is nice even if with strict provenance I could write `a.addr() == b.addr()` anyway.)

TC: scottmcm also asserted confidence that allowing mixed-type pointer comparisons is correct for `ptr::addr_eq` since comparing the addresses of `*const T`, `*const [T; N]`, and `*const [T]` are all reasonable. I pointed out that, if that's reasonable, then `ptr::fn_addr_eq` is the higher-ranked version of that, since for the same use cases, it could be reasonable to compare function pointers that return those three different things or accept them as arguments.

TC: Adding to that, scottmcm noted that comparing addresses despite lifetime differences is also compelling, e.g. comparing `fn(Box<T>) -> &'static mut T` with `for<'a> fn(Box<T>) -> &'a mut T`.

TC: Other alternatives we considered were not stabilizing `ptr::fn_addr_eq` at all and instead stabilizing `FnPtr` so people could write `ptr::addr_eq(fn1.addr(), fn2.addr())`, or expecting that people would write instead `fn1 as *const () == fn2 as *const ()`.

TC: Recently CAD97 raised an interesting alternative:

> From the precedent of `ptr::eq` and `ptr::addr_eq`, I'd expect a "`ptr::fn_eq`" to have one generic type and a "`ptr::fn_addr_eq`" to have two. Even if `ptr::fn_eq`'s implementation is just an address comparison, it still serves as a documentation point to call out the potential pitfalls with comparing function pointers.

TC: What do we think?

---

TC: Separately, on the 2024-01-10 call, we discussed some interest use cases for function pointer comparison, especially when it's indirected through `PartialEq`. We had earlier said we didn't want to lint when such comparisons were indirected through generics, but we did address the non-generic case of simply composing such comparisons.

One example of how this is used is in the standard library, in `Waker::will_wake`:

https://doc.rust-lang.org/core/task/struct.Waker.html#method.will_wake

It's comparing multiple function pointers via a `#[derive(PartialEq)]` on the `RawWakerVTable`.

We decided on 2024-01-01 that this case was interesting and we wanted to think about it further. We opened a discussion thread about this:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Function.20pointer.20comparison.20and.20.60PartialEq.60

Since then, another interesting use case in the standard library was raised, in the formatting machinery:

https://doc.rust-lang.org/src/core/fmt/rt.rs.html

What do we think about these, and would we lint on derived `PartialEq` cases like these or no?

### "unsafe attributes" rfcs#3325

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

TC: tmandry nominated this one for us so that we could finish the bikeshed that we started in time for Rust 2024.

Lokathor laid out these options:

> The three basic proposals are:
>
> * `#[unsafe attr]` ("unsafe space")
> * `#[unsafe(attr)]` ("unsafe parens")
> * `#[unsafe { attr }]` ("unsafe braces")
>
> During the lang meeting on 2023-06-06, it was requested that a summary of how each option actually _looks_ in practice be made,so that hopefully one of the proposals can be selected based on readability.
>
> When using an attribute, the attribute itself can be one of three basic forms:
>
> * lone token: `#[no_mangle]`
>
> * `#[unsafe no_mangle]`
> * `#[unsafe(no_mangle)]`
> * `#[unsafe { no_mangle }]`
>
> * key-val expression: `#[link_section = ".foo"]`
>
> * `#[unsafe link_section = ".foo"]`
> * `#[unsafe(link_section = ".foo")]`
> * `#[unsafe { link_section = ".foo" }]`
>
> * an attribute "call": `#[link_ordinal(15)]`
>
> * `#[unsafe link_ordinal(15)]`
> * `#[unsafe(link_ordinal(15))]`
> * `#[unsafe { link_ordinal(15) }]`
>
> There is also the issue of readability when mixed with `cfg_attr`.
>
> * Interior, around only the attribute:
>
> * `#[cfg_attr(cond, unsafe no_mangle)]`
> * `#[cfg_attr(cond, unsafe(no_mangle)]`
> * `#[cfg_attr(cond, unsafe { no_mangle } )]`
>
> * Exterior, around the `cfg_attr`:
>
> * `#[unsafe cfg_attr(cond, no_mangle)]`
> * `#[unsafe(cfg_attr(cond, no_mangle))]`
> * `#[unsafe { cfg_attr(cond, no_mangle ) }]`

TC: This is an interesting case because we are not *discharging* unsafety, as with `unsafe { expr }` in a function body. Neither does saying `unsafe` here create and push upward a type-checked *obligation*. Instead, the upward obligation exists regardless and there is no means to signal to the compiler that it has been discharged and no enforcement of that.

TC: Another option I've seen discussed is finding some way to make these annotations safe.

TC: What do we think?

TC: A poll was opened about this question here:

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unsafe.20attribute.20syntax

TC: While obviously such voting is not dispositive, it is perhaps at least worth noting that sentiment was strongly in favor of `#[unsafe(no_mangle)]`.

### "Uplift `clippy::precedence` lint" rust#117161

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

TC: The proposal is to lint against:

-2.pow(2); // Equals -4.
1 << 2 + 3; // Equals 32.

These would instead be written:

-(2.pow(2)); // Equals -4.
1 << (2 + 3); // Equals 32.

Prompts for discussion:

- Is this an appropriate lint for `rustc`?
- How do other languages handle precedence here?
- Is minus special enough to treat differently than other unary operators (e.g. `!`, `*`, `&`)?

### "`.await` does not perform autoref or autoderef" rust#111546

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

TC: This was nominated for T-lang by WG-async. @tmandry said:

> We discussed this in a recent wg-async meeting ([notes](https://hackmd.io/G6ULofyXSIS4CK9u-jwYRg)). The consensus was that we thought the change was well-motivated. At the same time, we want to be cautious about introducing problems (namely backwards compatibility).
>
> There should probably be a crater run of this change, and we should also work through any problematic interactions that could be caused by this change. (@rust-lang/types should probably weigh in.)
>
> The main motivation for the change is the analogy to `.method()`, as well as to wanting async and sync to feel similarly convenient in most cases.
>
> Note that there is another analogy that works against this, the analogy to `IntoIterator`, where the lang-effect form (`for _ in foo {}`) does not do autoref/autoderef. However, given that this _looks_ very different from `foo.await`, and taking a reference with that form is significantly more convenient (`for x in &foo` or `for x in foo.iter()` vs `(&foo).await`), it seemed the analogy was stretched pretty thin. So we elected to put more weight on the above two considerations.
>
> That being said, this change would need lang team signoff. You can consider this comment wg-async's official recommendation to the lang team.

TC: There's now been a crater run done for this. The result was that this breaks a small number of crates, but at least one of those crates has a large number of dependents (`aws-smithy-runtime`). It can be fixed in the dependency in such a way that dependent crates do not have to make changes, but those dependent crates would need to update to a fixed version of the dependency.

(See this [discussion](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Perform.20autoref.2Fautoderef.20on.20.2Eawait.20-.20.23111773).)

TC: What do we think?

### "types team / lang team interaction" rust#116557

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

TC: nikomatsakis nominated this:

> We had some discussion about types/lang team interaction. We concluded a few things:
>
> * Pinging the team like @rust-lang/lang is not an effective way to get attention. Nomination is the only official way to get attention.
> * It's ok to nominate things in an "advisory" capacity but not block (e.g., landing a PR), particularly as most any action can ultimately be reversed. But right now, triagebot doesn't track closed issues, so that's a bit risky.
>
> Action items:
>
> * We should fix triagebot to track closed issues.

TC: What do we think?

## Action item review

- [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals

None.

## PRs on the lang-team repo

### "Add soqb`s design doc to variadics notes" lang-team#236

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

### "Update auto traits design notes with recent discussion" lang-team#237

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

## RFCs waiting to be merged

### "RFC: patchable-function-entry" rfcs#3543

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

## `S-waiting-on-team`

### "offset: allow zero-byte offset on arbitrary pointers" rust#117329

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

### "Better errors with bad/missing identifiers in MBEs" rust#118939

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

### "privacy: Stabilize lint `unnameable_types`" rust#120144

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

### "Don't make statement nonterminals match pattern nonterminals" rust#120221

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

### "debuginfo: Stabilize `-Z debug-macros`, `-Z collapse-macro-debuginfo` and `#[collapse_debuginfo]`" rust#120845

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

### "restrict promotion of `const fn` calls" rust#121557

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

### "[ptr] Document maximum allocation size" rust#116675

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

### "warn less about non-exhaustive in ffi" rust#116863

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

### "Rename `AsyncIterator` back to `Stream`, introduce an AFIT-based `AsyncIterator` trait" rust#119550

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

### "Allow `#[deny]` inside `#[forbid]` as a no-op with a warning" rust#121560

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

### "Experimental feature postfix match" rust#121619

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

## Proposed FCPs

**Check your boxes!**

### "unsafe attributes" rfcs#3325

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

### "RFC: Syntax for embedding cargo-script manifests" rfcs#3503

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

### "add float semantics RFC" rfcs#3514

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

### "Tracking issue for function attribute `#[coverage]`" rust#84605

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

### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418

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

### "Add `REDUNDANT_LIFETIMES` lint to detect lifetimes which are semantically redundant" rust#118391

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

### "privacy: Stabilize lint `unnameable_types`" rust#120144

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

### "Let's `#[expect]` some lints: Stabilize `lint_reasons` (RFC 2383) " rust#120924

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

### "RFC: inherent trait implementation" rfcs#2375

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

### "MaybeDangling" rfcs#3336

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

### "Add text for the CFG OS Version RFC" rfcs#3379

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

### "RFC: New range types for Edition 2024" rfcs#3550

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

### "Stabilise inline_const" rust#104087

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

### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378

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

### "[ptr] Document maximum allocation size" rust#116675

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

### "Stabilize Wasm target features that are in phase 4 and 5" rust#117457

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

### "Stabilize Wasm relaxed SIMD" rust#117468

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

### "Stabilize associated type position impl Trait (ATPIT)" rust#120700

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

### "Allow `#[deny]` inside `#[forbid]` as a no-op with a warning" rust#121560

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

### "regression: let-else syntax restriction (right curly brace not allowed)" rust#121608

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

## Active FCPs

### "Reserve `gen` keyword in 2024 edition for `Iterator` generators " rfcs#3513

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

## P-critical issues

None.