---
title: Triage meeting 2023-09-05
tags: triage-meeting, minutes, T-lang
date: 2023-09-05
url: https://hackmd.io/4Tr_OZLHRkmpiQlCP8bDsw
discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-09-05
---

# T-lang meeting agenda

* Meeting date: 2023-09-05

## Attendance

* Team members: nikomatsakis, tmandry, joshtriplett, scottmcm
* Others: TC, lokathor, eholk

## Meeting roles

* Minutes, driver: TC

## Scheduled meetings

- (done) "Extern types V2 RFC" [#211](https://github.com/rust-lang/lang-team/issues/211)

Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.

## Announcements or custom items

### Pre-RFC describing mechanism to remove orphan rule constraints #3482

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

Lokathor: Mentioned https://github.com/rust-lang/rfcs/pull/3482, if we can't do this soon due to bandwidth or other issues we should say so sooner than later.

Niko: This is one of the major challenges we have in the language; so I'm open to ideas to improve it.

Josh: This is delegating the ability to make impls of your trait to another crate in a workspace. It seems useful, but also orthogonal to us fixing the orphan rule more broadly. This is not a solution to the AB problem. But on the other hand, the solution to the AB problem would also solve this.

Josh: We've talked about allowing orphaned impls as long as all implementations are identical (no conflicting implementations unless they're identical).

Niko: I feel like this is the recipe for inaction we often hit. Perhaps we should talk to jsgf about working on this?

Josh: Agreed. We could pass along some of the thoughts from this meeting.

Niko: There's a use case for this specific RFC that comes to mind from the smithy project. Smithy uses the code generation pattern where it generates a readonly base crate and the user is expected to add a crate that has the base crate as a dependency. But then the user can't add impls of different traits to those types defined in the base crate.

Josh: We could have an opt-in mechanism for the trait creator.

scottmcm: We should probably table the design discussion.

Niko: Who is going to follow up with jsgf?

Josh: I'll write that.

## Nominated RFCs, PRs and issues

### "Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024" rust#112038

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

TC: RalfJ nominated this with a question:

> I have nominated this PR for lang-team discussion. The question for t-lang is pretty clear -- should the default lint level of `unsafe_op_in_unsafe_fn` be raised to warn, and if yes, in which editions?

Niko: I'd say yes.

Josh: I'd say let's FCP to get consensus on yes.

Niko: Is anyone saying not to?

Lokathor: We should warn in the current edition.

scottmcm: There was conversation that we shouldn't do a 180 within a single edition.

Lokathor: It's a compiler version difference; not an edition difference in how we shift policies.

scottmcm: So we'd do this across all editions?

Niko: We did RFC an agreement to prioritize agreement across editions. That would suggest we should make this a warning full stop.

scottmcm: The churn is very high.

Niko: We could phase things in over time.

Josh: Editions can be a canary mechanism. People migrate timely. If we put out the 2024 edition with a warning, they'll fix their code. Then after some amount of time, there will be less of this code in the ecosystem. Then we could change to warning on all editions.

Niko: ...I buy that.

Josh: Someone said we agreed to not make this a hard error. Are we sure? That could be an edition change.

scottmcm: I'm one of the most skeptical, but I wouldn't rule it out.

Josh: ...I buy that. We can give ourselves time to make that decision, and look at how people deal with this lint as input for that decision.

scottmcm: ...similarly, we can look on crater to see how this works out, and see if many people are allowing this lint.

tmandry: Do we have a `cargo fix` for this lint?

scottmcm: We should have a `cargo fix` for this.

TC: Maybe having a comprehensive `cargo fix` would make us more willing to make this change.

scottmcm: I remember us talking about this and how the `cargo fix` should work.

Lokathor: I've had examples in `-sys` crates. In those places, I'd just turn this off.

TC: Do we have any partial answers here for RalfJ?

Josh: Let's propose FCP on doing this in 2024. Then we could separately FCP doing this in other editions.

