---
title: Triage meeting 2023-08-22
tags: triage-meeting, T-lang, minutes
date: 2023-08-22
url: https://hackmd.io/9a7PBOg5Q_aXM_hg0IF-jw
discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-08-22
---

# T-lang meeting agenda

* Meeting date: 2023-08-22

## Attendance

* Team members: Josh, scottmcm, pnkfelix, tmandry
* Others: TC, Lokathor

## Meeting roles

* Minutes, driver: TC

## Summary

- We discussed the `MaybeDangling` [RFC 3336](https://github.com/rust-lang/rfcs/pull/3336). The open questions seem to be deciding what the type should be called and whether it should implement `Deref`. We discussed whether the type is meant to be droppable. The feeling was that this is implied in the RFC but should be made explicit. Overall, we felt that the issue was complicated and needs more attention, and the meeting consensus was to table the matter so that people can read the RFC and associated discussion more carefully.

- For [RFC 3349](https://github.com/rust-lang/rfcs/pull/3349), we had been waiting on the author to make some updates. Those have now been made. @**Josh Triplett** reviewed the updates and believes this resolves the concerns, and has resolved his own. The meeting consensus was to table the matter to give time for others to review the changes and resolve the other open concerns.

- For [#112879](https://github.com/rust-lang/rust/pull/112879), we've made a decision to remove a case of optimization-dependent errors at the cost of a ~5% compile-time penalty. We decided this because we don't want optimizations to affect the stable surface area of Rust. But we shouldn't do this on the expectation that we'll ever get this time back, because that may not be possible. However, we were surprised that this was affecting the speed of `check`, and we wanted to understand why that was the case. The feeling was that it's OK if `check` doesn't catch this. That raised the question of what our stability guarantees are for `check`. The answer was that if a build passes in one release, then it must be accepted by `check` in a later release, but it's OK if something passes `check` in one release and then fails `check` in a later release. We felt that we should say this in a document along with a statement that current optimization-dependent differences in errors are not part of our stability guarantee. @**Lokathor** volunteered to write up an RFC, and we'll nominate it for discussion after it's posted.

- For [#113527](https://github.com/rust-lang/rust/issues/113527), putting together a team for the Rust spec, we discussed how to unblock this. The proposal was to break this up into two phases. The first phase would establish requirements for the spec. The second phase would actually work to write the thing. At this stage, we would pick only the members for the first phase of the team. @**pnkfelix** volunteered to write up a proposal for this. We noticed during the meeting that @**nikomatsakis** had made a [proposal](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/selection.20process) in parallel. The meeting consensus was to take this async.

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

### RFC: expose-fn-type #3476

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

Lokathor: This isn't ready for a general discussion, but people should have a look at this async.

Josh: If we have even the slightest plans for `typeof`, we should use that instead of `fn`. And I wonder if some associated type would be better.

Lokathor: They wanted to be able to implement traits for particular functions; that was the original motivation.

Josh: Someone should mention in the document that `typeof` would make this redundant.

## Action item review

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

## Pending lang team project proposals

None.

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## P-critical issues

None.

## `S-waiting-on-team`
### "Tracking issue for dyn upcasting coercion" rust#65991

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

TC: The 2023-08-15 meeting consensus was to table this and nominate it for @*T-types* to resolve the question of whether the stabilization report addresses the type system changes or whether more work is needed (and if so, what questions specifically should be answered by t-lang). We're still waiting on that.

TC: I propose that we nominate this to keep it on our radar but drop the `S-waiting-on-team` label.

pnkfelix: It is waiting on *a* team, but it's not tagged as t-types.

TC: OK. We'll leave it as waiting on team and tag with t-types.

pnkfelix: scottmcm had raised a concern. We'll leave that concern there pending action from t-types?

scottmcm: I'll actually resolve my concern now; it won't go into FCP anyway.

### "Replace old private-in-public diagnostic with type privacy lints" rust#113126

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

TC: This is now entering FCP, so it's no longer waiting on us. Let's remove the label.

Josh: Label is removed. Someone still needs to bors `r+` it, so it should be `S-waiting-on-review` once the FCP completes. It'll be `S-waiting-on-fcp` for now.

### "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. The issue is also nominated; let's maybe drop the `S-waiting-on-team` label?

TC: As with the first issue, let's instead leave the `S-waiting-on-team` label and also tag this for t-types.

pnkfelix: I'll add the label for t-types.

## Nominated RFCs, PRs and issues

### "MaybeDangling" rfcs#3336

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

TC: There's been considerable recent [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/MaybeDangling) of this over on Zulip.

TC: The discussion seems to have died down, so it may be good to discuss here.

Josh: Ralf has a comment from 3 days ago:

> FWIW I don't have a strong preference between the RFC as-written, and just giving ManuallyDrop this special behavior. I think we certainly want ManuallyDrop to have this special behavior, so that a MaybeUninit<Box<_>> is allowed to dangle. (Or maybe we allow all Box to dangle.)
>
> The pattern of having to move some data into a closure in an opaque way without knowing the exact type of the data and without making any promises about references outliving the entire closure does arise consistently, and MaybeDangling seems like a much clearer signal for such code than a ManuallyDrop + remembering to (unsafely) call drop.
>
> If we want to for now just make ManuallyDrop special, adjust Miri accordingly, and start spreading that as the intended way of dealing with these situations -- I could live with that. Adding a stand-alone MaybeDangling without drop semantics in the future always remains a possibility.

Josh: Ralf seems to be suggesting that having this separate may make it more clear.

Lokathor: Is MaybeDangling dropping?

...

all: This is a good point.

scottmcm: If it's not `Deref` it can have methods so it's not that bad to use.

Lokathor: The RFC points out as a drawback that we're getting a lot of these types that layer together.

pnkfelix: Do people use `MaybeUninit` for destructing? Is that a usage pattern that's used in practice?

scottmcm: I don't think I have an example of that. We've discussed whether `Vec` could be written in this way... actually, maybe that is an example of what you're discussing.

Lokathor: This has been nominated for so long that maybe things have shifted. Maybe it'd be appropriate to make a post asking for a current summary to discuss.

Lokathor: The unresolved questions are 1) what should the type be called and 2) should it implement `Deref`?

scottmcm: I'm going to read it closely and post something after that.

Lokathor: `ManuallyDrop` would always use `MaybeDangling` internally, but the interesting case is when you use the latter but not the former.

pnkfelix: The first bullet in the alternatives implies that Ralf does intend for these things to be droppable. That needs to be more explicit.

(The meeting consensus is that we'll table the issue so that people can read this more carefully while leaving it nominated so that we'll be prompted to discuss it later.)

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

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

TC: This one *was* waiting on the author, but the author has now updated the RFC based on the feedback.

Josh: I've confirmed that the author's updates did address the concern that I raised and that pnkfelix raised.

(The meeting consensus is to check async whether pnkfelix's concern can be resolved.)

### "Allow explicit `#[repr(Rust)]`" rust#114201

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

TC: This is entering FCP. @tmandry had earlier nominated this, but later dropped his associated concern. Maybe we should drop the nomination also.

(There was discussion about the intended effect of tmandry dropping his concern and the issue going into FCP without his box checked. The conclusion was that this should be interpreted as a +0.)

(The meeting consensus is to unnominate the issue.)

Josh: I've unnominated.

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

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

TC: This entered FCP. The change comes with a compile-time hit that we may not be able to mitigate. Josh renominated for discussion:

> @nnethercote +1 for making sure the signoff here is not contingent on finding ways to mitigate the performance. (I'm keeping the current lang nomination and proposing to recheck this in the next lang meeting. @scottmcm, @tmandry, are either of your checkboxes contingent on assumptions that we will get this specific performance loss back?)
>
> A 4-6% performance regression is awful. The only reason we're currently willing to reluctantly live with it is that without this change, compiler optimizations are potentially part of the compiler's stable surface area, and modifying an optimization could cause existing code to fail to compile. That is the outcome that's so unpalatable as to be worth considering this.
>
> If there's any other way we can avoid having compiler optimizations become part of Rust's stability guarantees, even a way that has other substantial tradeoffs, I think we'd be extremely interested in considering it.

Josh also filed a concern pending investigation into a point that RalfJ made:

> All the incr-unchanged regressions are also strange, if nothing changed caching should be as effective as before, no? Can someone generate the cachegrind diff, e.g. for this benchmark? E.g. there's a 25% incremental loading delta for optimized_mir, which is odd since we shouldn't run any more optimizations than before definitely not in a debug build...

Josh: We had approved this because we don't want to leak this through as stable behavior. But I want to be sure people realize that this is performance we may not get back.

scottmcm: Did we expect check-build regressions on this?

Josh: That is the other concern. It's appropriate to understand why that performance is lost, and whether it should be.

Lokathor: A check build does all the normal things but doesn't do translation.

scottmcm: But we said that a check build doesn't need to catch all things.

Josh: So it would be an option to simply not do this in check mode.

tmandry: We did say that, but it's better if check mode does report all errors.

pnkfelix: Are we saying the check build is different from a stabilization perspective?

scottmcm: Debug and opt builds may well do more and we're accepting the perf hits for those.

Josh: Agreed, but I'm concerned about the cost on incremental builds in a case that it didn't seem like it should.

scottmcm: Not a proposal yet, but maybe we could say that we are going to lean into check catching the most valuable things, but we're OK with requiring a build that does code gen to detect certain other problems?

Josh: The issue of optimizations affecting the stable surface of Rust is why we did this in the first place. But passing check doesn't mean that codegen will complete.

pnkfelix: If a check build passes with one release, are we guaranteeing that it will pass with a later version?

Josh: If build passes on one version it should pass on a later version. But if check passes and build does not pass, then it's OK if check starts failing later.

pnkfelix: I buy that.

Josh: I'd propose that we make a clear statement about this and FCP it. But I don't have the bandwidth to write that up.

scottmcm: It feels like a very visible thing; it's not just a tweak. We should have a document.

Lokathor: I'll try to write an RFC to this effect.

scottmcm: This can be a very minimal RFC and delete most of the template.

tmandry: Should we include that build will catch everything and will not depend on optimization flags in this RFC?

Josh: I'd be in favor. We'd be expressing that we're not promising that this is the case. But we'd be saying that it should be true.

scottmcm: We're saying this does not hold today; it is a bug that we may fix, and those fixes will not be considered breaking changes according to our stability guarantee.

TC: To clarify, we would be saying that the debug or release build is the correct one, as far as our stability guarantee?

Lokathor/Josh: It could go both directions.

tmandry: We should be clear that we may relax the property in the future.

TC: Maybe if we later changed our minds we should do a new RFC at that point?

Lokathor: We can put it under future possiblities.

Josh: Let's nominate that RFC after publishing it.

(The meeting consensus is that Lokathor will write up an RFC and that we'll nominate this for discussion once it is posted.)

### "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: In the 2023-08-08 meeting, we [discussed](https://hackmd.io/VY0E31zbTMCRXx-BZRluxA#Rust-specification-progress) various ways of unblocking this work as a separate agenda item.

Josh: One way to get this unblocked would be to break this into phases. There's a phase that consists of documenting requirements for the spec, then signing off on that from t-spec and t-lang. Then there's a phase where people will be writing a spec for quite some time. Then there will be a sign-off from the other teams.

Josh: I propose we propose a set of members for the first phase.

TC: What's the actual blocker on putting together the full team?

Josh: We don't have concrete names for some of the teams. We don't have full agreement on the composition of the team long-term. Some people have proposed it should be a smaller team. And some of the potential members may make sense for only one phase.

pnkfelix: Do you have to be a formal member of the team? The implication that the team has to be larger to get input does not naturally follow.

Josh: At the end of the day, the requirements will need to get signed off by a group larger than the spec team. The purpose of having reps is bandwidth and speed of iteration.

pnkfelix: I'm happy to draft this proposal.

TC: Is the proposal that t-lang would pick the members for both phases or that the first phase members would pick the second phase?

Josh: We'll pick the members for the first phase and not commit how to handle the second phase.

TC: Do we want to ask each of the teams that we want to be represented to finish picking someone?

pnkfelix: We may not need representation from many teams for the first phase.

TC: What teams are we expecting there?

pnkfelix: Probably t-lang and t-optem. Maybe t-types.

(We noticed during the meeting that @nikomatsakis is making a parallel [proposal](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/selection.20process).)

(The consensus was to take this async.)

(The meeting ended here.)

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

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

### "Lower `Or` pattern without allocating place" rust#111752

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

TC: This has completed its FCP merge. Let's unnominate this.

(We unnominated this in the meeting.)

### "Replace old private-in-public diagnostic with type privacy lints" rust#113126

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

TC: This one is entering FCP. Let's unnominate this.

(We unnominated this in the meeting.)

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

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

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

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

## 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 (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
> * waiting-on-update-re-using-char-and-string-tables (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1503875165)
>
> 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:
>
> * [ ] @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 (https://github.com/rust-lang/rust/issues/65991#issuecomment-1678581352)
>
> 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
> * [ ] @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.

### "Add alignment to the NPO guarantee" rust#114845

- **Link:** https://github.com/rust-lang/rust/pull/114845
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/114845#issuecomment-1679478228):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @Amanieu
> * [x] @BurntSushi
> * [x] @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/rust/pull/114845#issuecomment-1679449673):
> @rfcbot merge
>
> This is intentionally both lang (for the null-pointer optimization) and libs-api (for the specific types involved).

TC: In the 2023-08-15 meeting:

> @**scottmcm** raised the issue of documenting that `NonZeroI32` and `Option<NonZeroI32>` are guaranteed to have the same size *and alignment*. As he said, "as far as I know, this is always true already, but it’s not in the text of the `Option` module docs". The meeting consensus was to FCP this with t-lang and @*T-libs-api*.

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

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

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

### "Replace old private-in-public diagnostic with type privacy lints" rust#113126

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

### "Allow explicit `#[repr(Rust)]`" rust#114201

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

### "replace 'UB on raw ptr deref' with UB on place projection/access" reference#1387

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