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

# T-lang meeting agenda

* Meeting date: 2023-04-04

## Attendance

* Team members: nikomatsakis, pnkfelix, tmandry
* Others: dtolnay

## Meeting roles

* Action item scribe:
* Note-taker:

## Scheduled meetings

* Planning meeting tomorrow!

## Announcements or custom items

None!

## 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
### "RFC: result_ffi_guarantees" rfcs#3391

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

lokathor: does compiler already do this?

nikomatsakis: Pretty sure it does.

cramertj: is this insta-stable?

nikomatsakis: I think so, or else we can fcp merge the PR to the reference.

MAKE JOSH DO IT

from jitsi comments:

> David says: Whoever was asking whether the "Result FFI guarantees" RFC is insta-stable when accepted or does it need compiler implementation work: I think it needs compiler implementation work. In particular I don't think it's ever been determined whether `Option<NonZeroU8>` has the same ABI as C's `uint8_t` vs as C's `struct { uint8_t; }`. In particular this RFC is making new guarantees of the form "same ABI", not just "same layout", which is not a thing that has been done before outside of the context of repr(transparent).

David to author a comment on RFC.

## Proposed FCPs

**Check your boxes!**
### "unsafe attributes" rfcs#3325

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

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

### "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
> * [x] @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/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 `debugger_visualizer`" rust#95939

