---
title: Triage meeting 2023-05-16
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-05-16

## Attendance

* Team members: nikomatsakis
* Others:

## Meeting roles

* Action item scribe:
* Note-taker:

## Scheduled meetings

Uh oh, looks like our issues have the wrong labels.

- **Tomorrow:** RPITIT stabilization discussion
- **May 24:** Keyword generics -- repurpose to RTN or "send bound" problem?
- **May 31:** TAIT defining scope options

## Announcements or custom items

None! :zipper_mouth_face:

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

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

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

nikomatsakis: Looks like somebody needs to actually *do* this. Does anyone feel uncomfortable stabilizing this without gathering more data?

scottmcm: Given that we've already shipped it, and libs-api is ok with it, I think we are fine.

Two dangers:

* average crate size may go up
* worst case could be bad

But: LTO and other optimizations can help.

Tyler: want to understand what we are stabilizing and what the one-way doors are.

nikomatsakis: Seems like it needs a concise write-up.

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

nikomatsakis: I was thinking about unsafe crates. Interesting example from duchess, a library for JVM interop, where initializing the JVM can only be done once per process, but if you have multiple libraries trying to work atop the JVM, they can't coordinate.

lokathor: I asked ralf to add the future possibilities section.

nikomatsakis: so, in short, this is only one piece of the no-mangle story, but that's why we called it future possibilities, and so the only question that remains is the syntax one?

lokathor: yes, but if we do those future possilibities, it might not even need unsafe.

we can't figure out if there are any blocking concerns at this point.

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

### "Return position `impl Trait` in traits" rfcs#3425

- **Link:** https://github.com/rust-lang/rfcs/pull/3425
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3425#issuecomment-1531916403):
> 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
> * [ ] @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/3425#issuecomment-1531916376):
> @rfcbot fcp merge
>
> This feature has been a long time coming and feels like a no brainer to me. I'm going to start the merge proceedings.

### "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
> * [ ] @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

nikomatsakis: Blocked on...what?

scottmcm: Trying to be more consistent about not having opt-dependent failures.

lokathor: is that just impl quality?

scottmcm: concern is the stability, changes to optimizations could let less or more things compile, violating stability guarantees.

lokathor: I thought it was just about cargo check?

nikomatsakis: ie, cargo build is the "canonical source of errors", and cargo check is not

scottmcm: yes, I wouldn't block on that. I don't want to have to run crater because of changes to MIR optimization. I know we have that problem but I think we ended up as a team saying we wanted to resolved it better before stabilizing this.

lokathor: are you saying there would be opts that eliminate a const and thus allow a build? what would the opt be?

tmandry: opt-dependent, yes, but also errors that depend on your flags, if you pass "link dead code"

lokathor: zig has a thing where unused code won't report errors and it can be a pain

meeting consensus:

* we are not concerned about cargo check reporting fewer errors than cargo build
* but we do want cargo build to report consistent errors even in unused or dead code / not be dependent on optimizations

lokathor to author a comment

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

nikomatsakis: sync and async were different here, I wonder if we should care about that. Might be a Rust 2024 thing to think about.

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

## Active FCPs
### "The `#[diagnostic]` attribute namespace" rfcs#3368

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

### "expand: Change how `#![cfg(FALSE)]` behaves on crate root" rust#110141

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

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

### "Uplift `clippy::undropped_manually_drops` lint" rust#111530

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

Lint against:

struct S;
drop(std::mem::ManuallyDrop::new(S));

The idea being that this would be confusing, maybe you think this is "manually dropping".

Tyler to start an FCP.

### "Uplift `clippy::invalid_utf8_in_unchecked` lint" rust#111543

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

Deny by default:

unsafe {
    std::str::from_utf8_unchecked(b"cl\x82ippy");
}

Warn-by-default:

std::str::from_utf8(b"ru\x82st");

nikomatsakis: seems to meet our "no false warnings" threshold and I think deny by default feels right, similar to overflowing literals example.

scottmcm: my bar is "is it worth running your unit tests". If you run the one that panics, and you get a panic, then ok great. If you run your unit test, and it seems to pass, or it was UB, then -- i.e., are you plausibly going to get useful info from running the code.

### "Uplift `clippy::cast_ref_to_mut` lint" rust#111567

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

fn x(r: &i32) {
    unsafe {
        *(r as *const i32 as *mut i32) += 1;
    }
}

scottmcm: will this work if you use the "cast" method?

lokathor: I don't think the ptrcast method will work for `&`

*ptr::from_ref(r).cast_mut() += 1;

nikomatsakis + lokathor: we have a cast method?! [rustdoc](https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.cast_mut)

scottmcm: we're trying to migrate to them. Would be nice if the lint worked for the methods too, but doesn't need to block the link.

nikomatsakis: +1

urgau: you first need to coerce it with an `as` and then you can invoke `cast_mut`

scottmcm: coerce or `as` or use [`ptr::from_ref`](https://dev-doc.rust-lang.org/nightly/std/ptr/fn.from_ref.html) (nightly)

lokathor: it says for types with interior mutability but...

nikomatsakis: there's some debate here about how infectious the `UnsafeCell` should be

pnkfelix: current lint will stop firing if you use `UnsafeCell` for any part?

nikomatsakis: ralf has been saying he wants that, but I sort of want to hold space for us to change it.

tmandry: fcp merge'd!

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

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

removed nomination

### "Explicit Tail Calls" rfcs#3407

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

lokathor: a lot of discussion, not settled

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

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

est31 followed up on our request, let's FCP it

nikomatsakis: tmandry, fcp merge it!

### "Support RISC-V unaligned-scalar-mem target feature" rust#110884

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

meeting consensus: fine if it's gated.

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

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

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

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

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