Triage meeting 2023-09-19

--- title: Triage meeting 2023-09-19 tags: triage-meeting, minutes, T-lang date: 2023-09-17 url: https://hackmd.io/MC5VNYjzQpO1UqRsfyvnxA discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-09-19 --- # T-lang meeting agenda * Meeting date: 2023-09-19 ## Attendance * Team members: nikomatsakis, tmandry * Others: TC, Lokathor, eholk, dtolnay, waffle ## Meeting roles * Minutes, driver: TC ## Scheduled meetings - "RFC review Inherent Trait Impls -- RFC#2375" [#217](https://github.com/rust-lang/lang-team/issues/217) - "RFC review: Add f16 and f128 float types -- RFC#3453" [#218](https://github.com/rust-lang/lang-team/issues/218) - "RFC review: MaybeDangling -- RFCS#3336" [#219](https://github.com/rust-lang/lang-team/issues/219) Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7. ## Announcements or custom items ### Niko to create triage subteam NM: I'm creating a new triage subteam. nikomatsakis: Maybe call it "prioritization" :) NM: It would have TC on it for the moment as the lead, to make official that role and the great work he's been doing, (thanks TC, you rock), but we hope it would grow. NM: Should we call this triage? TC: Triage is shorter; we'll be typing this a lot. NM: I should have called the one for T-compiler triage. *Consensus*: We'll call this triage. ### tmandry nominated for co-lead NM: I've nominated tmandry for the role of co-lead of T-lang. [checkboxes here](https://github.com/rust-lang/team/pull/1077#issuecomment-1726227473) NM: We're running an FCP process for this. Congratulations to tmandry. ## Nominated RFCs, PRs and issues ### "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. We left a comment to that effect. Should this remain nominated? NM: I don't see why we'd leave this nominated. I don't think we have any role left. I'll unnominate. *Consensus*: We'll unnominate this. ### "Stabilize `impl_trait_projections`" rust#115659 **Link:** https://github.com/rust-lang/rust/pull/115659 TC: The consensus last meeting was that T-lang doesn't need to approve this. It's gone into FCP merge anyway. We should unnominate this. NM: Sounds fine. tmandry: I'll unnominate that. *Consensus*: We'll unnominate this. ### "Add allow-by-default lint for unit bindings" rust#112380 **Link:** https://github.com/rust-lang/rust/pull/112380 TC: The consensus last meeting was to propose FCP merge, to tag this for inclusion in the release notes, and to make this warn-by-default after some time. It's now entering FCP. Do we want to unnominate? NM: We should unnominate. I'll unnominate. *Consensus*: We'll unnominate this. ### "RFC: Unicode and escape codes in literals" rfcs#3349 **Link:** https://github.com/rust-lang/rfcs/pull/3349 TC: This is now entering FCP. Perhaps we should remove the nomination. tmandry: I don't see why it should be nominated. I'll unnominate it. *Consensus*: We'll unnominate this. ### "Cargo Check T-lang Policy" rfcs#3477 **Link:** https://github.com/rust-lang/rfcs/pull/3477 TC: The FCP merge is complete. Who wants to merge this? tmandry: I'll merge it. *Consensus*: We'll merge this. ### "Stabilize `async fn` and return-position `impl Trait` in trait" rust#115822 **Link:** https://github.com/rust-lang/rust/pull/115822 TC: CE posted the comprehensive stabilization report written by himself, nikomatsakis, tmandry, and myself. Does someone want to propose FCP merge? NM: I just posted a summary comment. There's been quality discussion. There are some valid possible tweaks. I think it's a good idea to do a merge. But we should raise a concern until we discuss what alternatives if any that we want to pursue. What do you think tmandry? ... (Discussion summarizing what's been discussed on the stabilization PR.) ... (Discussion about what whether we would block the 2024 lifetime capture rules on TAIT, exact capturing by borrow checking, or both.) TC: For the 2024 lifetime capture rules, we had certainly assumed that TAIT would be stabilized ahead of the new rules, as the new rules do break some existing patterns, and TAIT would be needed to give people an option to fix those. NM: That's right, and we may have an automatic conversion that would rewrite those cases to use TAIT anyway. So the exact capturing isn't a blocker for the new rules, but TAIT or something that accomplishes that thing is. TC: This is also what we did a crater run about. So we have some numbers quantifying the amount of code affected in the ecosystem. ... TC: We may have at least a partial solution to the exact capturing sooner than we might think. CE and I were talking yesterday, and I had proposed that we add a new pass early in the process that just looked at the signatures and `impl` generics and worked out the transitive outlives relationships without full borrow checking, as one of the concerns is leaking borrowck information into the opaques (which isn't possible if we only look at the signatures and `impl` items). CE described the complications with doing that as that 1) we have to normalize the projections to be able to resolve the explicit and implicit outlives bounds, and 2) that negative proofs are difficult and important to get right. I pointed out that in this case, a partial negative proof is OK because it doesn't result in unsoundness, only overcapturing. And I noted that for TAIT, we had decided to simply not normalize projections for now when doing the check for the signature restriction as a current compiler limitation, and suggested that might be an option here. A few hours later CE had working code (because he's that amazing). NM: Is that the PR I saw go up? TC: It may be. ... NM: Nobody is actually arguing about the new capture semantics. tmandry: I don't see any blockers to stabilization. We should discuss what exactly we're going to stabilize. NM: What are the deadlines? tmandry: Oct 5 is the next cut-date. NM: I'm tempted to say, let's just stabilize RPITIT. If we could get that out by the next version, that'd be great. No-one has any concerns about RPITIT. TC: +1, I had the same thought. eholk: Is RPITIT compatible with how `async fn` gets desugared? NM/TC: Yes. waffle: Will the rules for capturing be the same for AFIT/RPITIT be the same? NM: Yes. tmandry: I'd like to see at least RPITIT. *Consensus*: Let's discuss with the rest of the lang team. TC: If we were to break out RPITIT for stabilization first, what process would we want to follow for that? Would we want to post a new PR and new stabilization report? NM: Yes to both. It'd be cleaner to do it that way. ### "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). Is there anything we can discuss here to move this forward? NM: I'm checking my box. tmandry: It'll need T-libs-api as well to go into FCP. tmandry: I'll nominate this for T-libs-api and unnominate for T-lang. *Consensus*: T-lang has done what it needs to do here. ### "lint towards rejecting consts in patterns that do not implement PartialEq" rust#115893 **Link:** https://github.com/rust-lang/rust/pull/115893 TC: Ralf nominated this for T-lang on 2023-09-17: > @rust-lang/lang I found a surprising gap in our pattern-related future-incompat lints, which lead to us still accepting (without a warning) some consts as patterns that don't even implement `PartialEq`. I think we definitely don't want that (and @oli-obk said the intent of his lints was to catch all such cases), so this PR closes that gap. The new lint is immediately set up to show in cargo's reports. I expect this to be rare (one has to work pretty hard to get such a const to be accepted), so it doesn't seem worth the extra delay of having a phase where the lint only shows up for the local crates. > > So the question for you is, are you okay with consts in patterns requiring _at least_ a `PartialEq` bound? (There might be further restrictions, related to all this "structural equality" business. That doesn't have to be answered here. This is just asking whether we need _at least_ `PartialEq`.) > > If you are curious about what the affected code looks like, here are some examples: > > * [example 1](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=087d68eb0dc70b8740252669d2819177) > * [example 2](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6bdb890bd59ee68265b20b91f63ad766) > > On both cases, the reason the constant isn't `PartialEq` is an unnecessary trait bound introduced by `derive(PartialEq)`. That's why the compiler is still able to generate code that compares the constant with the matched place. These unnecessary trait bounds aren't great, but I don't think that should affect our const-in-match-pattern rules. tmandry: I'm not sure whether `PartialEq` is the trait that we want to use for pattern matching. But I need to think more about this. NM: When this was originally put in, the intent was to leave space for us to move toward either loosening these rules or making them more strict. Is equality the same as matching, or are they fundamentally different operations? I wanted it to be true, but now I just want us to have an answer. tmandry: This may be basically fixing a bug. If that's true, this is fine, but we'd need to do a crater run. NM: There were definitely some cases where you definitely had to call `PartialEq`. We should try to drive this story to ground. If this is fixing a bug, we should do it. tmandry: Does this need FCP? NM: No, if we think it's a bug fix. I'll leave a comment to that effect. *Consensus*: This is a bug fix and does not require an FCP to proceed. ### "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. NM: I do want to see this. (Discussion clarifying the purpose of use-case 4.) NM: My proposal is we should do option 1. But we can FCP it if needed. ... NM: I'll open a [new issue](https://github.com/rust-lang/rust/issues/115980) and FCP it. *Consensus*: We'll confirm we want to do this via a proposed FCP on a [#115980](https://github.com/rust-lang/rust/issues/115980). ### "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. TC: Is there anyone we should ping about that to avoid the bystander effect? tmandry/NM: I'd expect @oli to do that. TC: I'll mention it to @oli then. *Consensus*: We're waiting on oli to report on the root-cause analysis of the 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. tmandry: Is it last-one wins? NM: That's what we have usually done. I'm not thriled about how these are defined. It should be last-one-wins; that's what we've done in the past. NM: It's not "the set of things that are warn by default", which is what one might expect. tmandry: Right, we should just do this. NM: Mark Simalucra(?) drove this in the past. He would know. NM: How is it different depending on what "warnings" means? It seems to have to do with the ordering and how that is significant and it's independent of the definition of "warnings". tmandry: If warnings means the set of all things that are warnings right now, that would disarm the lint, but if it's the set of all default warnings.... NM: People expect the command-line warnings to override what's in the file. tmandry: It's actually like `expect`. It's obvious that `force-warn` should take precedence. tmandry: This feels like something that should have (or already had) a design meeting. NM: Maybe we didn't have a design meeting. Maybe we just talked about this in triage. The lint policy is also relevant. NM: We should write down what the semantics are once and for all. I.e. an RFC. TC: Do we think the work here should be blocked on an RFC, or can we give some way to go forward. *Consensus*: We'll leave this nominated for discussion next week, and NM will leave a comment asking questions. ### "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. tmandry: Does this mean this doesn't break anything on crater? NM: Correct. tmandry: Do we need an FCP? NM: Yes, we need to FCP a new hard error. We did agree that UB-in-const could be a hard error, but that doesn't mean we authorized hard errors everywhere. tmandry: I'll do that. *Consensus*: We'll propose FCP merge. ### "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. NM: I agree it's a bug. TC: Do we leave a comment saying that it's a bug and let him more forward on that basis? NM:: I think so. The `+ 'r` should have been inferred, not defaulted. We wanted this to default: `&'r dyn Trait` -- should default `Ref<'r, dyn Trait>` -- user version of that, so get it from the bound `struct Ref<'r, T: 'r>` NM: We do this in trait parameters, I'm not sure why we wouldn't do this in GAT parameters. tmandry: Agree this is a bug. NM: Maybe we could ping jackh726 to fix. It's definitely a types team issue. tmandry: I'll nominate for T-types. NM: I'll write a comment. waffle: Inference, or deducing, doesn't work for trait objects. NM: The question isn't so much trait objects as it is associated types. waffle: You said we default in traits, but we don't. Here's an example: [Playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a74cb294eb6a370620bf30334cadf55a). ``` error[E0228]: the lifetime bound for this object type cannot be deduced from context; please supply an explicit bound --> src/lib.rs:5:26 | 5 | fn g<'r>(_: &dyn Ref<'r, dyn Inner>) {} | ^^^^^^^^^ For more information about this error, try `rustc --explain E0228`. error: could not compile `playground` (lib) due to previous error ``` NM: ```rust trait Ref<'a, T: 'a + ?Sized> { type Ty; } trait Inner {} fn f<'r, T>(x: <T as Ref<'r, dyn Inner + 'r>>::Ty) { g(x) } fn g<'r, T>(x: <T as Ref<'r, dyn Inner>>::Ty) { g(x) } ``` ``` error[E0228]: the lifetime bound for this object type cannot be deduced from context; please supply an explicit bound --> src/lib.rs:7:30 | 7 | fn g<'r, T>(x: <T as Ref<'r, dyn Inner>>::Ty) { g(x) } | ^^^^^^^^^ ``` NM: I consider this a bug, but it's not specific to GATs. tmandry: We should be getting the same error for GATs. NM: We're getting "lifetime may not live long enough" for GATs. waffle: We're getting `+ 'static`. NM: Well that seems wrong. TC: What's the way forward here? NM: Let's put this example there and assert that these should be the same, we'll nominate this for T-types, and we'll ping jackh726. tmandry: It looks like we're calling for making a potentially breaking change. NM: Right. (The meeting ended here.) ### "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. Amanieu has since responded with: > We discussed this in the libs-api meeting today. We think there are 2 reasonable options for moving forward here: > > 1. Just make `Discriminant` implement `Ord` unconditionally and document the fact that the ordering should not be treated as semantically significant. > 2. Only provide `Ord` on `Discriminant<T>` if `T: OrderedDiscriminant` (subject to bikeshed). `OrderedDiscriminant` is a marker trait which is included by `#[derive(PartialOrd)]`, but can also be implemented manually. > > There was no consensus on which of these is the best approach, but it should help the discussion move forward. ### "RFC: Implementable trait aliases" rfcs#3437 **Link:** https://github.com/rust-lang/rfcs/pull/3437 TC: Niko nominated this on 2023-09-16: > One though -- @Jules-Bertholet -- I'm not sure if the RFC covers it, I didn't have time to read in super detail, but I think that if you are implementing `trait Foo = Bar + Baz`, that implies "unioning" the methods from `Bar` and `Baz` into one impl block. Does the RFC discuss this? > > I have, for a long time, wanted the ability to implement a trait **and** its supertraits together in a single impl block, I wonder if it's worth thinking about that as well, though I'd probably want to separate it out from this RFC. TC: This RFC has also been proposed for a design meeting as an RFC read, but it has not yet been scheduled for one. ### "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. ### "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. ### "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`. TC: Are there any particular people we might want to ping who we know might have an interest in this? ### "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. ## 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 ## RFCs waiting to be merged ### "Cargo Check T-lang Policy" rfcs#3477 **Link:** https://github.com/rust-lang/rfcs/pull/3477 ## `S-waiting-on-team` ### "Tracking issue for dyn upcasting coercion" rust#65991 **Link:** https://github.com/rust-lang/rust/issues/65991 ### "document ABI compatibility" rust#115476 **Link:** https://github.com/rust-lang/rust/pull/115476 ### "const-eval: make misalignment a hard error" rust#115524 **Link:** https://github.com/rust-lang/rust/pull/115524 ### "Stabilize `async fn` and return-position `impl Trait` in trait" rust#115822 **Link:** https://github.com/rust-lang/rust/pull/115822 ### "lint towards rejecting consts in patterns that do not implement PartialEq" rust#115893 **Link:** https://github.com/rust-lang/rust/pull/115893 ## Proposed FCPs **Check your boxes!** ### "RFC: inherent trait implementation" rfcs#2375 - **Link:** https://github.com/rust-lang/rfcs/pull/2375 - [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/2375#issuecomment-1718141313): > 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: > > * decide-on-handling-for-breakage-with-new-trait-methods (https://github.com/rust-lang/rfcs/pull/2375#issuecomment-1718141286) > > 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/2375#issuecomment-1718141286): > We reviewed this in a @rust-lang/lang meeting today, and would like to move ahead with it. > > Regarding the concern of `#[inherent] impl LocalTrait for RemoteType`, the proposed desugaring in the RFC would make that an error, and we do think that should be an error. > > Regarding the concern of `#[inherent] impl RemoteTrait for LocalType` causing addition of defaulted methods to `RemoteTrait` being a breaking change, there *is* a way (albeit annoying) that the crate with that inherent impl can fix such breakage if it arises without changing their API: they could do the desugar manually and only include the methods they want. We could also (as suggested in this thread) add syntax to mark individual methods in a trait impl as `#[inherent]` rather than the whole impl, which would make that workaround easier. Proposal: we should add that to future work and make it an unresolved question whether we need that syntax before stabilizing. > > Another option would be to augment the desugaring to say that "`#[inherent]` does not add an inherent forwarding method if the type has explicitly defined inherent method of the same name.". You could still get breakage that way if you had *multiple* `#[inherent]` blocks and one added a defaulted method conflicting with the other, but that's more far-fetched. > > @programmerjake also made the observation that we might want the ability to have a blanket impl for a variety of types and then have a way to make that impl inherent for a specific type. Proposal: let's similarly add that as potential future work. > > @rfcbot merge > > @rfcbot concern decide-on-handling-for-breakage-with-new-trait-methods ### "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 ### "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 > > ## Active FCPs ### "RFC: Unicode and escape codes in literals" rfcs#3349 **Link:** https://github.com/rust-lang/rfcs/pull/3349 ### "Add allow-by-default lint for unit bindings" rust#112380 **Link:** https://github.com/rust-lang/rust/pull/112380 ## P-critical issues None.