---
title: Triage meeting 2023-09-12
tags: triage-meeting, minutes, T-lang
date: 2023-09-12
url: https://hackmd.io/IwkRKAYiQ4W9D06k8b3FeQ
discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/triage.20meeting.202023-09-12
---
# T-lang meeting agenda
* Meeting date: 2023-09-12
## Attendance
* Team members: Josh, pnkfelix
* Others: TC, Lokathor, waffle, ~~Urgau~~
## Meeting roles
* Minutes, driver: TC
## Summary
- We scheduled the following upcoming design meetings:
- 2023-09-13: [Inherent trait impls - #2375](https://github.com/rust-lang/rfcs/pull/2375)
- 2023-09-20: [Add `f16` and `f128` float types - #3453](https://github.com/rust-lang/rfcs/pull/3453)
- 2023-09-27: [MaybeDangling - #3336](https://github.com/rust-lang/rfcs/pull/3336)
- In [#115659](https://github.com/rust-lang/rust/pull/115659), @**Michael Goulet (compiler-errors)** has proposed `#[feature(impl_trait_projections)]` for stabilization. This feature gate had been separated off for implementation reasons. It's now relevant to the stabilization of RPITIT. We decided that T-lang had already signed off on the language concerns here, so this stabilization does not need further T-lang approval.
- In [#80926](https://github.com/rust-lang/rust/issues/80926), @**RalfJ** had proposed to remove the aligned-in-packed check. We agreed that this should be done, and also agreed that a best-effort lint would be good, but that removing the check does not need to block on this.
- [#112380](https://github.com/rust-lang/rust/pull/112380) proposes an allow-by-default `unit_bindings` lint that would fire when an expression of unit type is bound to a variable without the type being annotated. The exemplar of the pattern we want to catch is `let list = list.sort()`. The consensus was that this is a good idea, and we proposed FCP merge. We tagged this for inclusion in the release notes as we want to raise awareness of this change so that proc macro authors can make any needed adjustments. After some time, we hope to make this warn-by-default.
## Scheduled meetings
- No pending proposals this time.
Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.
## Announcements or custom items
### Finalize 2023-09 design meeting schedule
The RFCs we're [considering](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rfc.20reads) for design meetings this month are:
- [MaybeDangling - #3336](https://github.com/rust-lang/rfcs/pull/3336)
- [Add `bf16`, `f64f64` and `f80` types - #3456](https://github.com/rust-lang/rfcs/pull/3456)
- [UnsafeAliased - #3467](https://github.com/rust-lang/rfcs/pull/3467)
- [Inherent trait impls - #2375](https://github.com/rust-lang/rfcs/pull/2375)
- [Unsafe extern blocks - #3439](https://github.com/rust-lang/rfcs/pull/3439)
- [Unified string literals - #3475](https://github.com/rust-lang/rfcs/pull/3475)
- [Placement by return - #2884](https://github.com/rust-lang/rfcs/pull/2884)
- [Unsafe lifetime - #3199](https://github.com/rust-lang/rfcs/pull/3199)
- [Aligned trait - #3319](https://github.com/rust-lang/rfcs/pull/3319)
- [Code string literals - #3450](https://github.com/rust-lang/rfcs/pull/3450)
- [Implementable trait aliases - #3437](https://github.com/rust-lang/rfcs/pull/3437)
- [Add `f16` and `f128` float types - #3453](https://github.com/rust-lang/rfcs/pull/3453)
TC: Based on the feedback in the thread, I would propose:
- 2023-09-13: [Inherent trait impls - #2375](https://github.com/rust-lang/rfcs/pull/2375)
- 2023-09-20: [Add `f16` and `f128` float types - #3453](https://github.com/rust-lang/rfcs/pull/3453)
- 2023-09-27: [MaybeDangling - #3336](https://github.com/rust-lang/rfcs/pull/3336)
Speculatively, looking forward to October and November we might consider:
- 2023-10-11: [UnsafeAliased - #3467](https://github.com/rust-lang/rfcs/pull/3467)
- 2023-10-18: [Unsafe extern blocks - #3439](https://github.com/rust-lang/rfcs/pull/3439)
- 2023-10-25: [Placement by return - #2884](https://github.com/rust-lang/rfcs/pull/2884)
- 2023-11-01: [Unsafe lifetime - #3199](https://github.com/rust-lang/rfcs/pull/3199)
- 2023-11-08: [Aligned trait - #3319](https://github.com/rust-lang/rfcs/pull/3319)
- 2023-11-15: [Add `bf16`, `f64f64` and `f80` types - #3456](https://github.com/rust-lang/rfcs/pull/3456)
- 2023-11-22: [Implementable trait aliases - #3437](https://github.com/rust-lang/rfcs/pull/3437)
- 2023-11-29: [Unified string literals - #3475](https://github.com/rust-lang/rfcs/pull/3475)
---
(Discussion related to who might be where when and who might want to be present for what...)
*Consensus*: Let's schedule the following meetings for this month:
- 2023-09-13: [Inherent trait impls - #2375](https://github.com/rust-lang/rfcs/pull/2375)
- 2023-09-20: [Add `f16` and `f128` float types - #3453](https://github.com/rust-lang/rfcs/pull/3453)
- 2023-09-27: [MaybeDangling - #3336](https://github.com/rust-lang/rfcs/pull/3336)
pnkfelix: I'll update the schedule on GitHub and in the Google calendar.
## Nominated RFCs, PRs and issues
### "Stabilize `impl_trait_projections`" rust#115659
**Link:** https://github.com/rust-lang/rust/pull/115659
TC: CE nominated this:
> This allows us to mention Self and T::Assoc in async fn and return-position impl Trait, as you would expect you'd be able to.
TC: This is related to the RPITIT stabilization. This feature flag was split out for implementation reasons; T-lang never decided that this should be separate.
Josh / pnkfelix: We don't need to approve removing a split we did not create.
TC: Want to pull T-lang off of the FCP?
Josh: I've removed the T-lang label and I'll write a comment to summarize.
*Consensus*: T-lang doesn't need to approve this.
### "Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024" rust#112038
**Link:** https://github.com/rust-lang/rust/pull/112038
TC: In the 2023-09-05 meeting, we agreed this was covered by a [previous FCP](https://github.com/rust-lang/rust/issues/71668#issuecomment-1189396860) and that we were still happy with the decision.
TC: I propose we remove the nomination.
Josh: Agreed. I'll remove it.
*Consensus*: Let's remove the nomination.
### "closure field capturing: don't depend on alignment of packed fields" rust#115315
**Link:** https://github.com/rust-lang/rust/pull/115315
TC: In the 2023-09-05 meeting, we agreed this was a bug fix and proposed FCP merge. It's now in FCP.
TC: I propose we remove the nomination.
Josh: Agreed. I'll remove it.
*Consensus*: Let's remove the nomination.
### "we reserve the right to reduce our amount of UB" reference#1397
**Link:** https://github.com/rust-lang/reference/pull/1397
TC: We discussed on 2023-09-05 and proposed FCP merge. It has now entered FCP.
TC: The bot couldn't add the label. We should do that.
Josh: Done.
Josh: I'll follow up with Ralf about the unmerged suggestion.
### "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: We discussed in the 2023-09-05 meeting and left a comment encouraging a proposal accompanied by a crater run.
TC: I propose we remove the nomination and allow it to be re-nominated when a proposal has been made.
Josh: Someone would have to make a proposal for concrete lints and then run crater on that.
Josh: We can safely remove the nomination. I'll remove it.
*Consensus*: Let's remove the nomination pending a proposal.
### "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?
Lokathor: What a mess that sounds like.
Josh: It's becoming clear packed is a good example of something that should be or should have been an unsafe attribute.
pnkfelix: It's not inherently unsound until it is.
Lokathor: In that sense, it is like no_mangle. It's not unsafe unless you mix it with other things.
TC: What do we think that Ralf is asking for exactly? People here seem to agree that this is a mess.
Josh: The check isn't as effective as we thought it would be. It may not have a lot of value. Ralf is saying it does the same thing on align as it does on everything else: "I don't care what alignment these types want, pack them anyway". That seems like a reasonable argument. It's not clear we need a check here about two things that are inconsistent.
Lokathor: Maybe the rule should be "outermost wins".
Josh: I think the rule is outermost wins at the moment.
Lokathor: If we remove the check, that codifies that rule.
pnkfelix: I'm trying to figure out if downgrading to a lint even has any value.
Josh: My only concern is the third paragraph, about GCC's behavior. But I don't think this particularly makes that worse. We could always make it better in the future.
Lokathor: If you had to be compatible here, you could `cfg` flag it.
Josh: Keeping this check doesn't seem valuable.
pnkfelix: Do we think it has any value as a lint?
pnkfelix: We're going to allow an aligned attribute that won't mean anything. It's like dead code.
Josh: Sticking aligned on a struct and putting the struct in a packed thing, it may not be totally dead, because you could be using the struct elsewhere.
Josh: But we could have a best effort lint.
pnkfelix: And it doesn't need to block removing the check.
Josh: +1 on that.
Lokathor: Maybe the lint should live in clippy, since it's known to be less accurate.
pnkfelix: I'll write the comment.
*Consensus*: Let's remove the check. We're in favor of a best-effort lint, but the check can be removed without that lint being implemented.
### "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`...)?
TC: Waffle, you're here, want to fill us in?
(Waffle discusses the situation...)
waffle: There is a possible false-positive in certain macro use-cases where code is generated with spans.
Lokathor: Looking at that, I'm not sure as a user I'd know how to silence that lint.
...
Lokathor: I guess the proc macros should update what they're doing.
TC: What should the proc macros do instead?
waffle: They should properly say which tokens are being generated by them rather than being taken from the macro call itself.
TC: We had earlier discussed `sort` as a good example of the value of this lint. Let's write that down.
waffle/TC:
```rust
// classic problem, `sort` uses `&mut self` it doesn't return
// a newly sorted list
let list = list.sort();
// Would not lint:
let list: () = list.sort();
let _: () = list.sort();
let () = list.sort();
// Would still lint:
let _ = list.sort();
```
Josh: It would be worth turning this up and doing a crater run. We might consider turning this up to default warn.
TC: There was a [crater run](https://github.com/rust-lang/rust/pull/112380#issuecomment-1612576955) done on 2023-06-29.
Josh: I'm surprised by point 7 there (`let mut _ = expr`). This isn't legal code.
> 7. Lints fired on let mut? _ = expr: 6154
waffle: This may have been a copy-paste error in the analysis. So it's just `let _` without `mut`.
TC: It sounds like the consensus is that this is a good idea. What's the next step?
Lokathor: Starting an FCP.
Josh: I'll propose T-lang FCP merge.
waffle: So we'll allow-by-default, suggest the changes to the proc macros, then later warn-by-default?
Josh / Lokathor: Yes.
Josh: We may want to draw attention to it, e.g. with a blog post on inside Rust.
Lokathor: Can we tag it for special mention in the release notes?
Josh: Tag it relnotes. I'll do that.
*Consensus*: Let's propose FCP merge. We'll tag this for inclusion in the release notes. The plan is to make this warn-by-default after some time.
---
Josh: Side-note. Someone brought this up to me as surprising:
```rust
x; // drops x
```
waffle: We already have a lint for that. It's on by default. Here's the example: [playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ef74d8282b7de77c78c770c167fc4947).
The lint is: `#[warn(path_statements)]`
(The meeting ended here.)
### "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.
### "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.
### "const-eval: make misalignment a hard error" rust#115524
**Link:** https://github.com/rust-lang/rust/pull/115524
TC: Oli nominated this:
> Nominating for T-lang team discussion. Don't know if you want to FCP this, as it's already in line with the const UB RFC (if your code exhibits UB at compile-time, but passes, we are allowed to break it later)
TC: RalfJ commented:
> I don't even know of an example where this is a breaking change... So crater seems unnecessary to me.
>
> This is a kind of funny FCP since it turns out the breaking change accidentally happened in [#104616](https://github.com/rust-lang/rust/pull/104616), we're now just removing some dead code.
>
> > Ah, the lint docs actually have an [example of code](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=2597104ff53b9621a58f6241a6f09afe) that did trigger the lint. So this is a breaking change after all.
### "Object lifetime defaults of GATs are not respected" rust#115379
**Link:** https://github.com/rust-lang/rust/issues/115379
TC: fmease nominated this:
> Nominating this for lang team discussion since I really don't know if this works as intended or not.
>
> To infer the default trait object lifetime of a trait object type, we first look at the bounds on the relevant type parameter of the containing generic type. According to my interpretation of the Reference, RFC 599 and RFC 1156, any kind of generic type can be an elegible container type, not just ADTs. However, if the containing generic type is a GAT, the compiler doesn't properly take into consideration the bounds on its type parameters. The RFCs obviously predate GATs.
### "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. We're planning to read this RFC in an upcoming design meeting.
### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418
**Link:** https://github.com/rust-lang/rust/pull/106418
TC: In the 2023-08-29 meeting we decided that we did have reservations and wanted to see what T-libs-api came back with. scottmcm left a comment in the thread to that effect. We're still waiting on the response.
### "dyn Trait comparison should not include the vtable pointer" rust#106447
**Link:** https://github.com/rust-lang/rust/issues/106447
TC: The FCP to close this issue has been completed. However, @Amanieu is still [looking](https://github.com/rust-lang/rust/issues/106447#issuecomment-1566147477) for a way forward. There's been some [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/dyn.20Trait.20pointer.20comparisons) on Zulip about this.
### "Tracking Issue for the Rust specification" rust#113527
**Link:** https://github.com/rust-lang/rust/issues/113527
TC: We've created a new [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr) for this work.
TC: A [job description](https://hackmd.io/tAC6D9SOT1ChxIJ2m1VQ2Q) for the editor has been discussed. There seems to be consensus to move forward on the hiring process.
TC: There is [outstanding discussion](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/the.20name.20of.20the.20doc) on the appropriate name of this document.
TC: There is an outstanding [discussion](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/goals.20.2F.20conformance.20.2F.20just.20describing.20a.20ref.20impl.3F) ongoing about the goals of the specification.
TC: Niko has [proposed](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/selection.20process) to create the team, with pnkfelix and Mara as the leads, and for that team to work to draft a new set of requirements.
### "Disallow *references* to `static mut` [Edition Idea]" rust#114447
**Link:** https://github.com/rust-lang/rust/issues/114447
TC: We discussed on 2023-09-05 and the consensus was in favor of going in this direction. We left a comment with the path forward and labeled it `E-help-wanted`.
### "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.
### "Parse unnamed fields and anonymous structs or unions" rust#114782
**Link:** https://github.com/rust-lang/rust/pull/114782
TC: We agreed in the 2023-09-05 meeting that `ty` should not parse anonymous types.
### "Guarantee representation of None in NPO" rust#115333
**Link:** https://github.com/rust-lang/rust/pull/115333
TC: In the 2023-08-29 meeting we decided to tag this with T-libs-api, untag T-libs, and propose FCP merge. tmandry has done this, and it is now waiting on checkboxes (from Niko and pnkfelix on T-lang).
### "Cargo Check T-lang Policy" rfcs#3477
**Link:** https://github.com/rust-lang/rfcs/pull/3477
TC: We agreed on final language in the 2023-08-29 meeting. This is now entering FCP.
## Action item review
* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)
## Pending lang team project proposals
None.
## PRs on the lang-team repo
### "Add size != stride to frequently requested changes" lang-team#216
**Link:** https://github.com/rust-lang/lang-team/pull/216
TC: The FCP merge for this is complete. It just needs to be merged.
## RFCs waiting to be merged
None.
## `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.
### "Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024" rust#112038
**Link:** https://github.com/rust-lang/rust/pull/112038
TC: This item is nominated; let's discuss it there.
### "closure field capturing: don't depend on alignment of packed fields" rust#115315
**Link:** https://github.com/rust-lang/rust/pull/115315
TC: This item is nominated; let's discuss it there.
### "document ABI compatibility" rust#115476
**Link:** https://github.com/rust-lang/rust/pull/115476
TC: We discussed this in the 2023-09-05 triage and in the 2023-09-06 planning meeting and were +1 on it. It's waiting on T-opsem to confirm they have reviewed it.
TC: I've [asked](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Document.20ABI.20compatibility.20.23115476/near/390585077) (on 2023-09-12) T-opsem about what they want to do here.
### "const-eval: make misalignment a hard error" rust#115524
**Link:** https://github.com/rust-lang/rust/pull/115524
TC: This item is nominated; let's discuss it there.
## Proposed FCPs
**Check your boxes!**
### "unsafe attributes" rfcs#3325
- **Link:** https://github.com/rust-lang/rfcs/pull/3325
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911253):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * ~~change-syntax-to-drop-parentheses~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974
> * ~~maybe-make-this-part-of-next-edition~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458690311
> * syntax-not-ideal (https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911218):
> @rfcbot merge
### "RFC: Unicode and and escape codes in literals" rfcs#3349
- **Link:** https://github.com/rust-lang/rfcs/pull/3349
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747916):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * ~~raw-byte-strings-with-unicode~~ resolved by https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1688688433
> * ~~waiting-on-update-re-using-char-and-string-tables~~ resolved by https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1688710635
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889):
> I do think we should permit `br"¥¥¥"`, but I don't think we should make any of the other changes proposed in that table, for the reasons @m-ou-se stated.
>
> I'm going to go ahead and propose FCP for this. This does *not* preclude making further changes to how this information is presented.
>
> @rfcbot merge
>
> @rfcbot concern raw-byte-strings-with-unicode
### "Add `f16` and `f128` float types" rfcs#3453
- **Link:** https://github.com/rust-lang/rfcs/pull/3453
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3453#issuecomment-1665987694):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @Amanieu
> * [x] @BurntSushi
> * [x] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3453#issuecomment-1665987676):
> Since we define `f32` and `f64` to be IEEE `binary32` and `binary64`, it seems entirely reasonable to also include `binary16` and `binary128` as well, working analogously.
>
> Let's see what others think:
> @rfcbot fcp merge
>
> Though I do expect that this will be non-trivial to stabilize, in terms of implementation effort, like how `u128` was easy to RFC but very hard to make *work* broadly.
>
> Compiler folks: Please comment if you think this should be postponed as impractical to implement in the foreseeable future.
>
> (Practically, we might not accept `f128: Display + FromStr` for a while even on nightly, because of size impacts of being able to accurately print/parse such precision, for example.)
>
### "Tracking issue for dyn upcasting coercion" rust#65991
- **Link:** https://github.com/rust-lang/rust/issues/65991
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/65991#issuecomment-1670127912):
> Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [ ] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * ~~ensure-we-discuss-lcnr's-thoughts-in-triage~~ resolved by https://github.com/rust-lang/rust/issues/65991#issuecomment-1688682808
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/65991#issuecomment-1670127881):
> Following up on: https://github.com/rust-lang/rust/issues/65991#issuecomment-1640732308
>
> After a few consecutive weeks discussing of the data presented in https://github.com/rust-lang/rust/issues/112355, T-lang believes this is ready to stabilize.
>
> [2023-08-01 hackmd](https://hackmd.io/eEpxNWhQTauw9LzsrZqBkQ#%E2%80%9CTracking-issue-for-dyn-upcasting-coercion%E2%80%9D-rust65991)
>
> [2023-08-08 hackmd](https://hackmd.io/VY0E31zbTMCRXx-BZRluxA#%E2%80%9CTracking-issue-for-dyn-upcasting-coercion%E2%80%9D-rust65991)
>
> The basic conclusion is that we think the cost of this will be limited. Namely, sufficiently limited that we can, if necessary, invest in an opt-out mechanism *at some future date*; we do not need to block stabilization today on the addition of a hypothetical opt-in mechanism, because we think migrating to an opt-in mechanism will be overly disruptive to Rust developers.
>
> @rfcbot fcp merge
>
### "Stabilise inline_const" rust#104087
- **Link:** https://github.com/rust-lang/rust/pull/104087
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231887):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * ~~expectations-around-panics-in-inline-const~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210
> * optimization-dependent-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210)
> * ~~post-monomorphization-errors~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1448730779
> * should-unused-code-cause-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1410921524)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231871):
> Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
>
> @rfcbot fcp merge
### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378
- **Link:** https://github.com/rust-lang/rust/pull/107378
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287200):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * elaborate-cases-and-future-directions (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
> * why-not-higher-rank (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287177):
> We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:
>
> @rfcbot merge
>
> We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.
### "TAIT defining scope options" rust#107645
- **Link:** https://github.com/rust-lang/rust/issues/107645
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789843):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * encapsulation-is-too-powerful (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
> * nested-modules-can-always-define-but-nested-functions-cannot (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789814):
> @rfcbot fcp merge
>
> We held a design meeting yesterday where we reviewed [this document](https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2023-05-31-TAIT-stabilization.md) prepared by @oli-obk and TC (not sure github name) but also with feedback/input from @matklad and others, particularly around IDE requirements.
>
> The document proposed the following resolution to this issue:
>
> - The hidden type may be constrained only within the scope of the item (e.g. module) in which it was introduced, and within any sub-scopes thereof, except that:
> - Functions and methods must have the hidden type that they intend to constrain within their signature -- within the type of their return value, within the type of one or more of their arguments, or within a type in a bound.
> - Nested functions may not constrain a hidden type from an outer scope unless the outer function also includes the hidden type in its signature.
> - A hidden type is considered to appear within the signature if it appears directly or is reachable via traversing field or other element types or via normalization.
> - The hidden type may be constrained by functions, methods, constants, and statics.
>
> The doc goes into more detail about the justifications and alternatives.
>
> Given all this, I propose to merge and accept this proposal.
### "Report monomorphization time errors in dead code, too" rust#112879
- **Link:** https://github.com/rust-lang/rust/pull/112879
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/112879#issuecomment-1677698959):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * incremental (https://github.com/rust-lang/rust/pull/112879#issuecomment-1683368091)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/112879#issuecomment-1677698927):
> @rfcbot fcp merge
>
> We agreed in last week's lang team meeting to FCP this. My understanding is that this removes all(?) errors that are dependent on optimization flags (e.g. debug vs release), but does not tackle the difference between `check` and `build`.
>
> My [above comment](https://github.com/rust-lang/rust/pull/112879#issuecomment-1641214618) still applies to what's being FCP'd: This FCP does not itself establish a policy that we will commit to this kind of behavior going forward. A crater run would be informative in terms of both build failure regressions and performance (if we are set up to collect performance data).
>
> ---
>
> I'm still trying to understand why there were regressions on debug builds too. I'm guessing it's because we optimized dead code out even in debug mode? That would suggest that there are going to be ecosystem crates which used to build but do not build anymore, in either debug or release.
### "FCP process: Require 2/3 majority for FCP" rust#114986
- **Link:** https://github.com/rust-lang/rust/issues/114986
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/114986#issuecomment-1684911463):
> Team member @RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @Amanieu
> * [x] @BurntSushi
> * [x] @CAD97
> * [x] @Dylan-DPC
> * [x] @JakobDegen
> * [ ] @Mark-Simulacrum
> * [x] @RalfJung
> * [x] @cuviper
> * [x] @digama0
> * [x] @dtolnay
> * [x] @joshtriplett
> * [x] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pietroalbini
> * [ ] @pnkfelix
> * [x] @saethlin
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * lack-of-voice (https://github.com/rust-lang/rust/issues/114986#issuecomment-1685080439)
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/114986#issuecomment-1684911460):
> @rfcbot fcp merge
### "`c_unwind` full stabilization request: change in `extern "C"` behavior" rust#115285
- **Link:** https://github.com/rust-lang/rust/issues/115285
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/115285#issuecomment-1694767772):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/115285#issuecomment-1694767763):
> @rfcbot merge
### "Guarantee representation of None in NPO" rust#115333
- **Link:** https://github.com/rust-lang/rust/pull/115333
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/115333#issuecomment-1697980592):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Amanieu
> * [ ] @BurntSushi
> * [x] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/115333#issuecomment-1697979984):
> @rfcbot fcp merge
### "document ABI compatibility" rust#115476
- **Link:** https://github.com/rust-lang/rust/pull/115476
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/115476#issuecomment-1707138758):
> Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * make-sure-t-opsem-has-chance-to-look-at-this-before-merging-it (https://github.com/rust-lang/rust/pull/115476#issuecomment-1707146613)
>
> 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/115476#issuecomment-1707138705):
> The T-lang design team discussed this PR briefly in triage meeting.
>
> We agreed with @RalfJung that this is something that needs documentation, and it appears that this text is not adding anything new, but rather documenting the existing rules as they are understood. Therefore, we are happy to go ahead with a T-lang FCP.
>
> In addition, however, we thought that this seemed like it may overlap with the expertise of T-opsem, and therefore in addition to the T-lang FCP, we also are nominating this for T-opsem to look at to ensure that they have a chance to sign off on the text as written here.
>
> @rfcbot fcp merge
>
>
### "Stabilize `impl_trait_projections`" rust#115659
- **Link:** https://github.com/rust-lang/rust/pull/115659
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/115659#issuecomment-1711023204):
> Team member @compiler-errors has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @BoxyUwU
> * [ ] @aliemjay
> * [x] @compiler-errors
> * [ ] @jackh726
> * [ ] @joshtriplett
> * [ ] @lcnr
> * [ ] @nikomatsakis
> * [x] @oli-obk
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @spastorino
> * [x] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/115659#issuecomment-1711023196):
> @rfcbot fcp merge (see stabilization report above)
## Active FCPs
### "Cargo Check T-lang Policy" rfcs#3477
**Link:** https://github.com/rust-lang/rfcs/pull/3477
### "closure field capturing: don't depend on alignment of packed fields" rust#115315
**Link:** https://github.com/rust-lang/rust/pull/115315
## P-critical issues
None.
Sign in with Wallet
Connect another wallet