---
title: Triage meeting 2023-06-06
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-06-06

## Attendance

* Team members: Niko, Felix, Scott, Josh, Tyler
* Others: Lokathor, Urgau, TC, Eric Holk

## Meeting roles

* Action item scribe: Tyler
* Note-taker: nikomatsakis

## Scheduled meetings

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

## Announcements or custom items

### rfc for unsafe extern blocks
* PR link: https://github.com/rust-lang/rfcs/pull/3439
* Please have a look

### RPITIT (return position impl trait in trait) refine and experiments

Niko: I reached out to Will Crichton about evaluating this empirically. Anyone interested in working with Will on this?

TC and Tyler expressed interest.

niko: Will left a [comment](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Evaluating.20.60.23.5Brefine.5D.60/near/363929944) in Zulip, follow up? I'd love to hear more details about plan.

### Stabilization schedule for AFIT / RPITIT

nikomatsakis: initially thought we should stabilize RPITIT before AFIT, changed my mind, now think we should stabize them at the same time. If we stabilize RPITIT before AFIT, people might try to emulate AFIT with RPITIT.

* stabilize AFIT + RPITIT together -- what is on nightly now, essentially, except limited to cases that don't need refine (as discussed in the design meeting)
* stabilize some solution for "send bounds" together shortly thereafter -- have to narrow down exactly, could be RTN

joshtriplett: Would we be able to author `AsyncRead` and `AsyncWrite` using what's currently on nightly?

nikomatsakis: yes, though uses of them are likely going to want send bounds.

scottmcm: If we have a case that we are enabling with this?

nikomatsakis: The embassy runtime for embedded async programming uses async fn / and RPITIT and doesn't require send bounds.

nikomatsakis: Other one is traits that want to force a `Send` return value can be modeled like this

trait Foo {
    // trait definition needs Send
    fn bar(&mut self) -> impl Future<Output = ()> + Send;
}

impl Foo for SomeType {
    // impl does not because of leakage
    async fn bar(&mut self) { } 
}

joshtriplett: other option is traits that don't need send at all?

nikomatsakis: yes, what doesn't work is "some consumers need, some don't"

joshtriplett: arguably it's at least as capable as current async-trait in the ecosystem, where person authoring trait has to decide in advance whether they want send or not

nikomatsakis: correct! good characterization.

joshtriplett: seems worth communicating/documenting that, not reducing capabilities, haven't yet extended them.

nikomatsakis: might be nice to write an Inside Rust blog post to communicate this a bit, this conversation has helped me to see the key points

## Action item review

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

## Pending lang team project proposals

None.

## PRs on the lang-team repo

None.

## RFCs waiting to be merged
### "Return position `impl Trait` in traits" rfcs#3425

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

scottmcm: I nominate niko as the pFCP-er 🙃

nikomatsakis: grrr, fair :angry:

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

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

nikomatsakis: WaffleLapkin is authoring some changes to allow us to measure memory impact. I found one team willing to run this on some real-world code and which cares a lot about memory usage.

scottmcm: should we set a deadline?

nikomatsakis: good question. I pinged Waffle yesterday and they said they'd have a PR soon, but setting a deadline makes sense.

pnkfelix: either waiting-on-author or waiting-on-data...?

joshtriplett: kind of like waiting-on-perf?

nikomatsakis: I'm not willing to wait on data, but I am willing to wait on somebody actively waiting on data.

nikomatsakis to leave comment asking for status, we'll look at this again in a future meeting

### "Allow partially moved values in match" rust#103208

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

*discussion whilst Niko was distracted*

Conclusion: Generally positive, but encourage T-opsem to make final decision (via FCP).

scottmcm: who officially owns mir building?

nikomatsakis: lang, but some areas -- most notably match desugaring -- are kind of opsem or overlapping.

lokathor: during opsem triage today, a lot of the issues covered had to do with layout. Some issues in the UCG that had to do with layout guarantees where opsem said "not our concern, pass back to lang". If lang team wants to improve guarantees on that front, please do so.

nikomatsakis: That makes sense, but this issue feels like an area where opsem would like to own it -- comes back to "what is a place".

