---
# System prepended metadata

title: Triage meeting 2023-04-18
tags: [triage-meeting]

---

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

# T-lang meeting agenda

* Meeting date: 2023-04-18

## Attendance

* Team members: tmandry
* Others: Connor Horman, 

## Meeting roles

* Action item scribe:
* Note-taker:

## Scheduled meetings
- "The #[diagnostic] attribute namespace" [lang-team#204](https://github.com/rust-lang/lang-team/issues/204) 

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

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



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

Pinged petrochenkov

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

cramertj to ping Mara about this

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

- **Link:** https://github.com/rust-lang/rfcs/pull/3368
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1505729113): 
	> Team member @tmandry 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
	> * [x] @estebank
	> * [ ] @joshtriplett
	> * [ ] @lcnr
	> * [x] @matthewjasper
	> * [ ] @michaelwoerister
	> * [ ] @nagisa
	> * [ ] @nikomatsakis
	> * [x] @oli-obk
	> * [ ] @petrochenkov
	> * [ ] @pnkfelix
	> * [ ] @scottmcm
	> * [x] @tmandry
	> * [ ] @wesleywiser
	> 
	> Concerns:
	> 
	> * lang-team-signoff (https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1505729088)
	> * ~~translation~~ resolved by https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1511696325
	> * version-namespace (https://github.com/rust-lang/rfcs/pull/3368#issuecomment-1505729088)
	> 
	> 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/3368#issuecomment-1505729088): 
	> @rfcbot merge
	> 
	> I think we should merge this RFC, modulo some concerns I note below.
	> 
	> It would be good to merge it soon so we can get the `#[diagnostic]` namespace parsed by rustc, so any crate using it in the future won't have to bump its MSRV past the first rustc version that knows about `#[diagnostic]` (even if it doesn't support any attributes yet â€“Â unknown attributes are allowed to be no-ops in the RFC).
	> 
	> ## Concerns
	> 
	> @rfcbot concern version-namespace
	> 
	> I personally think we should not include the version namespace in the current proposal but include it as a future possibility. @oli-obk pointed out to me that we can always decide to include a version namespace later, and choose to require it in a new edition if we decide that it was a mistake to let you use a diagnostic attribute _without_ a version. However, I think we should choose the more ergonomic option for now.
	> 
	> This doesn't necessarily represent the whole lang team's opinion (sorry for churn around that), but I'll try to push on getting consensus here.
	> 
	> @rfcbot concern lang-team-signoff
	> 
	> Several members of the lang team don't necessarily want to bypass the lang team for the stabilization process, though I'm sympathetic to the argument that there could be too much high-frequency churn and don't want the lang team to get in the way of progress. I propose modifying the RFC to say that the lang team can choose to adopt an expedited process for stabilization of new attributes and fields with an FCP (this would not require a new RFC).
	> 
	> ## Additional feedback
	> 
	> I think it would be ideal to strengthen the wording around warning on unrecognized lints or fields. I think these should _always_ be a warn-by-default lint.
	> 
	> We may want to make it possible for a diagnostic attribute to affect or create new warn-by-default lints, which by my read is not allowed in the current RFC ("Any attribute in this namespace may... only affect the messages emitted by a compiler in case of a failed compilation.")
	> 
	> Personally I think it's reasonable to allow affecting existing warnings in the current RFC, and leave the creation of new ones as a future possibility. Or if either of these were considered and rejected, the RFC should say why.

Lang team members need to review

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

Blocked on impl to remove check-only errors

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

cramertj: We need someone to take a stance on how to solve this and argue for it compared to other options, that would be in RFC format

scottmcm: Some of it is missing details, e.g. what does "constraining use" mean, versus new RFC

tmandry: Any substantial design question with multiple alternatives being considered should be included

cramertj to leave comment


scottmcm: @1n2nRkvSTd-QgK8cCPds1w Here's what I started typing, if it's useful:

