owned this note
owned this note
Published
Linked with GitHub
---
title: Triage meeting 2023-08-29
tags: triage-meeting, minutes, T-lang
date: 2023-08-29
url: https://hackmd.io/4br69DHGRy2EIm-JY5dTgw
discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-08-29
---
# T-lang meeting agenda
* Meeting date: 2023-08-29
## Attendance
* Team members: nikomatsakis, scottmcm, pnkfelix, tmandry
* Others: TC, Lokathor, Michael Goulet (compiler-errors), David
## Meeting roles
* Minutes, driver: TC
## Summary
- Rust assumes that the size of an object equals the [stride](https://en.wikipedia.org/wiki/Stride_of_an_array) of that object (i.e. `size_of::<[T; N]>() == N * size_of::<T>()`). This assumption inhibits certain optimizations that could sometimes save a lot of space (e.g. for overaligned structs) and it complicates interoperability with other languages. However, many things in Rust rely on this, so we decided to [document](https://github.com/rust-lang/lang-team/pull/216) why allowing `size != stride` would be difficult.
- [RFC 3399](https://github.com/rust-lang/rfcs/pull/3399) has completed its FCP. Congratulations to its author, @**recatek**. @**pnkfelix** will merge it.
- On the request of T-lang (to document an earlier consensus), @**Lokathor** filed [RFC 3477](https://github.com/rust-lang/rfcs/pull/3477). That RFC says that `cargo check` errors may be a subset of `cargo build` errors and that only code that passes a full build falls under our stability guarantee. It also says that optimization-dependent build errors are a bug and are *not* part of our stable surface area. The exact wording of this last part needed further discussion. We settled on, "Examples where the optimization level can affect if a program passes `cargo check` and/or `cargo build` are considered bugs unless there is a documented policy exception, approved by T-lang. One example of such an exception is [RFC #3016](https://rust-lang.github.io/rfcs/3016-const-ub.html), which indicated that undefined behavior in const functions cannot always be detected statically (and in particular, optimizations may cause the UB to be undetectable)." With that change, the consensus is to move forward, and @**tmandry** proposed FCP merge.
- T-libs-api had [proposed](https://github.com/rust-lang/rust/pull/106418) to implement `PartialOrd` and `Ord` for `Discriminant`. This would make reordering `enum` variants always a breaking change. @**scottmcm** [objected](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Pondering.3A.20reordering.20variants) to this as he had [previously](https://github.com/rust-lang/rust/issues/51561) back in 2018. There was general agreement in the meeting with those concerns. The question on the table was whether T-lang felt this was within its jurisdiction. The consensus is that T-lang does have reservations and wants to hear the outcome of the T-libs-api discussion that is in progress.
- @**Michael Goulet (compiler-errors)** [noticed](https://github.com/rust-lang/rust/issues/115010) that we stabilized in Rust 1.64 elided lifetimes in associated constants. We hadn't meant to do that, and the current lowering of that elision doesn't make much sense. The consensus is that we'll undo this accidental stabilization by landing a future-compatibility lint (already done) and then making it a hard error after a release or two.
- For [certain types](https://doc.rust-lang.org/std/option/index.html#representation), Rust guarantees that `Option<T>` has the same size as `T` and that `transmute::<T, Option<T>>(..)` and `transmute::<_, T>(Some::<T>(..))` are both sound. This is called the null pointer optimization (NPO). There is a [proposal](https://github.com/rust-lang/rust/pull/115333) to make `transmute::<_, Option<T>>([0u8; size_of::<T>()])` sound for these types and to define it to produce `None::<T>`. There are some speculative whole-program optimizations that are ruled out by doing this (e.g. using alignment niches). But the feeling was that too much of the language relies on this being true for it ever to be done differently. The consensus is to do this. @**tmandry** has tagged this `T-libs-api`, untagged `T-libs`, and proposed FCP merge.
## 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
None.
## Action item review
* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)
## Pending lang team project proposals
None.
## P-critical issues
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: This would add to our document of frequently requested changes an explanation of why `size != stride` would be difficult in Rust.
TC: Josh has proposed FCP merge.
Niko: Seems fine to me. Low hanging fruit. Seems accurate. I like the suggestion from pnkfelix of cross-linking.
pnkfelix: I was surprised the others don't have it.
Niko: I'll just paste it in right now.
Lokathor: These are reversible anyway, right?
pnkfelix: Yes.
scottmcm: Yes, it's a convenient link for people.
Consensus: Let's do this.
## RFCs waiting to be merged
### "Allow cfg-attributes in where clauses" rfcs#3399
**Link:** https://github.com/rust-lang/rfcs/pull/3399
TC: This has completed its FCP merge and is just waiting to be merged.
Niko: We should do this.
pnkfelix: I'll merge it.
Consensus: pnkfelix will merge the RFC PR.
## Nominated RFCs, PRs and issues
### "Cargo Check T-lang Policy" rfcs#3477
**Link:** https://github.com/rust-lang/rfcs/pull/3477
TC: The 2023-08-22 meeting consensus on issue #112879 was to write an RFC to the effect that `cargo check` errors may be a subset of those produced by `cargo build` and that neither this nor optimization-dependent errors are part of the surface area of our stability guarantee. Lokathor volunteered to write that RFC, and it's now posted. It received some earlier [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/cargo.20check.20lang.20policy.20draft) on Zulip resulting in various clarifications.
Niko: Sounds non-controversial and we should do it.
Lokathor: Some people are concerned that `cargo check` won't catch all errors. The answer is that it doesn't already.
Niko: This is the point of that RFC to discuss that question.
scottmcm: Maybe we should just explain why this is hard.
tmandry: I'm willing to propose it for FCP merge.
pnkfelix: Where was the conversation as of a few hours ago? Do we want to cut off that conversation?
scottmcm: FCP is part of the process of raising those concerns, so it doesn't cut off conversation.
pnkfelix: That's true.
tmandry: Did we say we want to commit to optimization-dependent errors never existing?
Lokathor: We did say that the policy could change, but it'd need to be another RFC. RalfJ proposed the language here.
Niko: I'm surprised RalfJ proposed this...
pnkfelix: Where did RalfJ suggest this?
Lokathor: [Here](https://github.com/rust-lang/rfcs/pull/3477#discussion_r1303511547).
all: RalfJ did propose that language.
tmandry: We're worried about people depending on this for some soundness guarantee in unsafe code? E.g. I have some code in an `if false` and I'm relying on the compiler to trigger this assertion at compile time inside of `const`?
Niko: I guess I don't expect the compiler to trigger that. Those are before MIR construction and also optimization-independent. You could imagine const propagation through a pointer deference.
scottmcm: Here's the UB-in-const RFC https://rust-lang.github.io/rfcs/3016-const-ub.html which says that we don't have to catch UB in CTFE (other than that it can't infect the general compilation).
tmandry: I was worried about an instantiation of some generic code.
scottmcm: The PRs we're talking about will cause these to be instantiated.
tmandry: Making that the case is a big performance hit.
TC: Would it help if we clarified in the RFC that we're not making any new guarantees but only specifying more clearly what we're *not* guaranteeing?
Niko: Should we just cut the paragraph about optimization-dependent errors?
tmandry: But we did discuss specifying that as part of this RFC.
Lokathor: Do we consider it a bug if there's an optimization-dependent error at any level?
scottmcm: As a lint, it's not a bug. But as an error, it's definitely a bug.
Niko: With const fns, we agreed, I thought, that it's not a bug.
Niko: I'm OK with saying we call it a bug. But maybe we do want a finer-grained policy? We could specify that the exception is some specific thing for const fn.
tmandry: I think the other thing is that we reserve the right to allow some of these if it would be too costly in terms of compiler performance.
Niko: We could say, "the policy is this, but we may make exceptions."
scottmcm: Agreed with that.
scottmcm: Niko, are you saying anything different than the UB-in-const RFC?
tmandry: Lokathor, do you have enough to go on?
Lokathor: No. What do we want?
Niko: The policy is this, but we may make and document exceptions.
TC: We would RFC those exceptions, or we would FCP the documentation for them?
Niko: We could leave making these exceptions to T-compiler.
scottmcm: If we leave this for compiler-team, they'd probably make the exception here. Do we want that?
Niko: Probably no. I take it back. This is a T-lang concern.
scottmcm: Could we make UB-in-const a forbid lint instead of a hard error?
Niko: That would help us to rationalize this.
Lokathor: We can always define undefined behavior.
Niko: It's not literally a deny-by-default lint. You can't allow it.
Niko: I think it's OK to say, "this is the main exception".
TC: Lokathor?
Lokathor: I'm still looking for a specific proposal for a change.
all: Let's work out the language here:
Original language:
> Any example where the optimization level can affect if a program passes `cargo check` and/or `cargo build` is a bug. There are no situations where a change in optimization level is intended to affect if a `check` or `build` is successful.
Revised language:
> Examples where the optimization level can affect if a program passes `cargo check` and/or `cargo build` are considered bugs unless there is a documented policy exception, approved by T-lang. One example of such an exception is [RFC #3016](https://rust-lang.github.io/rfcs/3016-const-ub.html), which indicated that undefined behavior in const functions cannot always be detected statically (and in particular, optimizations may cause the UB to be undetectable).
From the RFC:
> No UB-exploiting MIR optimizations are currently being performed for CTFE, so a CTFE execution currently will never go wrong in arbitrary ways: UB is either detected, or evaluation continues in a well-defined manner as described above.
>
> However, this is just a snapshot of what rustc currently does. None of this is guaranteed, and rustc may relax or otherwise change its UB checking any time.
Consensus: Let's proceed with the revised language.
### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418
**Link:** https://github.com/rust-lang/rust/pull/106418
TC: This T-libs-api change would make the reordering of variants in an `enum` a breaking change in all cases.
TC: scottmcm has raised concerns about this (as he did previously in 2018).
TC: I proposed nomination as this definitely seems to be a question for T-lang.
tmandry: Can we make this work if something is explicit?
scottmcm: Probably not.
Niko: Discriminant does carry the enum type... I'm imagining something like:
```rust
impl<T: Ord> Ord for Disciminant<T> { }
impl<T: PartialOrd> PartialOrd for Disciminant<T> { }
```
...which may not be *consistent* in its ordering, but avoids *introducing* an ordering.
scottmcm: That's less of a concern but it's slightly odd. There was a time when we were considering reordering the variants in `Option` for efficiency. We could do that by implementing `Ord` appropriately.
Niko: We could have a marker trait.
scottmcm: I proposed exactly that.
> If they want to opt-in to exposing the order, such as if these impls were `impl<T> cmp::Ord for Discriminant<T> where T: ExposedVariantOrder` with a `#[derive(ExposedVariantOrder)]` or something, then sure, having this would be fine.
tmandry: Does it matter if it's `#[repr(u8)]`?
Niko: Not for what I had proposed.
Niko: What's the action-item for this meeting? There's currently a registered concern.
TC: Does T-lang feel like it has jurisdiction here? If so, it should probably be documented in the issue.
...
Niko: What do people really do with this anyway?
scottmcm: I think the marker trait would probably solve this.
pnkfelix: I didn't understand the objection to the marker trait. Does anyone?
scottmcm: Yeah, I don't understand. This PR is doing the least private thing possible.
...
pnkfelix: Are we really asking for a way that the ordering could be overridden?
...
Niko/scottmcm: It'd be nice if there were a version of `Ord` that let you put it in a map but didn't mean anything.
...
Consensus: scottmcm will make a comment that T-lang has reservations (that match those that scottmcm has raised) and T-lang wants to hear the outcome of the T-libs-api discussion.
### "Tracking Issue for `ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT` future-compat lint" rust#115010
**Link:** https://github.com/rust-lang/rust/issues/115010
TC: Michael Goulet (CE) nominated this:
> @tgross35: that's behavior that @rust-lang/lang needs to stabilize separately. I'll nominate this issue to see if opinions have changed since #38831, but this lint is specifically aimed at making sure people are not relying on behavior that was never formally stabilized.
>
> # Question for T-lang: What should we do here?
>
> * A. Continue with this lint, accepting churn, with the possibility of relaxing this (i.e. resolving `'_` to `'static` in associated consts) in the future
> * B. Fast-track stabilization of this extension to static-lifetimes-in-const (RFC 1623), and revert this lint before it makes its way to stable (1.74, so we have approx. 12 weeks to decide as of 2023/08/24)
> * C. Some other compromise in the middle, e.g. stabilizing the static-lifetime elision rule when some other condition is true (i.e. the self type has no other lifetimes)
> * D. Something else :^)
Lokathor: Is this an accidental stabilization situation?
CE: Yes. In 1.64. We never decided to assign meaning to these elided associated constants.
Niko: What is the current resolution rule?
CE: It lowers to an early-bound var. But we could lower to a static var without breaking anything.
Niko: What happens in this scenario?:
```rust
struct Foo;
impl<'a, 'b> Foo {
const STR: &str = "hello, world";
}
```
CE: It lowers to a fresh early-bound var. It's a bit nuts.
Lokathor: You want to lower to static?
CE: No, I want to undo it.
Niko: I think we should undo it. Also: this does not compile ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c0d6bccf79f5a8838856eb761460a7bb)):
```rust
trait Foo {
const X: &'static str;
}
impl Foo for &u32 {
const X: &str = "foo";
}
```
Niko: It's even weirder in an associated constant because it's not an output type. And that's why it gives you a fresh var.
Lokathor: It seems this needs a full RFC cycle.
Niko: Is there a case where someone writes the lifetime explicitly and doesn't write static?
CE: When you have an invariant lifetime. I've done that in the compiler.
scottmcm: Notably, functions don't let you elide static in the output lifetime. Even if it's the only thing you could put there it doesn't necessarily mean it should be elided.
scottmcm: I should bring my associated types lifetime elision RFC back up now that GATs exist. (c.f. <https://github.com/rust-lang/rfcs/pull/2548#issuecomment-724919290>)
Lokathor: Do we have consensus to back this out?
tmandry, Niko: Yes, don't see another option.
pnkfelix: We mean to add a future-compat lint?
CE: Yes, it's already landed.
TC: Is this for 2024 edition?
CE: No, we'll make it a hard-error in a couple of versions, even before 2024.
tmandry: In writing the spec, maybe we'll find missing test cases like this.
Consensus: We'll back this out by adding a future compatibility lint and then making it a hard error in a couple of versions.
### "Guarantee representation of None in NPO" rust#115333
**Link:** https://github.com/rust-lang/rust/pull/115333
TC: Nilstrieb nominated this:
> ### Question
>
> Should it be guaranteed that the option null pointer optimization is _actually_ a null pointer optimization, choosing the null pointer (0) to represent `None`?
Niko: In what way is this new?
scottmcm: We don't guarantee this for all of the types. Some types specifically document this.
scottmcm: It's actually interesting that invalid file type is not in this list.
Niko: This is not like niche optimization. This is null-pointer optimization.
pnkfelix: Someone gave a comment, "what about alignment niches?", where you could theoretically represent `None` with something you couldn't encounter due to alignment constraints.
Niko: That doesn't seem very practical to me. You don't know the... actually, you conceivably could. But why would you? You'd have to have some crazy global optimization.
Niko: `Option<&u32>` has to have the same layout everywhere in the program.
Niko: I think we should do this.
tmandry: Agreed.
Lokathor: Too much of the language assumes this.
Niko: We should loop in T-opsem. They should be CCed.
tmandry: This is currently tagged T-lang + T-libs.
scottmcm/Niko: Plausibly both.
Niko; But it's more T-lang.
tmandry: Any objections to tagging T-libs-api, untagging T-libs, and proposing FCP merge?
scottmcm: Maybe we want this documented elsewhere, but I think it's fine.
Consensus: tmandry will tag this with T-libs-api, untag T-libs, and propose FCP merge.
(The meeting ended here.)
### "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.
### "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.
### "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.
>
> ...
### "Document soundness of Integer -> Pointer -> Integer conversions in `const` contexts." rust#113510
**Link:** https://github.com/rust-lang/rust/pull/113510
TC: @scottmcm nominated this on 2023-08-03:
> (Re-nominated to encourage discussion of the exact text on Tuesday.)
TC: The FCP merge on this issue has since completed.
### "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.)
### "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.
### "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.
### "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.
### "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?
### "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.
### "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`...)?
### "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 were three [proposals](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/selection.20process) during or after the 2023-08-22 meeting last week about how to move forward before the editor is hired.
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.
### "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.
## `S-waiting-on-team`
### "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
TC: This one is waiting on a decision on syntax.
### "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
TC: This issue is nominated.
### "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
> * [ ] @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.)
>
TC: @scottmcm proposed to merge this 2023-08-04.
### "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
>
TC: This issue is `S-waiting-on-team`.
### "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
TC: This one has been blocked on "Report monomorphization time errors in dead code, too" rust#112879.
### "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.
TC: This is waiting on the author.
### "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.
TC: This was discussed in a [design meeting](https://hackmd.io/IVFExd28TZWm6iyNIq66PA) on 2023-05-31. Subsequently @tmandry raised concerns. We had a [mini-design meeting](https://hackmd.io/r1oqcjrzTAK5e_T1IOXeXg) on 2023-06-29 regarding those. A [long thread](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/TAIT.20mini-design.20meeting.202023-06-29) on Zulip followed from that.
TC: TAIT is also separately affected by the capturing of lifetimes discussed in the [design meeting](https://hackmd.io/sFaSIMJOQcuwCdnUvCxtuQ) on 2023-07-26. That is pending an RFC that I will be submitting (the [PR](https://github.com/rust-lang/rust/pull/114616) for the implementation is ready).
### "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.
TC: This issue is nominated.
### "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
> * [ ] @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
TC: RalfJ proposed this:
> The summary is that for teams of size 5, currently 3 checkboxes are enough to consider the FCP as passed; the change is to require 4 checkboxes instead. Formally, the requirement for entering the 10-day period changes from "more than half the members" to "at least two thirds of the members".
TC: There is further discussion of this issue [here](https://rust-lang.zulipchat.com/#narrow/stream/392734-council/topic/RFC.20Bot.20Supermajority).
### "`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
TC: BatmanAoD opened this PR:
> This is a request for _full_ stabilization of the `c_unwind` feature, [RFC-2945](https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md). The behavior of non-`"Rust"`, non-`unwind` ABIs (such as `extern "C"`) will be modified to close soundness holes caused by permitting stack-unwinding to cross FFI boundaries that do not support unwinding.
>
> ## Summary
>
> When using `panic=unwind`, if a Rust function marked `extern "C"` panics (and that panic is not caught), the runtime will now abort.
>
> Previously, the runtime would simply attempt to unwind the caller's stack, but the behavior when doing so was undefined, because `extern "C"` functions are optimized with the assumption that they cannot unwind (i.e. in `rustc`, they are given the LLVM `nounwind` annotation).
>
> This affects existing programs. If a program relies on a Rust panic "escaping" from `extern "C"`:
>
> * It is currently unsound.
> * Once this feature is stabilized, the program will crash when this occurs, whereas previously it may have appeared to work as expected.
> * Replacing `extern "x"` with `extern "x-unwind"` will produce the intended behavior without the unsoundness.
>
> The behavior of function calls using `extern "C"` is unchanged; thus, it is still undefined behavior to call a C++ function that throws an exception using the `extern "C"` ABI, even when compiling with `panic=unwind`.
>
> ...
TC: Josh proposed to merge this.
### "Add size != stride to frequently requested changes" lang-team#216
- **Link:** https://github.com/rust-lang/lang-team/pull/216
- [**Tracking Comment**](https://github.com/rust-lang/lang-team/pull/216#issuecomment-1696697182):
> 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
>
> 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/lang-team/pull/216#issuecomment-1696657830):
> @rfcbot merge
TC: This is a PR on the lang-team repo.
## Active FCPs
### "Replace old private-in-public diagnostic with type privacy lints" rust#113126
**Link:** https://github.com/rust-lang/rust/pull/113126
### "Add alignment to the NPO guarantee" rust#114845
**Link:** https://github.com/rust-lang/rust/pull/114845