---
title: Triage meeting 2022-05-17
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-05-17

## Attendance

* Team members: Josh, Felix, Taylor
* Others: Mark, Mara, Urgau, compiler-errors

## Meeting roles

* Action item scribe: Mark
* Note-taker: Felix

## Scheduled meetings
- "Structural equality" [lang-team#94](https://github.com/rust-lang/lang-team/issues/94)
- "Never allow unwinding from Drop impls" [lang-team#97](https://github.com/rust-lang/lang-team/issues/97)
- "Dyn upcasting, safety considerations" [lang-team#119](https://github.com/rust-lang/lang-team/issues/119)
- "Const eval overview" [lang-team#131](https://github.com/rust-lang/lang-team/issues/131)
- "Return Position impl Trait in dyn Trait ("RPITIDT")" [lang-team#144](https://github.com/rust-lang/lang-team/issues/144)

## 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
### "Deprecate target_vendor " lang-team#102

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

### "Support platforms with size_t != uintptr_t" lang-team#125

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

### "Positional Associated Types" lang-team#126

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

### "Interoperability With C++ Destruction Order" lang-team#135

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

### "inner crates, aka multiple crates per file" lang-team#139

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

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

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

### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147

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

### "Async fns in traits" lang-team#150

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

### "dyn* trait" lang-team#158

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

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

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

### "Initiative: Ghost types and blocks" lang-team#161

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

### "Keyword generics" lang-team#162

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

### "Add const evaluatable `where const { <block> }`" lang-team#163

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

Josh: Any updates here, since there was discussion last week? No? Okay, moving on.

## PRs on the lang-team repo

None.

## RFCs waiting to be merged
### "Allow using `for<'a>` syntax when declaring closures" rfcs#3216

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

## Proposed FCPs

**Check your boxes!**
### "Refined trait implementations" rfcs#3245

- **Link:** https://github.com/rust-lang/rfcs/pull/3245
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3245#issuecomment-1116370994):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * unresolved-question-for-next-edition (https://github.com/rust-lang/rfcs/pull/3245#issuecomment-1116371336)
>
> 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!
>
> 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/3245#issuecomment-1116370985):
> @rfcbot fcp merge
>
> I think we've got consensus on most of this here -- the main question is whether, in the next edition, `#[refine]` ought to be required in order to see the effects of the change or optional (perhaps with a lint). I'm going to separate propose a concern to move this to an unresolved question, I dont' see why it should block this RFC from going forward now.

### "tracking issue for `infer_static_outlives_requirements` (RFC 2093 spinoff)" rust#54185

- **Link:** https://github.com/rust-lang/rust/issues/54185
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/54185#issuecomment-1124097917):
> Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
>
> 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!
>
> 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/54185#issuecomment-1124097663):
> It's been 3.5 years, and it doesn't seem like we've had any further reports about this being confusing. We can always make this change later, if we change our minds or new information comes to light.
>
> Any concerns from @rust-lang/lang about closing this?
>
> @rfcbot close

### "Tracking Issue for RFC 3128: I/O Safety" rust#87074

- **Link:** https://github.com/rust-lang/rust/issues/87074
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/87074#issuecomment-1075152025):
> Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Amanieu
> * [ ] @BurntSushi
> * [ ] @dtolnay
> * [x] @joshtriplett
> * [x] @m-ou-se
> * [ ] @yaahc
>
> Concerns:
>
> * OwnedHandle's TryFrom impls (https://github.com/rust-lang/rust/issues/87074#issuecomment-1080031167)
>
> 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!
>
> 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/87074#issuecomment-1075151992):
> @rfcbot merge
>
> See https://github.com/rust-lang/rust/issues/87074#issuecomment-1073069181

Josh: this is being raised to T-lang because it uses the `#[rustc_nonnull_optimization_guaranteed]` attribute. Is this a concern, the exposure of this use of that attribute in a public API

(some debate/discussion followed on whether stdlib File or other types are already using that attribute.)

Josh/Scott: We do already expose a guarantee here for applying the niche-optimization for a unused zero-value; the new thing with this stabilization is the use of the guarantee on a *non-zero* value.

Mark: I have a bikeshed objection to the use of the name "nonnull" for this.
Josh: I agree, and that is an argument for renaming if/when we were to stabilize it. But its not an argument against *using* it in a stable API.
Felix: Just to confirm: this attribute name is not exposed in any way? E.g. its not in the docs?
Mara: its not in the docs.

Scott: If its just an optimization and people should not be relying on it, then we should take this attribute *off*. The whole point here is that by putting in this attribute, we are *guaranteeing* this optimization for our users.

Josh: Does this need an FCP?
Scott: Its a breaking change to revert it; that means it needs an FCP.
Josh: Okay. How do we handle that T-lang specific FCP, due to the ongoing FCP that T-libs-api is doing?
(some discussion of options here, e.g. revert that part of the change and then have separate PR re-adding it)
consensus: We will file a separate issue specifically about this and apply a T-lang FCP on that new issue.

Josh to file an issue here.

### "Stabilize `let else`" rust#93628

- **Link:** https://github.com/rust-lang/rust/pull/93628
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383585):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * need-consistency-rvalue-temporary-rules-between-let-and-let-else (https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523)
> * ~~not-while-rustfmt-breaks-on-it~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1032936704
> * ~~semicolon~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1059799661
> * ~~stabilization-report~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1033846359
> * ~~summarize-concerns~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1056785904
>
> 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!
>
> 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/93628#issuecomment-1029383577):
> Shall we stabilize `let else` syntax? We've had many demonstrated uses, including extensively throughout `rust-lang/rust`, we've seen the value of it, and there aren't any known issues with it.
>
> @rfcbot merge

Josh: There's someone working on this.
Felix: Yes we agreed on adding explicit support for `let else` to HIR, rather than continuing to fail at finding a desugaring-based solution.

### "[Experiment] Remove migrate borrowck mode" rust#95565

- **Link:** https://github.com/rust-lang/rust/pull/95565
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/95565#issuecomment-1110084133):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * confirm-no-other-regressions (https://github.com/rust-lang/rust/pull/95565#issuecomment-1110084111)
> * investigate-96331 (https://github.com/rust-lang/rust/pull/95565#issuecomment-1122677059)
> * ~~wait-for-96268~~ resolved by https://github.com/rust-lang/rust/pull/95565#issuecomment-1122674554
>
> 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!
>
> 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/95565#issuecomment-1110084111):
> @rfcbot merge
>
> @rfcbot concern wait-for-96268
> @rfcbot concern confirm-no-other-regressions

Josh: We wanted to double-check interpretation of the crater run
Mara: in all cases that are breaking, we already warn
Josh: Were all the warnings about the mutable borrow reservation confict?
Mara: It was only that.
Josh: Okay, that was the concern, about whether there was a *different* warning that we might be concerned about.

Mara: Which is up-to-date current thread for tracking NLL?
Josh: This one, I think
Mara: It would be nice for NLL to be stable this cycle; scoped-threads are blocked on it.
Josh: I believe [#96331](https://github.com/rust-lang/rust/issues/96331) is the main current blocking concern: knowing whether that issue represents expected behavior or not.

### "Modify MIR building to drop repeat expressions with length zero" rust#95953

- **Link:** https://github.com/rust-lang/rust/pull/95953
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/95953#issuecomment-1116384402):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * uncertain-intended-behaviour (https://github.com/rust-lang/rust/pull/95953#issuecomment-1128323128)
>
> 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!
>
> 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/95953#issuecomment-1116384385):
> @rfcbot fcp merge
>
> We discussed in the @rust-lang/lang meeting today. Everybody felt this was a clear bug fix, so moving to merge.

scott: an array of zero length with a value from a const-expr, today we do not drop that value, while this PR will change that.
scott: (oli says) T-lang previously specified [CONST; 0] as equivalent to [].
> in https://github.com/rust-lang/rust/pull/79270#issuecomment-740877885

let _x = [SOME_CONST; 0];
// vs
let temp = SOME_CONST;
let _x = [temp; 0];

scott: if the special case was `[const { ... stuff ... }; 0]` that might make the special-case less scary, because the introduction of the local is more obviously a change. And that's something we could do in an edition.

scott: it seems that based on T-lang's [prior approval](https://github.com/rust-lang/rust/pull/79270#issuecomment-740877885) of `[CONST; 0]` not instantiating the const, then there's no specification question to be resolved here. Its just an implementation concern of how to get the right semantics for the const vs non-const cases.

Scott will remove their concern.

### "Remove label/lifetime shadowing warnings" rust#96296

- **Link:** https://github.com/rust-lang/rust/pull/96296
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/96296#issuecomment-1114024288):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * doc-pr (https://github.com/rust-lang/rust/pull/96296#issuecomment-1116366940)
>
> 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!
>
> 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/96296#issuecomment-1114024287):
> T-lang, do we have consensus to make label scopes limited to their block, and eliminate spurious shadowing warnings?
>
> @rfcbot merge

Josh: Any objections to a merge now? No? Okay.

## Active FCPs
### "Create a types team" rfcs#3254

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

### "(Modules) Tracking issue for `crate` as a visibility modifier" rust#53120

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

### "Tracking issue for `explicit_generic_args_with_impl_trait`" rust#83701

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

### "Neither require nor imply lifetime bounds on opaque type for well formedness" rust#95474

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

### "[EXPERIMENT] disable orphan check for marker traits" rust#96766

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

### "Deprecate target_vendor " lang-team#102

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

### "Positional Associated Types" lang-team#126

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

### "Interoperability With C++ Destruction Order" lang-team#135

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

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

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

### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147

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

### "Async fns in traits" lang-team#150

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

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

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

### "Initiative: Ghost types and blocks" lang-team#161

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

### "Keyword generics" lang-team#162

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

## P-critical issues
### "nested RPIT and HRTB: unclear semantics and future incompatibility" rust#96194

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

fn f() -> impl for<'a> Tr<'a, Assoc = impl Copy> {}
                                      ~~~~~~~~~ RPIT
               ~~~~~~~ HKT
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RPIT

https://github.com/rust-lang/rust/pull/97039 (and backport https://github.com/rust-lang/rust/pull/97040) makes this an error so we have breathing room to decide what we want to do about it.

## Nominated RFCs, PRs and issues discussed this meeting

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

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "non-lexical lifetimes (NLL) tracking issue" rust#43234

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

### "Covariance-related GAT lifetime mismatch" rust#89352

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

### "Stabilize `let_chains` in Rust 1.62.0" rust#94927

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

### "Neither require nor imply lifetime bounds on opaque type for well formedness" rust#95474

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

### "Warn about dead tuple struct fields" rust#95977

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

### "nested RPIT and HRTB: unclear semantics and future incompatibility" rust#96194

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

### "Should `repr(transparent)` require *inhabited* 1-ZSTs?" rust#96921

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

### "Upper bound on hashes in raw string literals" reference#1180

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

### "Document the effect of main's return value?" reference#1196

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