> I think we ended up here because of this concern <https://github.com/rust-lang/rust/issues/63063#issuecomment-1385946789>.  Looking at <https://github.com/rust-lang/rfcs/blob/master/text/2071-impl-trait-existential-types.md#alternatives> again, it talks a bunch about _syntax_ alternatives but not about why it should be defined "implicitly".  In a quick skim, I didn't notice it talking about the R-A concern, for example, of wanting to be able to not look at bodies to find a defining use.  Or from the perspective of someone trying to figure out what the actual concrete type is, there's no obvious way to find that today.

cramertj: ..actually why does RA need this?

Gary Guo: In https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=a7445611369de2767e5d5383a5364ba2, `Foo` is defined by `define_foo` but used by `use_foo`.

cramertj: `let () =` is also the defining use of `Foo` in `use_foo` function.

cramertj: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6f28029026b89e9b26acfdf572609d8e shows an unconstrained use of `Foo` in `use_foo` function.


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

left a ping

### "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:
	> 
	> * [x] @Aaron1011
	> * [x] @cjgillot
	> * [x] @davidtwco
	> * [x] @eddyb
	> * [ ] @estebank
	> * [ ] @joshtriplett
	> * [x] @lcnr
	> * [x] @matthewjasper
	> * [x] @michaelwoerister
	> * [ ] @nagisa
	> * [x] @nikomatsakis
	> * [x] @oli-obk
	> * [x] @petrochenkov
	> * [ ] @pnkfelix
	> * [x] @scottmcm
	> * [x] @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
### "Tracking Issue for `debugger_visualizer`" rust#95939

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



## P-critical issues

None.




## Nominated RFCs, PRs and issues discussed this meeting

### "unsafe attributes" rfcs#3325

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

unnominated, already discussed

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

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

tmandry opened an FCP for lang team

### "dyn Trait comparison should not include the vtable pointer" rust#106447
**Link:** https://github.com/rust-lang/rust/issues/106447

garyguo: Discussed this last year around `Arc::ptq_eq`, didn't reach a conclusion.

https://hackmd.io/@rust-lang-team/SyDavQuri#%E2%80%9CArcptr_eq-does-not-always-return-%E2%80%9Ctrue-if-the-two-Arcs-point-to-the-same-allocation%E2%80%9D-as-documented%E2%80%9D-rust103763

tmandry: Looks like libs did an FCP for `Arc::ptr_eq` to ignore metadata, approved

scottmcm: Arc never allocates a ZST. Are there cases where we want to distinguish between ZSTs based on metadata?

```rust=
#[derive(Debug)]
#[repr(transparent)]
struct Foo(u8);

let f = Foo(1);
let p1: *const dyn Debug = &f;
let p2: *const dyn Debug = &f.0;

assert_ne!(p1, p2); // always passes today
```

garyguo:
```rust
trait Slice {
    fn len(&self) -> usize;
}

impl<T, const N: usize> Slice for [T; N] {
    fn len(&self) -> usize {
        N
    }
}

// Say a is from &[u8; 1] and b is from &[u8; 2]

fn eq_1(a: *const dyn Slice, b: *const dyn Slice) {
    // should a == b?
}

fn eq_2(a: *const [u8], b: *const [u8]) {
    // a != b
}
```

garyguo: we can prevent merging of vtables by telling LLVM the address is significant. We can prevent duplication for static linking (linkonce), but we can't prevent duplication when dynamic linking is used.

<some discussion about putting TypeId into all vtables and C++ RTTI>

tmandry: Can we signal that we're open to breaking

scottmcm: What lets us break it?

garyguo: We couldn't tell all raw dyn trait ptr comparisions due to `T: ?Sized` but we could try to generate a lint for all places known to be doing raw dyn trait ptr?

scottmcm: hmm, even <https://doc.rust-lang.org/std/ptr/fn.eq.html> takes `T: ?Sized`

leaving nominated for now, aren't sure how to proceed yet.

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


### "regression: unaligned references to packed fields are now an error" rust#109745

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

scottmcm: Unnominated --- tmandry commented on it last week and nothing has happened since.