Niko: We should make a request for someone to work on an automation for `cargo fix`.

scottmcm: Should we block on a `cargo fix`?

Josh: A simpler `cargo fix` would have lower value; a more complicated one would be harder to do. I think we should go ahead and warn without a `cargo fix`.

Niko: Agree with Josh.

scottmcm: I'll propose FCP.... actually, it looks like we FCPed this. Already FCPed in <https://github.com/rust-lang/rust/issues/71668#issuecomment-1189396860>

Josh: We should propose a new FCP for doing this without a `cargo fix`.

scottmcm: Actually, an automation is already present.

scottmcm: I'll leave a comment.

### "closure field capturing: don't depend on alignment of packed fields" rust#115315

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

TC: RalfJ nominated this:

> Nominated for t-lang discussion. This is a breaking change that fixes a semver hazard. The PR description contains an example of a piece of code where changing the type of a private field from `u8` to `u64` changes what exactly a closure captures, and therefore changes the order in which two lines are printed (or arbitrary other behavioral differences).
>
> The breaking change only affects code where a closure captures fields of a packed struct (or fields nested inside a packed struct's fields) by-reference and those fields have alignment 1. Such code used to capture the nested inner field; after the PR it instead captures a reference to the entire packed struct. For the example from the PR for instance, this means that both versions (with `u8` and `u64` for the private field) behave the same way that the `u64` variant behaves today.

Josh: It sounds like there are not observed issues with crater.

Josh: The new behavior is that field captures don't project into packed fields.

Niko: Sounds right. Feels like a bug fix.

scottmcm: +1.

Niko: This would be a good case for a better spec.

scottmcm: Maybe MIR should block projections into weird things.

scottmcm: Closure capture into a `#[repr(simd)]` struct would be interesting.

Josh: Let's FCP merge on this change. I've done that.

### "document ABI compatibility" rust#115476

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

TC: RalfJ nominated this:

> I don't think we have any central place where we document our ABI compatibility rules, so let's create one. The `fn()` pointer type seems like a good place since ABI questions can only become relevant when invoking a function through a function pointer.
>
> This will likely need T-lang FCP.

TC: This came out of an interesting discussion on Zulip over the last week.

Lokathor: This is a big change. Maybe we should discuss next week after we read it.

scottmcm: +1.

Josh: Do we want to read and discuss next week, or do we want to say we want to do this but want to look into the details, because then we should just FCP merge it.

pnkfelix: Another alternative would be a design meeting... but I largely agree with Josh.

Josh: Tomorrow is the planning. We could use the rest of the planning meeting tomorrow to read this.

scottmcm, TC: +1.

Niko: What's the T-opsem take on this.

pnkfelix: Did T-opsem discuss this?

Lokathor: I don't recall it being covered recently there.

scottmcm: I like the argument this is more T-opsem.

Lokathor: Most of this PR is already writing down existing thoughts on the issue.

tmandry: So we're FCPing the documentation.

Lokathor: And the docs could change if we find something new.

pnkfelix: Let's FCP merge and nominate for T-opsem. I'll do that now.

### "repr(transparent): it's fine if the one non-1-ZST field is a ZST" rust#115334

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

TC: RalfJ nominated this:

> This code currently gets rejected:
>
> ```rust
> #[repr(transparent)]
> struct MyType([u16; 0])
> ```
>
> That clearly seems like a bug to me: `repr(transparent)` [got defined ](https://github.com/rust-lang/rust/issues/77841#issuecomment-716575747) as having any number of 1-ZST fields plus optionally one more field; `MyType` clearly satisfies that definition.
>
> This PR changes the `repr(transparent)` logic to actually match that definition.

Josh: So this is transparently empty.

scottmcm: From the T-lang perspective, yes, we agreed it should do that. So it's worth fixing.

Josh: We already FCPed it. So we should just say yes. Let's unnominate and comment that we FCPed this.

scottmcm: I'll take that.

### "we reserve the right to reduce our amount of UB" reference#1397

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

TC: RalfJ submitted this PR:

> It was pointed out to me that the docs currently say that the things on the UB list are definitely UB. That's not true, we do reserve the right to have less UB in the future. (Exactly that is happening e.g. in #1387.)

TC: And pnkfelix nominated:

> I want to discuss this at the @rust-lang/lang design team meeting. In particular, on the [associated zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/237824-t-lang.2Fdoc/topic/we.20reserve.20the.20right.20to.20reduce.20our.20amount.20of.20UB/near/387027064) where I asked why someone would _want_ the prior interpretation of this text, a couple interesting cases were described:
>
> * I hypothesized, as a [strawman](https://rust-lang.zulipchat.com/#narrow/stream/237824-t-lang.2Fdoc/topic/we.20reserve.20the.20right.20to.20reduce.20our.20amount.20of.20UB/near/387048107), that compiler optimization authors want it so they don't have to update their code when the language spec changes
> * @chorman0773 [pointed out](https://rust-lang.zulipchat.com/#narrow/stream/237824-t-lang.2Fdoc/topic/we.20reserve.20the.20right.20to.20reduce.20our.20amount.20of.20UB/near/387069939) that some API's might be written in a way where they just say "precondition: `*x` is a legal operation", and then treat the implications of that according to this list **at the time when they are writing the API** as something they can assume for all time.
> * @RalfJung pointed out their own motivating case, which is verification tools that want to similarly make [assumptions in their reasoning](https://rust-lang.zulipchat.com/#narrow/stream/237824-t-lang.2Fdoc/topic/we.20reserve.20the.20right.20to.20reduce.20our.20amount.20of.20UB/near/387149252) based on the UB list.

Josh: Yes, this seems great. It would be a problem if people interpreted things the other way.

Niko: I'm fine with this, except that at some point, I think that... currently rayon requires that it's UB to pop its stack frames or skip over its destructors. We should say this here, but we have to put some bottom limits so people can write unsafe code. Right now doing `longjmp` over arbitrary stack frames is UB. If we change that, then `rayon` would become unsound.

Josh: ...if we define it in a way that makes existing code unsound. (We could define it in a way that doesn't.)

Niko: Removing UB can cause sound code to become unsound. We need a more refined notion.

pnkfelix: That sounds like another instance of something pointed out in the ticket.

pnkfelix: It's not quite the same.

Niko: I think we should do this.

pnkfelix: Niko, add a comment, if you would.

Josh: By FCPing this, we're not saying we'll never make some things UB in the future. I just posted a GitHub suggestion along the lines of your point.

Niko: My preference is to guarantee what will happen, e.g. when a stack frame is called. Then the UB is implied. That's the framing I like.

scottmcm: We could split out what will always be UB. Some things we just know will never happen.

Lokathor: Some of those fall out of the rules for other things. E.g. jumping between local variables.

Niko: I'll FCP merge it.

### "Handling of packed fields causes semver hazard: layout details from other crates affect type-checking" rust#115305

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

TC: RalfJ nominated this:

> This is very similar to #78586: we have another situation where the compiler calls `layout_of` to determine whether some code should compile or how it should be compiled, but `layout_of` completely ignores visibility and crate boundaries, thus creating a semver hazard.
>
> This issue is about packed fields. When `S` is a `packed(N)` type, and we write `&s.field`, then this will be allowed by the compiler iff the type of `field` requires alignment no more than N. This has 2 semver consequences:
>
> - If you have a packed struct with public fields, it is a breaking change to make it "more packed" by reducing the N -- that part is probably fine, it is similar to how it is obviously a breaking change to add `repr(packed)` in the first place.
> - _Increasing_ the alignment of a type can be a breaking change, if that type is ever used as the type of a public field in a packed struct (including in a nested way, for cases like `&s.field.inner_field`). This might not be what we want, at least I recall @scottmcm being concerned about this.
>
> ...

Josh: The layout of a packed type relies on the details of the things within it, even if those shouldn't be relied upon.

Josh: This is broader than the earlier one. Packed fields make things tricky between crates.

scottmcm: This is a case of the "we have no way to commit to a layout" problem. Equivalent problem with `repr(transparent)`: <https://github.com/rust-lang/rust/issues/78586> or more generally <https://github.com/rust-lang/rust/issues/114391>.

Niko: Yes, it seems like the same problem.

Josh: There are two uses of packed that are worth considering. Some people need to lay out a structure in a way that is hardware compatible with something. The other case is for optimization. The latter case seems more likely to run into this hazard.

Josh: One of the options is a warning for when you may be relying on private details. We could do a crater run after that.

tmandry: I like that, and I'd like a mechanism within the type system for this.

scottmcm: Some things we can probably fix as just a bug.

Josh: Do we have consensus to "we would be open to lints to warn about compatibility issues, and we want to see crater runs to see how often the lints trigger?"

tmandry, Niko, scottmcm: +1

Josh: Will post a comment.

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

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

On 2023-08-04, @scottmcm proposed for discussion:

> Now that we have `ptr::addr_of_mut!`, the 2024 edition would be a great time to do @RalfJung's idea from [#53639 (comment)](https://github.com/rust-lang/rust/issues/53639#issuecomment-415487264):
>
> **Disallow `&MY_STATIC_MUT` and `&mut MY_STATIC_MUT` entirely.**
>
> `ptr::addr_of_mut!(MY_STATIC_MUT)` could even be safe -- unlike taking a reference which is `unsafe` and often insta-UB -- and helps encourage avoiding races in the accesses, which is more practical than trying to avoid the UB from concurrent _existence_ of references.
>
> (Maybe people will end up just doing `&mut *ptr::addr_of_mut!(MY_STATIC_MUT)` anyway, but we can't force them to drink.)

scottmcm: I wanted a straw-poll feeling on this. This is an old RalJ idea from 2018.

Niko: +1.

Lokathor: Can you make methods that target a pointer?

scottmcm: Probably not, but you can target a ref `RacyUnsafeCell`.

Josh: This isn't making `mut static` disallowed; it's making references to it disallowed?

scottmcm: Yes, this is a case where it's basically insta-UB.

Josh: Agreed this shouldn't be controversial. Disallowing read-only references would prevent people from...

scottmcm: But if it's a Mutex, it's usually not `static mut`.

Josh: Concern withdrawn.

scottmcm: I'll write a comment that T-lang is +1, and we'll add a help-wanted label.

### "Parse unnamed fields and anonymous structs or unions" rust#114782

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

TC: This is an implementation of the accepted [RFC 2102](https://github.com/rust-lang/rfcs/pull/2102) "Unnamed fields of struct and union type".

TC: Josh proposed this for discussion:

> I don't think there's any proposal currently on the table to have standalone anonymous structs/unions like those, nor much appetite for accepting one and all its associated complexity.
>
> The rationale for accepting these anonymous structs/unions as ty in macros would not be for that; it'd be to preserve the function of macros that are parsing structs as a series of ident/ty pairs (plus attributes).
>
> However, whether we do or don't accept this in ty seems likely to break at least some macros making that parsing assumption. If we don't accept these in ty, macros that try to parse struct/union fields would not work if you use anonymous structs/unions, without adaptation. But if we do accept these in ty, macros that try to parse struct/union fields and do something with them (e.g. declare a function parameter) are likely to break, and we'd also allow more than we might want in all other macros using ty for any other purpose. And I'd expect macros walking a struct field-by-field to want to have special handling for this case anyway, such as walking the fields of a nested anonymous struct.
>
> Given that, my first reaction is that ty should not include anonymous structs/unions. But that should be confirmed by lang. I'll raise this in today's lang meeting.

Josh: This isn't something that `ty` should parse.

Lokathor: If `ty` doesn't parse it now, can it in the future?

Josh: No, I don't think so. We'd have to do this as a two-step over editions (introduce `ty202x` and `ty202y` and migrate what `ty` points to over an edition).

Niko: Every change to `ty` is a breaking change.

Niko: I half buy your argument. Having another fragment identifier is also a plausible solution.

Josh: A macro would want to do this explicitly.

Niko: Agree with that. There should be an explicit way. E.g. `anon_ty`.

Josh: We shouldn't block on a new one, but if someone proposed one, we should consider that. It'd be a convenience, not a new capability (since you can parse it manually as its components).

Niko: It's not a huge blocker, but it will annoy someone at some point.

Niko: This is saying `struct { .. }` should not match `ty`.

Josh: There are multiple potential things we could add: `:anonty` to match the anonymous type, or `:field` to match the name/type pair.

scottmcm: We don't have a matcher for a field name. There are a couple of these things that would make sense.

Niko: I could imagine us allowing anon types as structs.

Josh: But we didn't do that in this RFC. Doing structural types is a big change.

TC: What's our walk-away here?

Niko: We're not going to change `ty`. But we should explore other options.

Josh: I'll make a comment to that effect.

(The meeting ended here.)

### "Aligned-in-packed restriction can be circumvented with generic parameters" rust#80926

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

TC: RalfJ nominated this:

> I feel like we should just remove the aligned-in-packed check. There's probably already code out there relying on its current behavior via generics (even accidentally). And I don't think the behavior is particularly surprising either, `packed` acts on `align` types the same way it acts on all types -- it completely ignores their alignment.
>
> Having types that can be written with generics but not monomorphic is obviously inconsistent, and means the check can at best serve as a lint anyway. We had a [similar situation](https://github.com/rust-lang/rust/issues/77841) with `repr(transparent)` and that got fixed by also allowing the attribute on types where all fields are 1-ZST.
>
> I wonder what @rust-lang/lang thinks about this -- the [original goal](https://github.com/rust-lang/rfcs/pull/1358#issuecomment-217582887) was to avoid having to decide either way for the interaction of packed and align. Different C implementations seem to behave differently: [on MSVC](https://github.com/rust-lang/rfcs/pull/1358#issuecomment-163018963), `__declspec(align(N))` types are fully aligned even in a packed struct; in GCC `__attribute__((aligned(N)))` types behave like all other types in a packed struct. But now that we inadvertently already made a decision to behave like GCC, is it really worth keeping the restriction?

### "Add allow-by-default lint for unit bindings" rust#112380

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

TC: WaffleLapkin nominated this:

> Nominating for T-lang discussion, as they are usually the ones approving lints.
>
> The current lint behavior is described in the PR description. It's designed in such a way that there shouldn't be many false positives (is this the right term? I'm always confusing them...) — as using an explicit unit type, a `()` pattern or a `()` expression will silence the lint.
>
> The only false positive really possible is the case of proc macro using a user provided span for the unit binding. There isn't much to do here and this seems to be an issue with the proc macro implementation, not the lint. See this comment for details: [#112380 (comment)](https://github.com/rust-lang/rust/pull/112380#issuecomment-1612576955).
>
> The **question(s) for the lang team**: do we want to include such lint in the compiler? Is the current behavior the one we want? What should be the default level of this lint (`allow`, `warn`...)?

### "MaybeDangling" rfcs#3336

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

TC: We discussed this 2023-08-22 and our consensus was to table the issue so that we could look more carefully into the situation offline.

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

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

TC: This had been waiting on author. The author then updated. Both Josh and pnkfelix have resolved their concerns. This is now waiting on one checkbox to enter FCP.

### "Cargo Check T-lang Policy" rfcs#3477

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

TC: We agreed on final language in the 2023-08-29 meeting. This is now waiting for one more checkbox (from Josh, Niko, or pnkfelix).

### "Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503

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

TC: Based on feedback from t-lang, @xFrednet [created](https://github.com/rust-lang/rust/issues/54503#issuecomment-1628471905) a [list of use-cases](https://hackmd.io/@xFrednet/expect-attr-use-cases) and is seeking review from t-lang.

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

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

TC: In the 2023-08-29 meeting we decided that we did have reservations and wanted to see what T-libs-api came back with. scottmcm left a comment in the thread to that effect. We're still waiting on the response.

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

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

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

TC: The 2023-08-22 meeting consensus was to write the RFC now posted as rfcs#3477. We're also waiting for a root-cause assessment on an unexpected `check` build-time regression.

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

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

TC: This is in a t-compiler proposed FCP, but @jieyouxu has a [specific question](https://github.com/rust-lang/rust/pull/113307#issuecomment-1628161766) for t-lang.

TC: We [discussed](https://hackmd.io/Hoo205tDQc6vwWAYaYF37g?view#%E2%80%9CSupport-overriding-warnings-level-for-a-specific-lint-via-command-line%E2%80%9D-rust113307) this in the meeting on 2023-07-25 without resolution.

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

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

TC: We've created a new [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr) for this work.

TC: A [job description](https://hackmd.io/tAC6D9SOT1ChxIJ2m1VQ2Q) for the editor has been discussed. There seems to be consensus to move forward on the hiring process.

TC: There is [outstanding discussion](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/the.20name.20of.20the.20doc) on the appropriate name of this document.

TC: There is an outstanding [discussion](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/goals.20.2F.20conformance.20.2F.20just.20describing.20a.20ref.20impl.3F) ongoing about the goals of the specification.

TC: Niko has [proposed](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/selection.20process) to create the team, with pnkfelix and Mara as the leads, and for that team to work to draft a new set of requirements.

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

### "Allow dropping `dyn` trait object's principal" rust#114679

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

TC: The 2023-08-15 meeting consensus was to table this and nominate it for @*T-types* to write up a stabilization report if immediate stabilization is wanted (or otherwise to add a feature gate). We're still waiting on that.

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

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

TC: In the 2023-08-29 meeting we decided to tag this with T-libs-api, untag T-libs, and propose FCP merge. tmandry has done this, and it is now waiting on checkboxes (from Josh, Niko, and pnkfelix on T-lang).

### "const-eval: make misalignment a hard error" rust#115524

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

TC: Oli nominated this:

> Nominating for T-lang team discussion. Don't know if you want to FCP this, as it's already in line with the const UB RFC (if your code exhibits UB at compile-time, but passes, we are allowed to break it later)

TC: RalfJ commented:

> I don't even know of an example where this is a breaking change... So crater seems unnecessary to me.
>
> This is a kind of funny FCP since it turns out the breaking change accidentally happened in [#104616](https://github.com/rust-lang/rust/pull/104616), we're now just removing some dead code.
>
> > Ah, the lint docs actually have an [example of code](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=2597104ff53b9621a58f6241a6f09afe) that did trigger the lint. So this is a breaking change after all.

## Action item review

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

## P-critical issues

None.

## Pending lang team project proposals

None.

## 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: Last week we decided to do this; it's now entering FCP.

## RFCs waiting to be merged

### "Allow cfg-attributes in where clauses" rfcs#3399

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

TC: Last week we agreed this should be merged; pnkfelix is doing that.

## `S-waiting-on-team`

### "Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024" rust#112038

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

TC: This item is nominated; let's discuss it there.

### "closure field capturing: don't depend on alignment of packed fields" rust#115315

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

TC: This item is nominated; let's discuss it there.

### "document ABI compatibility" rust#115476

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

TC: This item is nominated; let's discuss it there.

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

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

TC: This is waiting on T-types.

### "Allow dropping `dyn` trait object's principal" rust#114679

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

TC: This is waiting on T-types.

## Proposed FCPs

**Check your boxes!**

### "unsafe attributes" rfcs#3325

- **Link:** https://github.com/rust-lang/rfcs/pull/3325
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911253):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * ~~change-syntax-to-drop-parentheses~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974
> * ~~maybe-make-this-part-of-next-edition~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458690311
> * syntax-not-ideal (https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911218):
> @rfcbot merge

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

- **Link:** https://github.com/rust-lang/rfcs/pull/3349
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747916):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * ~~raw-byte-strings-with-unicode~~ resolved by https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1688688433
> * ~~waiting-on-update-re-using-char-and-string-tables~~ resolved by https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1688710635
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889):
> I do think we should permit `br"¥¥¥"`, but I don't think we should make any of the other changes proposed in that table, for the reasons @m-ou-se stated.
>
> I'm going to go ahead and propose FCP for this. This does *not* preclude making further changes to how this information is presented.
>
> @rfcbot merge
>
> @rfcbot concern raw-byte-strings-with-unicode

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

- **Link:** https://github.com/rust-lang/rfcs/pull/3453
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3453#issuecomment-1665987694):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @Amanieu
> * [x] @BurntSushi
> * [ ] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3453#issuecomment-1665987676):
> Since we define `f32` and `f64` to be IEEE `binary32` and `binary64`, it seems entirely reasonable to also include `binary16` and `binary128` as well, working analogously.
>
> Let's see what others think:
> @rfcbot fcp merge
>
> Though I do expect that this will be non-trivial to stabilize, in terms of implementation effort, like how `u128` was easy to RFC but very hard to make *work* broadly.
>
> Compiler folks: Please comment if you think this should be postponed as impractical to implement in the foreseeable future.
>
> (Practically, we might not accept `f128: Display + FromStr` for a while even on nightly, because of size impacts of being able to accurately print/parse such precision, for example.)
>

### "Cargo Check T-lang Policy" rfcs#3477

- **Link:** https://github.com/rust-lang/rfcs/pull/3477
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3477#issuecomment-1697985863):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3477#issuecomment-1697985719):
> This was discussed in today's lang triage meeting ([notes](https://hackmd.io/4br69DHGRy2EIm-JY5dTgw?view#%E2%80%9CCargo-Check-T-lang-Policy%E2%80%9D-rfcs3477)). The consensus was that we should do it, after the updates in 309c26f2b0e458ad8c0fd051dcc063c9d349bbe2. In particular, we can't guarantee that no optimization-dependent errors will ever exist, but we want the default to be that they shouldn't exist and are considered a bug (and to document the exceptions).
>
> @rfcbot fcp merge

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

- **Link:** https://github.com/rust-lang/rust/issues/65991
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/65991#issuecomment-1670127912):
> Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [ ] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * ~~ensure-we-discuss-lcnr's-thoughts-in-triage~~ resolved by https://github.com/rust-lang/rust/issues/65991#issuecomment-1688682808
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/65991#issuecomment-1670127881):
> Following up on: https://github.com/rust-lang/rust/issues/65991#issuecomment-1640732308
>
> After a few consecutive weeks discussing of the data presented in https://github.com/rust-lang/rust/issues/112355, T-lang believes this is ready to stabilize.
>
> [2023-08-01 hackmd](https://hackmd.io/eEpxNWhQTauw9LzsrZqBkQ#%E2%80%9CTracking-issue-for-dyn-upcasting-coercion%E2%80%9D-rust65991)
>
> [2023-08-08 hackmd](https://hackmd.io/VY0E31zbTMCRXx-BZRluxA#%E2%80%9CTracking-issue-for-dyn-upcasting-coercion%E2%80%9D-rust65991)
>
> The basic conclusion is that we think the cost of this will be limited. Namely, sufficiently limited that we can, if necessary, invest in an opt-out mechanism *at some future date*; we do not need to block stabilization today on the addition of a hypothetical opt-in mechanism, because we think migrating to an opt-in mechanism will be overly disruptive to Rust developers.
>
> @rfcbot fcp merge
>

### "Stabilise inline_const" rust#104087

- **Link:** https://github.com/rust-lang/rust/pull/104087
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231887):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * ~~expectations-around-panics-in-inline-const~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210
> * optimization-dependent-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210)
> * ~~post-monomorphization-errors~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1448730779
> * should-unused-code-cause-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1410921524)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231871):
> Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
>
> @rfcbot fcp merge

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

- **Link:** https://github.com/rust-lang/rust/pull/107378
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287200):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * elaborate-cases-and-future-directions (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
> * why-not-higher-rank (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287177):
> We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:
>
> @rfcbot merge
>
> We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.

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

- **Link:** https://github.com/rust-lang/rust/issues/107645
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789843):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * encapsulation-is-too-powerful (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
> * nested-modules-can-always-define-but-nested-functions-cannot (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789814):
> @rfcbot fcp merge
>
> We held a design meeting yesterday where we reviewed [this document](https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2023-05-31-TAIT-stabilization.md) prepared by @oli-obk and TC (not sure github name) but also with feedback/input from @matklad and others, particularly around IDE requirements.
>
> The document proposed the following resolution to this issue:
>
> - The hidden type may be constrained only within the scope of the item (e.g. module) in which it was introduced, and within any sub-scopes thereof, except that:
> - Functions and methods must have the hidden type that they intend to constrain within their signature -- within the type of their return value, within the type of one or more of their arguments, or within a type in a bound.
> - Nested functions may not constrain a hidden type from an outer scope unless the outer function also includes the hidden type in its signature.
> - A hidden type is considered to appear within the signature if it appears directly or is reachable via traversing field or other element types or via normalization.
> - The hidden type may be constrained by functions, methods, constants, and statics.
>
> The doc goes into more detail about the justifications and alternatives.
>
> Given all this, I propose to merge and accept this proposal.

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

- **Link:** https://github.com/rust-lang/rust/pull/112879
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/112879#issuecomment-1677698959):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * incremental (https://github.com/rust-lang/rust/pull/112879#issuecomment-1683368091)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/112879#issuecomment-1677698927):
> @rfcbot fcp merge
>
> We agreed in last week's lang team meeting to FCP this. My understanding is that this removes all(?) errors that are dependent on optimization flags (e.g. debug vs release), but does not tackle the difference between `check` and `build`.
>
> My [above comment](https://github.com/rust-lang/rust/pull/112879#issuecomment-1641214618) still applies to what's being FCP'd: This FCP does not itself establish a policy that we will commit to this kind of behavior going forward. A crater run would be informative in terms of both build failure regressions and performance (if we are set up to collect performance data).
>
> ---
>
> I'm still trying to understand why there were regressions on debug builds too. I'm guessing it's because we optimized dead code out even in debug mode? That would suggest that there are going to be ecosystem crates which used to build but do not build anymore, in either debug or release.

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

- **Link:** https://github.com/rust-lang/rust/issues/114986
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/114986#issuecomment-1684911463):
> Team member @RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @Amanieu
> * [x] @BurntSushi
> * [x] @CAD97
> * [x] @Dylan-DPC
> * [x] @JakobDegen
> * [ ] @Mark-Simulacrum
> * [x] @RalfJung
> * [x] @cuviper
> * [x] @digama0
> * [x] @dtolnay
> * [x] @joshtriplett
> * [x] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pietroalbini
> * [ ] @pnkfelix
> * [x] @saethlin
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * lack-of-voice (https://github.com/rust-lang/rust/issues/114986#issuecomment-1685080439)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/114986#issuecomment-1684911460):
> @rfcbot fcp merge

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

- **Link:** https://github.com/rust-lang/rust/issues/115285
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/115285#issuecomment-1694767772):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/115285#issuecomment-1694767763):
> @rfcbot merge

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

- **Link:** https://github.com/rust-lang/rust/pull/115333
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/115333#issuecomment-1697980592):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Amanieu
> * [ ] @BurntSushi
> * [ ] @dtolnay
> * [ ] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/115333#issuecomment-1697979984):
> @rfcbot fcp merge

## Active FCPs

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

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