scottmcm: interesting diffs, turns FakeReads into PlaceMentions, makes sense, but implications are not obvious. Would be great to have a writeup.

nikomatsakis: Let's hand it off, seems like we all agree we are generally in favor and would like opsem to make final decision.

### "resolve: Remove artificial import ambiguity errors" rust#112086

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

joshtriplett: ...removing some errors we added back in 2018 edition that we added for theoretical future proofing?

scottmcm: what is the `_` about in the example?

*some discussion, conclusion seems to be that `use S as _` means `use S as ArbitraryName`.*

joshtriplett: This only talks about "use type as something", I wonder if it also applies to modules? What about this example....?

use some::module; // Outer

fn main() {
    use some_other::module; // Inner

    use module::item; // does this produce an ambiguity error on `module`?
}

Today:

mod foo { pub struct S; }

fn main() {
    mod foo { pub struct S; }

    use foo::S; // error[E0659]: `foo` is ambiguous

    let s = S;
}

scottmcm to start FCP

scottmcm: kicked off: <https://github.com/rust-lang/rust/pull/112086#issuecomment-1579271190>

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

joshtriplett: bunch of discussion about syntax

nikomatsakis: yes, we've not reached a "best answer"

joshtriplett: sense for what most people want? I'm holding this concern on behalf of "issue doesn't seem to have a consensus"

nikomatsakis: I have a vague preference for `#[unsafe(...)]` but not a strong one

joshtriplett: either `()` or `{}` works well for me, but not ` `, we don't normally have unsafe written quite that way

pnkfelix: usually it's `unsafe` + keyword, which isn't the case here

scottmcm: we didn't get a clear consensus, I wonder about value

TC: we asked this ...

lokathor: in general, the unsafe obligations are created obligations for downstream users, and we'd like to highlight that in some way?

joshtriplett: certainly the case that some crates expect other people to handle it, but strictly speaking I think it's discharging an obligation, and then the question is, as part of that, is the crate passing it on to someone else? If so, we don't have any mechanism for that. I think this is closer to "I am discharging the obligation" rather than "declaring the obligation".

nikomatsakis: I think of it as "I am asserting that I know this is unsafe and I have documented it as a linker limitation" (for want of a better mechanism).

joshtriplett: In projects that use `// SAFETY` comments, this should take one.

lokathor: when library declares a function, no way to discharge the obligation?

nikomatsakis: there is, write it in a comment.

scottmcm: yeah, I think writing it in crate docs is all we have

joshtriplett: we don't like it when crates discharge an unsafe obligation and expose a safe interface through which you can use UB? But we have no other mechanism. "invoke the build system" is not a safe operation, so there's no safe operation invoking UB here.

nikomatsakis: we could talk about *adding* a mechanism in the future

TC: would we ever want a mechanism where procedural macros could, in the macro, create an obligation that someone *using* the macro would have to discharge it?

nikomatsakis: I think there probably should be, but I think we shouldn't block on it

lokathor: consensus is that putting unsafe is discharging by passing it downstream?

joshtriplett: it's discharging the user's obligation, but not specific what they are doing with it

nikomatsakis: I don't see how it's any different from any other unsafe block -- you are always asserting that you take responsibility, but you have to figure out how you can justify that. It might be docs but it might be that you know the contexts in which your library are being used (e.g., because it's part of a workspace.)

TC: I brought up the proc macro because I think it affects the syntax.

lokathor: normally when you use an unsafe block, it's always clear whether it's discharging or not

nikomatsakis: I don't agree, consider this, the unsafe block is justifyable with local reasoning

unsafe fn foo(x: *const u32) {
    let y = 22;
    
    let p = &y as *const u32;
    println!("{}", unsafe { *p }); // what is this `unsafe` block doing?
}

tmandry: point is that you can typically use local reasoning

lokathor: when libm writes `#[unsafe(no_mangle)] sqrt`, how do they justify that? is there just a documentation comment put at the libm module?

nikomatsakis: yes. it'd be nice if we established some conventions, but how else are they going to do it?

lokathor: who is at fault?

nikomatsakis: if libm documented that they require nobody else links `sqrt`, then you're at fault.

pnkfelix: it's more complex than that, hard to pinpoint blame.

nikomatsakis: ok, libm is not at fault anyway.

tmandry: there are options where you can get warnings or errors for conflicts, we're taking it for granted that it causes UB, we've not explored the full space.

joshtriplett: We're going on a long tangent about how things could be made safer, or how we could discharge these obligations or track them, I agree it'd be awesome, but in the meantime... it seems like it's not actually critical for us to decide that in order to evaluate syntax.

TC: I agree and I think the syntax would work if you had proc macros that required uses to be unsafe

tmandry: or even a way to declare unsafe crates.

nikomatsakis: I would add that if you were using the linker attributes that can't cause UB, maybe you don't need to write `unsafe`, that'd be nice

Straw poll for syntax:

1) `#[unsafe(attr(...))]`
2) `#[unsafe { attr(...) }]`
3) `#[unsafe attr(...)]`
4) Something else?

