---
title: Triage meeting 2023-03-07
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-03-07

## Attendance

* Team members:
* Others: dtolnay

## Meeting roles

* Action item scribe:
* Note-taker: scottmcm

## Scheduled meetings
- "Language design principles" [lang-team#189](https://github.com/rust-lang/lang-team/issues/189)
- "Design decisions around the `#[expect]` attribute" [lang-team#191](https://github.com/rust-lang/lang-team/issues/191)
- "discuss/resolve `fn { mod { (use) super::...; } }` and its interaction with derive patterns" [lang-team#193](https://github.com/rust-lang/lang-team/issues/193)
- "Design Meeting: Field Projection" [lang-team#194](https://github.com/rust-lang/lang-team/issues/194)
- "Interface between opsem and lang team" [lang-team#196](https://github.com/rust-lang/lang-team/issues/196)
- "Temporary lifetimes" [lang-team#197](https://github.com/rust-lang/lang-team/issues/197)

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

## Action item review

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

## Pending lang team project proposals

None.

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "Edition Based Method Disambiguation: Preventing inference ambiguity breakages with extension trait methods" rfcs#3240

- **Link:** https://github.com/rust-lang/rfcs/pull/3240
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3240#issuecomment-1377748067):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Amanieu
> * [ ] @BurntSushi
> * [ ] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @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/rfcs/pull/3240#issuecomment-1377748031):
> @rfcbot merge

### "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:
>
> * maybe-make-this-part-of-next-edition (https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1438988272)
>
> 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

josh: Looks like there's a blocker.

tmandry: something from petrochenkov: <https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1452420832>. Let's talk about it.

josh: I wouldn't object to that new one. Only difference would be comma-separating attributes, if we added support for that. Inclined to make the change anyway.

felix: Should one of us raise a concern?

josh: I will.

felix: Will resolve concern once josh's is in.

josh: it's in. Agrees with Ralf's point that nesting like cfg_attr doesn't seem unreasonable. Could maybe do something space-like for `cfg_attr` too?

#[cfg_attr(cfg = "foo") test]

Lokathor: `unsafe` is a keyword, rather than a path. Other attributes are all paths.

Tyler: practical implication that this will break existing parsers?

scott: will this break r-a's parser?

josh: this isn't substantially different from other rust syntax additions.

tyler: not sure we *should* change. what exactly is the concern with the parens? Will post a question about elaborating it.

felix: can they be unresolved questions instead of needing to be dealt with now?

scott: is delaying the question useful?

josh: syntax isn't a blocker, so pick something we prefer and let it potentially change later if needed. Unresolved question for "will this make parsers excessively unhappy?"

David: parsers will expose the path, so naïvely the parser would return the path `unsafe`, whereas with the no-paren version the path would be `no_mangle`, with a method to say when it's `unsafe`. So there's an important piece here of what's "primary" -- if `unsafe` being the top-level thing is how it should be thought about.

Lokathor: assume you're put `unsafe` inside the `cfg_attr`.

Mark: if `unsafe` if magic or just a normal path, it affects the interpretation down the tree.

Josh: It could be outside or inside and that might be ok

Tyler: How much value is there in nesting under the unsafe?

Josh: we could write the following
`#[unsafe { no_mangle }]`

Scott: this discharges the obligation, which is nice.

Josh: In every case except `unsafe impl`, it's braces to discharge the obligation, and `unsafe ` (space) to create the obligation.

Tyler: is it like `async Trait`?

Scott: Those braces look awful to me.

Josh:
`#unsafe[no_mangle]`

Lokathor: the above would break all normal `macro_rules!` that grab meta as part of their input

Scott: Could we ever have another modifier like this?
Josh: Maybe, though I don't know what it would be.

Scott: ~~if we did `#[unsafe foo]` we have to update the matcher,~~ was confused forgot it was `#[$meta]`.

Tyler: two favoures are `unsafe attr` (with no nesting) and `unsafe { attr }`.

Josh: happy to drop `#unsafe[attr]`. I would block `unsafe attr` (looks too much like introducing an obligation rather than discharging one).

Scott: You can imagine `where T: const Add`. So in a way the `unsafe attr` is like that.

Tyler: it's effectively part of the name, just without an underscore.

Josh: We should take this async. Any other possibilities to suggest?

Scott: Let's make sure Ralf knows not to do a bunch of work here since we're not in consensus.

Josh: changed the concern. Let's go to github/zulip for the bikeshed.

Scott: concern on `unsafe {}` is not blocking, but would like something better.

### "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
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
>
> 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: result_ffi_guarantees" rfcs#3391

- **Link:** https://github.com/rust-lang/rfcs/pull/3391
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3391#issuecomment-1448763059):
> 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
>
> Concerns:
>
> * needs-to-mention-non_exhaustive (https://github.com/rust-lang/rfcs/pull/3391#issuecomment-1448776897)
>
> 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/3391#issuecomment-1448763007):
> @rfcbot merge

### "Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc)" rust#51540

- **Link:** https://github.com/rust-lang/rust/issues/51540
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/51540#issuecomment-1448404177):
> Team member @Amanieu has proposed to close this. The next step is review by the rest of the tagged team members:
>
> * [x] @Amanieu
> * [x] @BurntSushi
> * [x] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/51540#issuecomment-1448404145):
> After working on the OOM handler for a while, I think that the best way to move forward is to just treat OOM as a normal panic (so that it calls the normal panic handler/hooks). This is what already happens on `#![no_std]` since https://github.com/rust-lang/rust/pull/102318 was merged.
>
> I believe that we should do the same for the `std` case. Specifically:
> - The unstable `#[alloc_error_handler]` is removed. `alloc::alloc::handle_alloc_error` now always invokes the panic handler.
> - For backwards compatibility reasons, this is a [non-unwinding](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.can_unwind) panic. Unsafe code may not be written to correctly handling unwinding out of a memory allocation (this is in fact a frequent source of bugs in C++!). However this behavior can be overridden with `-Zoom=panic` which changes the behavior to a normal unwinding panic.
> - Since there is no separate handling for OOM any more, the unstable [OOM hook API](https://github.com/rust-lang/rust/issues/51245) in the standard library can also be removed.
>
> @rfcbot fcp 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)

### "Tracking Issue for "C-unwind ABI", RFC 2945" rust#74990

- **Link:** https://github.com/rust-lang/rust/issues/74990
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/74990#issuecomment-1363474839):
> 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
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * docs (https://github.com/rust-lang/rust/issues/74990#issuecomment-1364528477)
>
> 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/74990#issuecomment-1363474832):
> Shall we stabilize the `extern "C-unwind"` and other `-unwind` calling conventions? This change will leave `extern "C"` unchanged for now, but have the existing feature gate continue to opt into the new behavior on nightly. We'll do a separate change later to make `extern "C"` and similar not permit unwinding.
>
> @rfcbot merge

https://rust-lang.zulipchat.com/#narrow/stream/237824-t-lang.2Fdoc/topic/docs.20for.20unwind/near/338678624

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

Scott: Some conversation about where NLEs should really be ok. I posted a comment, which people seem relatively happy with, so hopefully it reflects lang consensus well enough.

Tyler: 5% regression for `check`ing unused stuff.

https://github.com/rust-lang/rust/pull/108730

Tyler: is this different from use-dependent?

Felix: this is that check builds weren't doing everything they should?

Tyler: lots of sticky questions.

Josh: that's the performance hit for 108730, which is checking all mir analyses. Is this the complete requirement? Could it be pruned more? Is there low-hanging fruit?

Tyler/Felix: let's ask oli for some clarification

### "Clarify stability guarantee for lifetimes in enum discriminants" rust#104299

- **Link:** https://github.com/rust-lang/rust/pull/104299
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/104299#issuecomment-1451325906):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @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/rust/pull/104299#issuecomment-1451325893):
> @rfcbot fcp merge
>
> This PR documents that the discriminants of enums that are generic over a lifetime do not change when only the concrete value of the lifetime changes.
>
> It does look related to the decision in https://github.com/rust-lang/rust/pull/101520, but that was about transmutes, and this is about the value of enum discriminants.
>
> I don't see how we could sensibly do anything different here, so I think we should go ahead and document this.

### "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
>
> 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/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 a builtin `FnPtr` trait that is implemented for all function pointers" rust#108080

- **Link:** https://github.com/rust-lang/rust/pull/108080
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/108080#issuecomment-1457830765):
> Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @Amanieu
> * [x] @compiler-errors
> * [ ] @cuviper
> * [ ] @jackh726
> * [ ] @joshtriplett
> * [ ] @lcnr
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [x] @oli-obk
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @spastorino
> * [ ] @the8472
> * [ ] @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/108080#issuecomment-1457830730):
> This PR adds a `FnPtr` trait that is implemented for *all* function pointers (even `unsafe` ones, `extern` ones, higher kinded ones or ones with more than 12 args). This allows us to implement various traits (like `PartialEq` or `Debug`) in terms of that `FnPtr` trait (it exposes a method for returning the address the pointer points to). This reduces the `((12 + 1) * 12 / 2 * 10 - 4) * 7` (`776 * 7`) macro generated impls we have right now to `7` blanket impls for `T` where `T: FnPtr`.
>
> Blanket impls have the issue that they'll report that a type does not implement `Debug` because it does not implement `FnPtr`, because rustc always assumes the blanket impl is the right one if there is no other one. It's obviously nonsense to report that e.g. `Mutex` does not implement `FnPtr`. So we added a quick reject in trait resolution to avoid considering these blanket impls unless the implements `FnPtr` (either by being a function pointer or by being a type parameter with a `FnPtr` bound).
>
> The `FnPtr` trait is *not* stable, but this PR insta-stabilizes all of
>
> * `PartialEq`
> * `Eq`
> * `PartialOrd`
> * `Ord`
> * `Hash`
> * `fmt::Pointer`
> * `Debug`
>
> for all function pointer types.
>
> An alternative design would be to add some magic syntax (e.g. a builtin macro) that expands directly to a `ty::FnPtr` internally which has all its possible variants be generic. That would avoid the blanket impl issues, but makes the type system more complex, while the scheme of this PR works with something we already do regularly: add built-in trait impls for types automatically within the trait solver.
>
>
> @rfcbot merge

## Active FCPs
### "RFC - sigil-option-notation" rfcs#2918

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

### "Properly allow macro expanded `format_args` invocations to uses captures" rust#106505

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

## P-critical issues
### "`#[target_feature]` is allowed on `main`" rust#108645

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

Downgraded to P-high because stabilization was reverted.

## Nominated RFCs, PRs and issues discussed this meeting

### "RFC: result_ffi_guarantees" rfcs#3391

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

Josh: can we unnominate since it needs checkboxes but there are no concerns left?

### "Partial stabilisation of `c_unwind`" rust#106075

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

Blocked on niko resolving their concern.

Mark: are the docs actually ready? I recall Eric asked for lang input on state.

### "Relax ordering rules for `asm!` operands" reference#1323

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

Josh: r+ on the docs change, and on the language change

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "RFC: Postfix match" rfcs#3295

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

### "unsafe attributes" rfcs#3325

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

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

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

### "`overflowing_literals` should have an option for "ignore signed overflows"" rust#99195

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

### "Introduce terminating scope for tail expressions of breakable scopes" rust#106493

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

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

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

### "Lint ambiguous glob re-exports" rust#107880

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

### "Clarify that free constants are always evaluated at compile time" reference#1328

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