- **Link:** https://github.com/rust-lang/rust/issues/95939
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/95939#issuecomment-1496371829):
> Team member @wesleywiser has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Aaron1011
> * [ ] @cjgillot
> * [ ] @davidtwco
> * [x] @eddyb
> * [ ] @estebank
> * [ ] @joshtriplett
> * [ ] @lcnr
> * [ ] @matthewjasper
> * [ ] @michaelwoerister
> * [ ] @nagisa
> * [ ] @nikomatsakis
> * [ ] @oli-obk
> * [ ] @petrochenkov
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
> * [x] @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/95939#issuecomment-1496371801):
> I think this is ready for stabilization.
>
> @gibbyfree wrote a [stabilization report](https://github.com/rust-lang/rust/issues/95939#issuecomment-1456938444) and the associated PR is #108668.
>
> @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-1468728438):
> Team member @nikomatsakis 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:
>
> * explicit-alternative (https://github.com/rust-lang/rust/issues/107645#issuecomment-1469979788)
> * why-not-just-the-return-type (https://github.com/rust-lang/rust/issues/107645#issuecomment-1468796621)
>
> 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-1468728409):
> @rfcbot fcp merge
>
> I propose that we accept https://github.com/rust-lang/rust/pull/107809. It implements a conservative path forward. Basically any function that constraints a TAIT but doesn't list the TAIT in its arguments/return type is a hard error, giving us room to change the behavior in the future.
>
> ### Final behavior as I understand it
>
> * A TAIT has a *defining scope* that corresponds to the enclosing module or item.
> * A *defining use* for a TAIT is any item that (a) is within the defining scope and (b) contains a function that lists the TAIT in the argument or return types, either before or after normalization (*see edge case below).
> * Within the defining scope, an item is called *constraining* if it puts constraints on the value of the TAIT. i.e., for the item to type check, the hidden type of the TAIT must have a particular value. This could occur because of a `let` (e.g., `let x: TAIT = 22_u32`), a return (e.g., `return 22_u32` in a function whose return type is `TAIT`), or in other ways.
> * Any *constraining* item within the defining scope that is not a *defining use* is a hard error. This means we can later opt to allow such a use; or to allow it with an annotation of some kind; or to make other such changes.
> * All *defining uses* must fully infer the hidden type of the TAIT and must infer the same type for the TAIT.
> * WIthin the defining scope, TAITs must always be given generic arguments (e.g., `fn foo<T>() -> TAIT<T>` and not `fn foo() -> TAIT<u32>`). This ensures inference is tractable and well-defined.
>
> ### Current bugs and limitations (forwards compatible to change)
>
> * Within the defining scope, attempts to check whether `TAIT` implements an auto-trait will yield a cycle error unless the auto-trait is listed in the TAIT's bounds. This is suboptimal, but the ideal fix is unclear.
> * A function that has an argument which is an associated type referencing a TAIT (e.g. `<TAIT as SomeTrait>::SomeItem`) ought to be considered a *defining use*. However, in the compiler today, if that associated type can be normalized, and the normalized form does not reference the TAIT, the function is not. This can only cause more errors.
>
> @rustbot labels -I-lang-nominated

### "Make late_bound_lifetime_arguments a hard error." rust#108782

- **Link:** https://github.com/rust-lang/rust/pull/108782
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/108782#issuecomment-1468627626):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * types-team-input (https://github.com/rust-lang/rust/pull/108782#issuecomment-1477170467)
>
> 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/108782#issuecomment-1468627594):
> @rfcbot fcp merge
>
> Discussed in a (minimally attended) lang-team triage meeting and we are in favor of moving forward with this.
>

### "Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool" rust#109677

- **Link:** https://github.com/rust-lang/rust/pull/109677
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/109677#issuecomment-1491574659):
> Team member @michaelwoerister has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Aaron1011
> * [x] @cjgillot
> * [x] @davidtwco
> * [x] @eddyb
> * [ ] @estebank
> * [ ] @joshtriplett
> * [x] @lcnr
> * [x] @matthewjasper
> * [x] @michaelwoerister
> * [ ] @nagisa
> * [ ] @nikomatsakis
> * [x] @oli-obk
> * [x] @petrochenkov
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
> * [x] @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/pull/109677#issuecomment-1491574605):
> Thanks, @dpaoliello! Let's start the FCP then. This includes the lang team for final sign off on the `import_name_type` field of the `#[link]` attribute. In https://github.com/rust-lang/rust/pull/100732#issuecomment-1225873457, @joshtriplett gave a general OK for the new key, but let's make it part of an FCP.
>
> @dpaoliello's extensive stabilization report is in the tracking issue at https://github.com/rust-lang/rust/issues/58713#issuecomment-1485826095.
>
> @rfcbot fcp merge
>

## Active FCPs

None.

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Tracking Issue for Non-lifetime Binders" rust#108185

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

`for<T> i32: SomeTrait<T>`

* this is just a heads up that work is ongoing, still needs an RFC

### "Uplift `clippy::{drop,forget}_{ref,copy}` lints" rust#109732

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

### "Tracking Issue for `#[track_caller]` on closures" rust#87417

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

Question: are we ok with stabilizing "track caller" on async function?

Currently it gets put on the poll function, not on the actual function.

Probably the original caller is better, as track-caller usually means caller was responsible for some variant, but we don't want to store the data.

nikomatsakis: the spawn is the worst case, most combinators (e.g., join) will introduce annoying frames but your caller is still likely there

cramertj: but futures unordered is also not great.

cramertj: how would it work via dynamic dispatch..? since it is isn't on the `Future` trait, it likely wouldn't work there.

nikomatsakis: how big are these arguments anyway, maybe we do want to store it in there...

tmandry: ...3 pointers

cramertj: I think it's a static pointer to that information

nikomatsakis: I'm persuaded, it probably wants a write-up and an FCP, RFC feels overkill

tmandry: let's make it a separate feature flag and then we can FCP plans there

*tmandry to author comment*

### " Make typeck aware of uninhabited types" rust#108993

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

Types team has ongoing FCP, seems like it's more in their domain, not a major change to how Rust feels.

### "Add ability to transmute (somewhat) with generic consts in arrays" rust#106281

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

tmandry: why do we have these rules when transmute is unsafe?

cramertj: historically doesn't let you transmute between things of different size

pnkfelix: example at the end...

fn transpose_with_const<const W: usize, const H: usize>(
  v: [[u32; 2 * H]; W + W]
) -> [[u32; W + W]; 2 * H] 

...can you always do this?

cramertj: it's still unsafe...?

pnkfelix: I think because of padding this isn't always safe to do for arbitary `T`

cramertj: the problem is that the transmute (today) will fail

pnkfelix: for `T != u32`, can't you have rows and columns where swapping them will change the size of the 2d array?

cramertj: I think it fails at monomorphization time

tmandry: We accept this today

use core::mem::transmute;
fn foo() {
    let x: *const [u8; 32] = &[0; 32];
    let y: *const [u8; 16] = unsafe { transmute(x) };
}

what about `Arc<...>`

nikomatsakis: seems like we have some questions, but do we like this overall direction?

cramertj: maybe we want a transmute that checks at monomorphization time, rather than algebraic simplificaiton? seems questionable given that we have mono-time errors with const fn. This approach will allow more errors, resulting in better error messages.

pnkfelix: background is that we've always been striving to make transmute cases pre-mono, whole point was to restrict it so much that you're always sure boths ides have same size. Are you saying we give up on that?

cramertj: I'm saying there could be another fn for transmuting between types that are not known to be the same size which fails at mono-time, would allow for you to write more const generic code, since we've already opened the door. I think this makes transmute cleverer, in contrast.

nikomatsakis: why have 2 transmutes, maybe move that later in compilation cycle?

pnkfelix: currently there's a guarantee that your code will work with all instantiations?

nikomatsakis: correct. we could have a lint that says "I can't guarantee these are the same".

cramertj: I would be happier if this were a lint than making it more complex when transmute compiles.

nikomatsakis: I would feel fine putting an allow for cases like "I know that this function will only be invoked with a T and a U".

tmandry: precise proposal is... make a lint but a hard error at mono time?

cramertj: yes, this seems like it wants an RFC, and T-libs involvement

pnkfelix: add a lint for transmute-copy

cramertj: people learned from clippy to pointer-cast... which has no checks...

nikomatsakis: ...that's what I do.

lokathor: transmute is a const fn, transmute-copy won't be for a while.

nikomatsakis: transmute also moves the value which is usually what I want.

cramertj: and having to go through an extra pointer in heavily optimized code is no bueno.

lokathor: you wrap the value you're getting rid of in manually drop .. etc etc ...

nikomatsakis: it's just a lot of hassle

cramertj: I feel we should discourage transmute less, people wind up doing more convoluted things instead :hot_pepper:

lokathor: safe transmute ftw!

Consensus:

* This analysis is cool but we'd be more comfortable with it as a lint.
* We would prefer to loosen transmute and have a lint (using this sort of logic) that decides when to warn.
* Strong reservations on team about having the ability for transmute to compile being gated on this.

tmandry: we may need algebraic equivalence elsewhere in the language

nikomatsakis: agreed but this PR isn't making a strong enough case in terms of motivation

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "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