joshtriplett: 1 > 2 > 4 > 3 ; I don't think we should introduce a substantially different syntax here than people have seen before.
nikomatsakis: 1 > 2 > 4 > 3 -- revisiting this :)
scottmcm: Weak 1, because I'm not sure the churn from the others is worth it, even though I'm not convinced that 1 is actually the with-a-time-machine best.
tmandry: 3 > 2 > 1
pnkfelix: {1,2} > 3. abstain re: 4.

joshtriplett: Tyler, would you like to talk a bit more about your preferences?

tmandry: It looks more like other of unsafe. We use parentheses for other things. Just have a vague sense that it looks more like other uses of unsafe.

pnkfelix: the people who don't like two, is it curly brace, or spaces?

scottmcm: I actually think I like 2 best but I might vote 1 because of implications of parsing this stuff

tmandry: it seemed like petrochenkov preferred 2 for parsing

scottmcm: we can of course parse #2 just fine but things that needs to be able to handle attributes needs to have a newform

nikomatsakis: I don't think I *don't like* two, one looks more familiar, but I see Tyler's point

joshtriplett: 1 is more familiar, but 2 has literally all 3 kinds of brackets in one line. Feels like people will point to it as examples of unpleasant Rust syntax.

lokathor: the primary argument for 2 is that when you have `attr(...)` you are passing args to attr but you are not passing args to `unsafe`

joshtriplett: I won't block on 2. It seems awkward and we are introducing something *new* here. A new kind of attribute syntax.

nikomatsakis: unsafe attribute syntax.

tmandry: tooling point is interesting. remains to be seen whether existing tooling can parse keywords

lokathor: everybody uses syn, right?

tmandry: but everyone must upgrade syn

nikomatsakis: this feels like a weak objection, we add new syntax all the time, and we don't complain

pnkfelix: people will certainly notice the difference

joshtriplett: yeah, it's certainly not a *quiet* syntax

scottmcm: How do we feel about `unsafe(cfg_attr(foo, no_mangle))` vs `cfg_attr(foo, unsafe { no_mangle })` vs `unsafe { cfg_attr(foo, no_mangle) }` or whatever? Notably, `unsafe{ || something_unsound() }` works because it applies through the closure boundary.

TC: the braces make me feel it must work at every level

tmandry: if we don't we should reconsider the "`unsafe` space" syntax. Braces let you wrap multiple things. Syntax of attributes is much less rich.

pnkfelix: does `#[unsafe { attr1, attr2 }]` have same "effect" as `#[attr1, attr2]` does today?

nikomatsakis: RFC proposed that it flattens, but that was with parens

scottmcm: does comma separated work for top-level attributes?

pnkfelix: I think so

lokathor: no, `#[no_mangle, inline]` doesn't work.

TC: What about outside of the attribute in a function body?:

fn foo() {
    unsafe {
        #[no_mangle] // Is this OK?
        fn bar() { ... }
    }
}

joshtriplett: I *think* we discussed that previously and agreed that it shouldn't?

nikomatsakis: I'm starting to like space

tmandry: me too!

joshtriplett: grumble grumble re space (feels like allowing `else statement;` without braces)

scottmcm: we do have `unsafe impl TrustedLen`, so space isn't unprecedented.

