---
title: Triage meeting 2023-10-18
tags: T-lang, triage-meeting, minutes
date: 2023-10-18
discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-10-18
url: https://hackmd.io/cjKzvTMER_O9Df4PRo5zsg
breaks: false
---

# T-lang meeting agenda

- Meeting date: 2023-10-18

## Attendance

- Team members: Josh Triplett (JT), Niko Matsakis (NM), Tyler Mandry (TM\), scottmcm, pnkfelix (FK), TC (T-lang-ops)
- Others: waffle

## Meeting roles

- Minutes, driver: TC

## Scheduled meetings

- 2023-10-11: "Meeting proposal: Unsafe extern blocks" [#223](https://github.com/rust-lang/lang-team/issues/223)
- 2023-10-18: "Design meeting: Decide about the future for consts in patterns" [#220](https://github.com/rust-lang/lang-team/issues/220)
- 2023-10-25: "Design meeting: Implementable trait aliases" [#224](https://github.com/rust-lang/lang-team/issues/224)

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

## PRs on the lang-team repo

### "Add size != stride to frequently requested changes" lang-team#216

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

TC: This PR has been hanging out awhile even after the FCP completed. If someone wants to flip the bit that would let me do it, I'll merge it. I'd also use that bit to start posting the minutes to GitHub.

NM: I'll flip the bit.

JT: +1. Seems sensible for the person writing the minutes to post them.

## RFCs waiting to be merged

### "RFC: Unicode and escape codes in literals" rfcs#3349

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

NM: I'll open an issue/PR to flip the bit.

JT: It's probably a teams repo where that needs to happen.

### "Add `f16` and `f128` float types" rfcs#3453

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

TC: As above.

## Nominated RFCs, PRs, and issues

### "Make `#[repr(Rust)]` and `#[repr(C)]` incompatible with one another" rust#116829

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

TC: CE nominated this for us.

TC: Apparently, on beta, `#[repr(C, Rust)]` compiles successfully. This was nominated to confirm that we don't want that.

fmease: Further, should `#[repr(Rust, simd)]` be forbidden, too? `#[repr(C, simd)]` already gets rejected.

JT: Sure sounds like a compiler error.

pnkfelix: Do we know how long-standing this bug is?

waffle: `#[repr(Rust)]` was introduced in a recent PR.

JT: Probably shouldn't be able to `#[repr(Rust, i8)]` either?

pnkfelix: Why not?

JT: They're asking for contradictory things. `repr(Rust)` allows niches, `repr(uN)`/`repr(iN)`.

pnkfelix: We could disallow that in the short term.

JT: The other one mentioned was `#[repr(Rust, simd)]`.

waffle: this is currently accepted on nightly:

#[repr(Rust, u8)]
enum S {
    A, B(u8)
}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=3646c815ed3674d70e8a1974f04c0bcb

pnkfelix: Maybe we should enumerate what is allowed.

JT: `#[repr(Rust, packed)]` and `#[repr(Rust, aligned(N))]` are the ones that make sense for now.

scottmcm: `#[repr(Rust, transparent)]`?

JT: Transparent is disallowed because it disallows combining with anything else currently.

scottmcm: I'd like to kill `repr(Rust, packed)`...

tmandry: The nomicon says that `packed` does apply to `#[repr(Rust)]`.

scottmcm: We should probably allow it (`Rust, packed`) even if it makes us sad.

JT: I think that reduces to "packed makes us sad".

pnkfelix: Ralf said that, looking at the code, `packed` is equivalent to `(C, packed)`.

scottmcm: Maybe we should lint to tell people who write `packed` that they mean and should write `C, packed`.

JT: The reference says `packed` uses the "default representation" unless you say `C, packed`. Of course, the reference could be wrong.

waffle: We don't guarantee any representation for `repr(Rust)`, so it always being C is OK.

scottmcm: I propose we allow it. This isn't the time/place to express our unhappiness with packed or with how we stuff reprs into the attributes.

JT: :+1:

scottmcm: As an example of the problem, we're seeing now that `packed` is a modifier on something but `transparent` is not. (And maybe it would make sense to reflect some of these differences in syntax, but this change is not the time for that.)

JT: Let's ping T-opsem to check (and to check and possibly update the reference).

waffle: I'll leave a note in the PR.

Consensus:
- Allow `Rust, aligned(N)`.
- Allow `Rust, packed`.
- Disallow any other `Rust, ...`.

### "Do not inline integer literals which are out of range in format_args!" rust#116633

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

TC: CE nominated this for us. It seems that we accidentally stabilized [this](https://github.com/rust-lang/rust/issues/115423):

fn main() {
    println!("{}", 0x8Fi8); // OK?
         // prints 143 !!!!!
}

TC: The question seems to be whether we want to break it.

pnkfelix: This has been allowed since 1.70. It might have been gated then.

nikomatsakis: Is there a lint for this?

scottmcm: No, it's worse. It prints "200" for the following, which is "impossible" for i8.

fn main() {
    println!("{}", 200_i8); // OK?
}

waffle: It inlines it into the string.

TC: It's converting these to 128-bit numbers before inlining.

JT: I propose we fix this and let the usual release crater runs check it.

tmandry: +1, let's fix the bug.

Urgau: there was a crater run: https://github.com/rust-lang/rust/pull/116633#issuecomment-1761228862 (no regression found, I think)

scottmcm/pnkfelix: I can't imagine anyone would want to rely on this.

NM: It's definitely a bug.

JT: +1. Also, this is a lint that someone could turn off.

scottmcm: But it would wrap around.

scottmcm: I'll leave a comment.

Consensus: This is a bug. Let's fix it.

### "Tracking Issue for const `mem::discriminant`" rust#69821

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

TC: This needs T-lang members to check off, none have yet, and it seems easy to do in this case.

JT: All four of the people with unchecked boxes are in this meeting.

tmandry: Are there any considerations to be aware of?

scottmcm: Now that we have pointer const, this isn't really exposing anything. It doesn't particulary scare me.

TC: This is now entering FCP. I'll unnominate.

*Consensus*: Let's do this.

### "Stabilize `const_maybe_uninit_zeroed` and `const_mem_zeroed`" rust#116218

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

TC: Similarly, this is another constification needing T-lang attention.

scottmcm: Ralf said this one looks good. With unions in const you can already kind of do this.

tmandry: ...

scottmcm: From a lang side, we could add an intrinsic for zeros.

NM: What's Ralf mean by "internal mutable reference support"?

scottmcm: It'd be bad if the caller could get the reference, but they can't, it's internal, so it's OK.

NM: I'll ask a question in the ticket.

*Consensus*: We'll wait to hear back on that question and discuss again.

### "Guarantee `char` layout" reference#1401

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

TC: @ehuss nominated this. The question seems to be whether we're OK with this language:

> ## Layout and bit validity
>
> `char` is guaranteed to have the same size and alignment as `u32` on all platforms.

JT: I'm assuming this phrasing does not preclude us from later doing move-only data types.

tmandry; If you mean string types, then I agree.

JT: If you have a char, you could do clever niche tricks that would be visible if there's a reference.

NM: You mean things to which you can't take references?

JT: Right. E.g. packing a `char` and three `bool`s into a `u32`.

scottmcm: This reminds me of the NPO guarantee.

JT: I'd be fine with a consensus with or without the point I raised. We could leave it up to the reference folks.

JT: We don't already say this in the std docs.

JT: https://doc.rust-lang.org/std/option/index.html#representation

scottmcm: I was actually expecting a PR to the std docs. We've been FCPing other such guarantees there.

scottmcm: Maybe if we merge this, we should also then merge a PR in std.

TC: Proposal is to merge this verbatim.

NM: +1.

tmandry: And we can leave a comment that the std docs should also be updated.

Josh: I'll leave that comment.

TC: I'll unnominate.

*Consensus*: Let's do this. The std docs should also be updated, but that can be done separately.

### "Stabilize Ratified RISC-V Target Features" rust#116485

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

TC: This PR stabilizes ratified RISC-V target features.

> - Atomic Instructions (A) on v2.0
> - Compressed Instructions (C) on v2.0
> - Integer Multiplication and Division (M) on v2.0
> - Bit Manipulations (B) on v1.0 listed as `zba`, `zbc`, `zbs`
> - Scalar Cryptography (Zk) v1.0.1 listed as `zk`, `zkn`, `zknd`, `zkne`, `zknh`, `zkr`, `zks`, `zksed`, `zksh`, `zkt`, `zbkb`, `zbkc` `zkbx`

TC: @tmandry and @scottmcm have reviewed and given +1.

tmandry: I don't think there's anything controversial in this PR.

pnkfelix: What do all the crossed out things mean?

tmandry: They were removed from this stabilization discussion. This is due to how a target feature can impact the ABI.

tmandry: All of these have been approved by the RISC-V ratification process.

TC: This is going into FCP. I'll unnominate.

Consensus: Let's do this.

### "Reserve `gen` keyword in 2024 edition and start an experiment implementation of `Iterator` generators " rfcs#3513

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

TC: We discussed this last week on 2023-10-10 in the context of an earlier [issue](https://github.com/rust-lang/rust/pull/116447). We were feeling positive about reserving the keyword in the 2024 edition given the progress, and we wanted an RFC that described what was known about how `gen` / `iter` blocks should work. We were OK with the RFC leaving undecided questions that were still open. This RFC has now been posted.

TC: This is something we need to decide ahead of the 2024 edition. Is there anything we should discuss about it this week to move forward?

TC: tmandry, you had raised a point about this phrasing itself as an e-RFC.

(Discussion about that.)

JT: We introduced the `k#` mechanism to allow a keyword to be used immediately. Is the rationale that we don't expect it to be stabilized before the 2024 edition?

tmandry: Correct.

NM: It'd be worth writing out our edition policies. We've resisted reserving keywords speculatively. This feels different because we know we want this for an upcoming feature.

pnkfelix: Right.

NM: We know exactly what we want to use it for, and we have high certainty on the keyword.

JT: And we have `yield` reserved.

NM: I don't want to reserve this and then end up with a different keyword.

JT: We do have to complete the bikeshed before the edition.

TC: Oli had revised the RFC to *not* use the keyword for the initial experiment to try to help the RFC land more quickly. Would we actually prefer for the RFC to just make a decision on the keyword and commit to it?

JT: Honestly yes.

NM: Kicking the can down the road isn't any good. This RFC is to hash out the keyword. Of course we can change our mind (with expense).

scottmcm: I liked niko's phrasing of "RFC is for 'how will people experience this feature'".

scottmcm: Oli could put this in the compiler with attributes without an RFC.

JT: We should go ahead and settle it. And let's reserve the keyword.

NM: Sounds good to me. Sounds like we're aligned.

waffle: I'm concerned about the section on how we handle self-referential generators. It seems to me that generators will mostly be self-referential, as futures are.

tmandry: Agreed it's an important question. But the current RFC implies that another RFC will be required.

NM: There is no way we're doing this without self borrows.

JT: We can decide at stabilization time whether there are any one-way doors.

NM: It does have those doors. This feels like something that would be an unresolved question. The RFC could list the patterns that we want to have work. It feels silly to block when we know that we'll find some solution.

TC: I'm planning to revise the RFC to remove the language requiring a new RFC. It'll be a regular RFC.

waffle: We should do this like we did with tail calls.

NM: Agreed it should be a normal RFC.

JT: Is this going to be labeled experimental?

NM: No. Experimental RFCs are a dead process. Once there's an RFC, the team has said it's in favor of that direction. The RFCs are a way to get community feedback.

TC: And I'll revise also to remove the attribute syntax and have the RFC commit to the `gen` keyword.

scottmcm: +1.

NM: The self-borrowing can be an unresolved question, but I wouldn't object to it being spelled out either. But either way, if we spell out the patterns that we want to make work, we could maybe eventually stabilize on that basis.

scottmcm: "We are hoping to allow self-referential generators under this framework, but might need a new RFC if it turns out to not work." But that's how implementing features goes.

*Consensus*: TC and Oli will revise the RFC.

- We are in favor of `gen` keyword.
- We want generators and we want to reserve it for 2024.
- We *think* we want self-borrowing generators, but we want to better understand what it means, so this should be an unresolved question and we will decide later if a follow-up RFC.
- Ideal is to enumerate the usage patterns we know we want to work (e.g., `for` loop) and show what generators might mean for them.

(The meeting ended here.)

### "Lifetime Capture Rules 2024" rfcs#3498

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

TC: FCP merge has been proposed. Given that RPITIT relies on this behavior and will be stabilized in Rust 1.75, it would be good to move this RFC forward before we start announcing RPITIT more widely. It's also, of course, related to the 2024 edition. Is there anything we can discuss to move this forward?

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

### "Decision: semantics of the `#[expect]` attribute" rust#115980

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

TC: @nikomatsakis gives this background:

> This issue is spun out from #54503 to serve as the decision issue for a specific question. The question is what the 'mental model' for the `expect` attribute should be. Two proposed options:
>
> 1. The expectation is fulfilled, if a #[warn] attribute in the same location would cause a diagnostic to be emitted. The suppression of this diagnostic fulfills the expectation. ([src](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Expect.20attribute.20mental.20model/near/341522535)) (Current implementation in rustc)
> 2. The expectation is fulfilled if removing the `#[expect]` attribute would cause the warning to be emitted. ([src](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Expect.20attribute.20mental.20model/near/354082551))
>
> @xFrednet created a [list of use cases](https://hackmd.io/@xFrednet/expect-attr-use-cases) to help with the discussion of these two models; they found both models work equally well, except for [use case 4](https://hackmd.io/@xFrednet/expect-attr-use-cases#Use-case-4-Suppress-lints-from-CI) which would only be possible with the first model.

TC: ...and proposes that we adopt option 1.

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

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

TC: In the 2023-10-10 meeting, we discussed this. The main open question is whether these lifetimes should be higher ranked. We decided we wanted an analysis that went deeper than just pointing out consistency with an accidental stabilization (and we were hoping to get feedback from @nikomatsakis). @tmandry has now done that [analysis](https://github.com/rust-lang/rust/pull/107378#issuecomment-1767448648).

### "`.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 (and for T-types) 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.

### "Tracking Issue for the Rust specification" rust#113527

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

TC: On 2023-10-12, pnkfelix [posted](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/unsticking.20us/near/396373682) a [vision document](https://hackmd.io/R_YYc4dXQCuOhCHPjqqudA) for the Rust specification. We all might want to have a look at that.

### "Support overriding `warnings` level for a specific lint via command line" rust#113307

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

TC: We discussed in the 2023-09-26 meeting, but were unsure of the question we were being asked. @jieyouxu has since replied:

> I believe I wanted to ask that if the command line indeed forms the root of the tree, or if it actually overrides the source annotations.

TC: On that basis, @tmandry replied:

> ### Nesting
> I think the command line (specifically `-A`, `-W`, `-D` flags) should form the root of the tree. We have `--cap-lints`, `--force-warn`, and `-F` (forbid) for overriding the source. (Actually the mental model documented in the [rustc book](https://doc.rust-lang.org/rustc/lints/levels.html) is that `force-warn` and `forbid` still form the root of the tree, but cannot be overridden; I think the distinction is mostly academic.)
>
> That's almost all the expressive power one could want along this axis. One wrinkle is that `--forbid` is overridden by `--cap-lints`, while `--force-warn` is not. If we wanted full fine-grained control we could always add `--force-allow` and `--force-deny`.
>
> ### `warnings`
> Regarding the meaning of `warnings`, it _is_ a simpler mental model for this to mean "the set of things that are warn-by-default". But this ignores what I perceive to be a common (and valid) use case, which is to disallow _all_ warnings in a codebase: In other words, prevent code from being checked in that causes warnings to be printed to a user's screen. Of course, for this to be practical one must control the version of rustc being used to build a codebase, but that is common in monorepo setups.
>
> ### Conclusion
> Given that there is an existing use case that relies on documented behavior, I think we should continue to treat `warnings` as a "redirect" for all warnings that come out of a particular level of the tree. Interpreting `-Awarnings -Wfoo` in the way proposed by this PR would muddy the (already complicated) mental model and add inconsistency between CLI and the command line, as noted by @oli-obk.
>
> A different group, like `default-warnings`, could be used to mean "the set of things that are warn-by-default". The compiler could further warn users that specify `-Awarnings -Wfoo` on the command line to use `-Adefault-warnings -Wfoo` instead.

### "Fix `non_camel_case_types` for screaming single-words" rust#116389

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

TC: @petrochenkov nominated this for us:

> A relaxed version of this PR could be bumping the length limit from 3 letters to 4. E.g. `ABC` would still be considered camel case, but `ABCD`/`ABCDF`/etc not.

This is related to [#116336](https://github.com/rust-lang/rust/issues/116336) and [#60570](https://github.com/rust-lang/rust/issues/60570).

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

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

TC: The following syntax is being proposed for addition to Rust:

#!/usr/bin/env cargo

[dependencies]
clap = { version = "4.2", features = ["derive"] }

use clap::Parser;

### "MaybeDangling" rfcs#3336

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

TC: We [discussed](https://hackmd.io/ifgF0ThcTSWvKnYRWEM8nw) this in an RFC read on 2023-09-27. The consensus was that someone would proposed FCP merge, but that has not yet been done.

### "Non-temporal stores (and _mm_stream operations in stdarch) break our memory model" rust#114582

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

TC: We [discussed](https://hackmd.io/ZJiCNtIwTE2V2arUsabJ6g) this on 2023-08-15.

> @**RalfJ** points out that certain compiler intrinsics don't fit within the memory model of the Rust Abstract Machine. For this one in particular, in the time between doing a non-temporal store and before doing a store fence, things are a bit nuts. But this has a performance benefit as it bypasses the cache, so "fixing" it by eliminating the performance benefit isn't a good option. The meeting consensus was to table this while looking for ways to raise awareness. As @**scottmcm** said, "it wouldn't be the first thing you could do in unsafe that turns out to be sketchy."

TC: Some [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-08-15) followed about this issue after the meeting.

TC: We further [discussed](https://hackmd.io/YCOGGiHWQOGqFzj_ws2-rQ) this in the 2023-10-10 meeting without resolution. We raised the question of whether adding a lint might be a good step forward.

### "RFC: Implementable trait aliases" rfcs#3437

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

TC: This RFC has also been proposed for a design meeting as an RFC read, but it has not yet been scheduled for one.

TC: We discussed this in the 2023-09-26 triage meeting. We decided that this needed more discussion and that we'd leave a comment about what was discussed in the issue. Niko has [posted](https://github.com/rust-lang/rfcs/pull/3437#issuecomment-1736102047) that comment.

### "dyn Trait comparison should not include the vtable pointer" rust#106447

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

TC: The FCP to close this issue has been completed. However, @Amanieu is still [looking](https://github.com/rust-lang/rust/issues/106447#issuecomment-1566147477) for a way forward. There's been some [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/dyn.20Trait.20pointer.20comparisons) on Zulip about this.

TC: We discussed this in the 2023-09-26 triage meeting without a full resolution, but decided that adding `ptr::addr_eq` may be one small step forward. @pnkfelix proposed this [in the ticket](https://github.com/rust-lang/rust/issues/106447#issuecomment-1741849318) and then [to T-libs-api](https://github.com/rust-lang/libs-team/issues/274). @dtolnay seconded the request and asked for a PR.

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

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

TC: We discussed in the 2023-09-26 meeting. We decided to simply let T-libs-api know about what we had discussed. Niko [left a comment](https://github.com/rust-lang/rust/pull/106418#issuecomment-1736377423) to the effect that "right now we seem to have no good options."

TC: There has since been further discussion on the issue. E.g., Amanieu noted:

> While discussing this in the libs-api meeting today, we noticed that the documentation for `mem::discriminant` [doesn't guarantee stability for the discriminant](https://doc.rust-lang.org/nightly/std/mem/fn.discriminant.html#stability). This means that the actual ordering of `Discriminant` is _not_ tied to the source code order of the variants.
>
> This makes it unsuitable for many use cases, including the one in the PR description, which is to manually implement `Ord` for an enum. To enable this use case, we need to guarantee that the ordering of `Discriminant` matches that of the variants in the source code.

### "Disallow *references* to `static mut` [Edition Idea]" rust#114447

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

TC: We discussed on 2023-09-05 and the consensus was in favor of going in this direction. We left a comment with the path forward and labeled it `E-help-wanted`.

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

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

TC: We're waiting on @oli to investigate an unexpected incremental build-time regression. I made sure that @oli knows that, and knows that we resolved the fundamental question that was blocking this earlier in RFC 3477.

## Action item review

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

## Pending lang team project proposals

None.

## `S-waiting-on-team`

### "Tracking issue for dyn upcasting coercion" rust#65991

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

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

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

### "remove 'illegal_floating_point_literal_pattern' future-compat lint" rust#116098

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

## Proposed FCPs

**Check your boxes!**

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

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

### "unsafe attributes" rfcs#3325

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

### "Lifetime Capture Rules 2024" rfcs#3498

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

### "Tracking issue for dyn upcasting coercion" rust#65991

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

### "Tracking Issue for const `mem::discriminant`" rust#69821

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

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

### "TAIT defining scope options" rust#107645

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

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

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

### "FCP process: Require 2/3 majority for FCP" rust#114986

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

### "`c_unwind` full stabilization request: change in `extern "C"` behavior" rust#115285

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

## Active FCPs

### "Guarantee representation of None in NPO" rust#115333

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

### "document ABI compatibility" rust#115476

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

## P-critical issues

None.