---
title: Triage meeting 2023-07-25
tags: triage-meeting
url: https://hackmd.io/Hoo205tDQc6vwWAYaYF37g
---

# T-lang meeting agenda

* Meeting date: 2023-07-25

## Attendance

* Team members: nikomatsakis
* Others:

## Meeting roles

* Action item scribe:
* Note-taker:

## Scheduled meetings
- "Capturing lifetimes in RPITITs" [#215](https://github.com/rust-lang/lang-team/issues/215)
- tmandry owning the doc, niko to give feedback in a timely fashion

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

## Announcements or custom items

### Spec editor selection

Joel Marcey: Following up on the Zulip discussion. I'm looking to figure out how we should pick the candidate for spec editor role. Subteam isn't formed yet. There's a chicken-and-egg problem.

joshtriplett: Seems like we should form the subteam. Does anyone in this room feel they need to be involved in selecting editor but not in the subsequent spec work? If not, shall we just make the subteam and have the subteam set requirements and interview?

nikomatsakis: Do we just need to move from the bullet points and make the decision?

joelmarcey: I've got some initial candidates and I'm at the point where we need to figure out the subteam.

joshtriplett: Given that we signed off on the original RFC, we don't necessarily need a full team sign-off on their being a subteam. The question is who will the initial members be. Or at least who from our perspective.

nikomatsakis: I don't think we know that exactly as we don't have a list.

joshtriplett: Need someone from lang, opsem. Do we need someone from libs, given that we're not specifying the library yet? May want to add someone if they have interest in any case.

nikomatsakis: types team.

nikomatsakis: at some point I was tossing around [this hackmd](https://hackmd.io/fQcfuJ6oTvSWNvLXnMNt7A) with a draft for how this might work.

joelmarcey: can I throw my hat in the ring?

nikomatsakis: does it make sense for you to be a decision maker for what goes into final spec?

joelmarcey: being part of the process, and because I have experience in spec authoring.

joshtriplett: shouldn't try to decide in *this* meeting.

nikomatsakis: Yeah, and to be clear, I'm not disputing anybody's right to anything, just clarifying what the expectations are of members basically. We should draw up some proposal offline and move forward. The other question is how you've integrated in the past with interviewing.

joshtriplett: we prob want to move quickly, draw up some rough requirements from subteam, and then have those be used to get pool of candidates and have some folks from team involved in interview process, if nothing else to ensure they are someone they can work with

joelmarcey: I have a job description that is a starting point.

joshtriplett: A draft seems like a great way to start a discussion.

joshtriplett: process for how we will make decision:

nikomatsakis: usual process is kind of drawing up initial slade of leads and letting team drive its own membership going forward. A PR with a charter on the lang-team repo, with FCP, should suffice given that we already had the spec RFC.

joshtriplett: PR should include how membership is maintained going forward (does team determine new people to add, does parent team decide new people to add?)

## Action item review

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

## Pending lang team project proposals

None.

## PRs on the lang-team repo
### "Expand variadic generics design notes" lang-team#212

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

tmandry to merge.

### "Frequently requested changes: `return expr if condition`" lang-team#213

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

in FCP. scott/pnkfelix have not checked your boxes.

## 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: Last week we discussed and agreed to proceed to an FCP this week if no data had been provided. @nikomatsakis had posted a request on the ticket for this data with instructions on how to collect it. Multiple people have now run this test and reported data [here](https://github.com/rust-lang/rust/issues/112355). Surveying the results, the cost seems to be around 0.5% - 2% (overall).

Points raised in discussion:

* This data shows vtable sizes for most traits is not affected, but also that there are some traits that do get impacted (e.g., a trait in the `wgpu_core` crate whose vtables grew from 20 to 32 bytes, an 80% increase).
* We are open to an
* *opt-out* at the trait level
* LTO or other compilation time options
* Do we want to block on this?
* Why?
* It's a breaking change to opt a trait out.
* Why not?
* Does it matter that this is a breaking change?
* We are already paying the size, but this commits to it in a "new way".
* People using it are saying that they
* Question for today:
* Do we want an opt-out?
* Do we care to block?

tmandry: I haven't seen anybody say that it's blocking or affecting their project.

nikomatsakis: I feel like this is a real problem that should be addressed but I don't really know the parameters -- who needs it? For what? Is LTO ok?

One option:

* create an *experimental* (non-RFC'd) attribute for disabling it at trait level
* let people use it on nightly and leave comments
* if there is demand, we can convert to an RFC
* stabilize this

joshtriplett: Anyone want to block stabilization waiting on an opt-out?

tmandry: My concern is that adopting it is a breaking change, but I'm fine with stabilizing and adding in parallel.

nikomatsakis: May be a moot point because charleslf is super fast but I can leave a comment that, based on the data we've gotten, we are happy to move forward. The numbers that are showed show that an opt-out may be useful.

joshtriplett: It would be helpful also to clarify what the data actually means.

nikomatsakis: yes, it's not going to make the crates 80% bigger, just some number of vtables.

### "Create `unnecessary_send_constraint` lint for `&(dyn ... + Send)`" rust#110961

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

TC: The FCP to merge has finished. Perhaps it should be merged and the tag should be removed?

Done.

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

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

TC: @petrochenkov [reports](https://github.com/rust-lang/rust/pull/113126#issuecomment-1647895643) being ready to stabilize most of [RFC 2145](https://github.com/rust-lang/rust/issues/48054).

joshtriplett: We should start FCP

tmandry: first I've seen of this RFC...what's the plan?

nikomatsakis: went from rules that have false positives and annoying rules to more seantics analysis. Don't remember all the details anymore in terms of the most annoying cases.

joshtriplett: crater run found

## Proposed FCPs

**Check your boxes!**
### "Lower `Or` pattern without allocating place" rust#111752

- **Link:** https://github.com/rust-lang/rust/pull/111752
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/111752#issuecomment-1641010420):
> Team member @scottmcm 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/pull/111752#issuecomment-1641010396):
> Thanks for the summary, @cjgillot !
>
> I think lowering short-circuiting operators as control flow makes good sense, and fits well with future potential for things like let chains or scoping for an `is` operator. This does suggest that if we ever allow overriding them then those overrides ought to work via control-flow as well, but I don't see that as blocking anything that we'd need. (For example, we could still lower the LHS to a call that returns an `Option`, and have the lowering work on that `Option`.)
>
> @rfcbot merge

TC: @scottmcm proposed a FCP to merge last week.

### "add notes about non-compliant FP behavior on 32bit x86 targets" rust#113053

- **Link:** https://github.com/rust-lang/rust/pull/113053
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/113053#issuecomment-1613366741):
> 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
> * [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/113053#issuecomment-1613366705):
> @rfcbot fcp merge
>
> Here's what I [wrote in zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Document.20.28lack.20of.29.20floating.20point.20conformance.20on.20x86-32/near/370819815) about why T-lang should merge this:
>
> > my current take is: Its better for the docs to be updated to reflect reality, especially if its to point out a place where we are not conforming to an assumed specification. We can always change the docs later if we improve our conformance in some manner.
> >
> > At this point I'm not sure if we should force all such doc improvements to go through lang-team FCP, but its also safer to just do the FCP (and then let the team debate later if we want to follow less strict policy)

TC: There's an ongoing proposed FCP here. @RalfJung has [asked](https://github.com/rust-lang/rust/pull/113053#issuecomment-1644164828) recently if maybe we should just have a separate page for platform errata.

### "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: UTF-8 characters and escape codes in (byte) string 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

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

- **Link:** https://github.com/rust-lang/rfcs/pull/3399
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3399#issuecomment-1640750937):
> 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
> * [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/3399#issuecomment-1640750790):
> @rfcbot merge

### "Tracking issue for the `thiscall` calling convention" rust#42202

- **Link:** https://github.com/rust-lang/rust/issues/42202
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/42202#issuecomment-1616187726):
> Team member @petrochenkov has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Aaron1011
> * [x] @cjgillot
> * [x] @compiler-errors
> * [x] @davidtwco
> * [x] @eddyb
> * [x] @estebank
> * [ ] @jackh726
> * [ ] @lcnr
> * [x] @matthewjasper
> * [x] @michaelwoerister
> * [ ] @nagisa
> * [x] @oli-obk
> * [x] @petrochenkov
> * [ ] @pnkfelix
> * [ ] @wesleywiser
>
> 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/42202#issuecomment-1616187723):
> @rfcbot fcp merge
> Stabilization report: https://github.com/rust-lang/rust/issues/42202#issuecomment-1565207948

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

### "Mention style for new syntax in tracking issue template" rust#113586

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

## Active FCPs
### "make `noop_method_call` warn by default" rust#111916

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

TC: This has 4/5 boxes checked, no concerns.

### "Frequently requested changes: `return expr if condition`" lang-team#213

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

(none yet, move things from the section below as they are discussed)

### "Clearly specify the `instruction_set` effects" reference#1307

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

TC: This should enter FCP merge, and @rfcbot is asking someone to add a `final-comment-period` label.

done.

### "Mention style for new syntax in tracking issue template" rust#113586

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

TC: Discussed under proposed FCPs.

joshtriplett: this is effectively what the style team was created for. This PR adds to the template for new tracking issues. We'll have to go back to the existing tracking issues and update them.

Lokathor: just incomplete to not have formatting.

joshtriplett: yes and if we ship without formatting it causes breakage when we do.

### "Tracking issue for the `thiscall` calling convention" rust#42202

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

TC: This was discussed last week. We decided to do a poll to get t-lang sign-off. It has 5/5 boxes checked now. Maybe this should be unnominated?

Josh to unnominate.

### "feat: `riscv-interrupt-{m,s}` calling conventions" rust#111891

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

TC: @jackh726 is [asking](https://github.com/rust-lang/rust/pull/111891#issuecomment-1598021106) for t-lang to sign-off on adding a feature gate for two new calling conventions.

left comment, we're good with it.

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

nikomatsakis: Last time we talked about this, it was revealed that warnings doesn't do what I thought it did, which is "the set of things that are warn-by-default".

joshtriplett: We had a discussion a long time ago that the people who are doing `#[deny(warnings)]` want anything that would've been a warning to be an error, which isn't quite how it's implemented, what do people expect when they say allow-warnings?

tmandry: and things like cap-lints are an issue here too. I think in source code, the inner source should override, but the CLI should more or less override those.

nikomatsakis: you think CLI should override no matter where it appears in the source?

tmandry: that's my gut instinct.

joshtriplett: what do we do today?

nikomatsakis: I guess I think of the CLI as the "very root level", but I can see why that wouldn't be what you wanted.

We can't settle this right now.

### "nightly/beta regression: fnptrs with types containing `()` is warned to be not FFI-safe, while it is before" rust#113436

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

unnominated

### "Make `unconditional_recursion` warning detect recursive drops" rust#113902

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

fcp merge'd.

## Nominated RFCs, PRs and issues NOT discussed this meeting

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

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

### "Rename and allow `cast_ref_to_mut` lint" rust#113422

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

TC: There's a [feeling](https://github.com/rust-lang/rust/pull/113422#issuecomment-1624280691) that this does not need a t-lang sign-off, but t-compiler wanted to [check](https://github.com/rust-lang/rust/pull/113422#issuecomment-1629260277) that t-lang agreed.

### "Document soundness of Integer -> Pointer -> Integer conversions in `const` contexts." rust#113510

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

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

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

TC: This is a blocker for the stabilization of `inline_const`. We discussed this last week and decided we were OK with it. @tmandry posted a comment asking about a possible crater run.

### "RPITIT is allowed to name any in-scope lifetime parameter, unlike inherent RPIT methods" rust#112194

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

TC: We'll be talking a lot about capture rules tomorrow.

### "Explicit Tail Calls" rfcs#3407

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

TC: @WaffleLapkin has been [working](https://github.com/rust-lang/rfcs/pull/3407#issuecomment-1639625362) on an implementation.

### "let-else does not support `else if`" rust#111910

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

TC: @lcnr wants to do this. It's waiting on a t-lang member to sponsor an experiment.

### "Make pointer_structural_match normal and warn" rust#110166

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

TC: This has completed its FCP merge, but it is [waiting](https://github.com/rust-lang/rust/pull/110166#issuecomment-1565346604) on the author for some final changes.

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

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

TC: Discussed under proposed FCPs.

### "make `noop_method_call` warn by default" rust#111916

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

TC: Discussed under proposed FCPs.

### "add notes about non-compliant FP behavior on 32bit x86 targets" rust#113053

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

TC: Discussed under proposed FCPs.

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

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

TC: Discussed under waiting on team.