pnkfelix: space with a non-keyword following is what is unprecedented.

lokathor to post something with a few options on threads showing the alternatives

we will revisit this next meeting after we've had some time to ponder, but with a time limit

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

### "RFC: Start working on a Rust specification" rfcs#3355

- **Link:** https://github.com/rust-lang/rfcs/pull/3355
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3355#issuecomment-1513641410):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @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/3355#issuecomment-1513641387):
> @rfcbot fcp merge
>
> We talked about this in the lang team triage meeting and agreed that this is ultimately a council-level decision. That said, it seems like a good idea to get formal lang team buy-in ahead of the council making a decision on this.
>
> Since we can do that now while the council is still forming, I'm opening an FCP for it. **Note that this will still need a _separate_ FCP to actually be merged once the governance council is formed.**

### "Tracking issue for RFC 1868: A portability lint" rust#41619

- **Link:** https://github.com/rust-lang/rust/issues/41619
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/41619#issuecomment-1548112936):
> Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @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/issues/41619#issuecomment-1548112912):
> It seems like the current consensus among @rust-lang/lang is that this isn't the approach we want to go after all, and we'd like something *type-based* rather than *lint-based*. For instance, something based on the various "capabilities" proposals for global impls of a `Trait`, together with `where` clauses.
>
> @rfcbot close

### "Tracking issue for RFC 2515, "Permit impl Trait in type aliases"" rust#63063

- **Link:** https://github.com/rust-lang/rust/issues/63063
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/63063#issuecomment-1360043090):
> Team member @nikomatsakis 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
> * [ ] @scottmcm
>
> Concerns:
>
> * ~~~~ resolved by https://github.com/rust-lang/rust/issues/63063#issuecomment-1361432898
> * docs (https://github.com/rust-lang/rust/issues/63063#issuecomment-1364525286)
> * function-defining-uses (https://github.com/rust-lang/rust/issues/63063#issuecomment-1385946789)
>
> 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/63063#issuecomment-1360043060):
> @rfcbot fcp merge
>
> This has been a long-time coming. Let's Do This!
>
> [Stabilization report in this comment.](https://github.com/rust-lang/rust/issues/63063#issuecomment-1354392317)

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

### "Add `internal_features` lint" rust#108955

- **Link:** https://github.com/rust-lang/rust/pull/108955
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/108955#issuecomment-1564739018):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @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/108955#issuecomment-1564739001):
> I was pondering whether this is more lang or more compiler, but with a compiler MCP already complete,
>
> @rfcbot fcp merge
>
> I support giving stronger discouragement from using `S-tracking-perma-unstable` things.
>

### "Uplift `clippy::option_env_unwrap` lint" rust#111738

- **Link:** https://github.com/rust-lang/rust/pull/111738
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/111738#issuecomment-1559994605):
> Team member @nikomatsakis has proposed to close this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * move-errors-left (https://github.com/rust-lang/rust/pull/111738#issuecomment-1564194388)
>
> 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/111738#issuecomment-1559994585):
> @rfcbot fcp close
>
> We discussed this in the lang-team meeting and felt it did not meet the rustc bar of preventing bugs or helping to shape ecosystem wide consistency (like naming conventions).
>
> We would be interested in some kind of "custom lint" mechanism. Ideally this would be a pattern-matching scheme that would ecosystem crates provide this sort of lint. A more limited thing might be something like #[must_use] (e.g., #[prefer_on_unwrap("env!")], but some members of the team were skeptical of such a narrow purpose attribute. Regardless that would be a separate proposal that would ultimately require an RFC.
>
> The motivation here is that we think "usage lints" like this add value, but to do so, you need an awful lot of them, and we think the best way to get that is to let people add them themselves. Otherwise, clippy is a better home.

## Active FCPs
### "TAIT defining scope options" rust#107645

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

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

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "Explicit Tail Calls" rfcs#3407

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

### "dyn Trait comparison should not include the vtable pointer" rust#106447

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

### "Add `internal_features` lint" rust#108955

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

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

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

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

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

### "Uplift `clippy::option_env_unwrap` lint" rust#111738

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

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

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

### "resolve: Remove artificial import ambiguity errors" rust#112086

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