---
title: Triage meeting 2023-02-28
tags: triage-meeting
---
# T-lang meeting agenda
* Meeting date: 2023-02-28
## Attendance
* Team members: nikomatsakis, Josh, tmandry, scottmcm
* Others: Mark, Lokathor, Gary Guo, y86, Bryan Garza
## Meeting roles
* Action item scribe:
* Note-taker: tmandry
## Scheduled meetings
* Tomorrow: **"Interface between opsem and lang team" [lang-team#196](https://github.com/rust-lang/lang-team/issues/196)**
Other scheduled meetings (see calendar):
- "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)
- "Design meeting: Non-local errors (aka post-monomorphization errors)" [lang-team#195](https://github.com/rust-lang/lang-team/issues/195)
- "Temporary lifetimes" [lang-team#197](https://github.com/rust-lang/lang-team/issues/197)
## Announcements or custom items
### Governance RFC and Council representative selection
Governance RFC is up: https://github.com/rust-lang/rfcs/pull/3392
Please let Josh know if you have any concerns or feedback or questions.
We need to start selecting a Council representative for lang+subteams. Need to make sure we include subteam feedback.
## Action item review
* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)
## Pending lang team project proposals
None.
## PRs on the lang-team repo
### "Updates to Frequently Requested Changes" lang-team#200
**Link:** https://github.com/rust-lang/lang-team/pull/200
## RFCs waiting to be merged
None.
## Proposed FCPs
**Check your boxes!**
### "RFC - sigil-option-notation" rfcs#2918
- **Link:** https://github.com/rust-lang/rfcs/pull/2918
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/2918#issuecomment-1444975102):
> 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/rfcs/pull/2918#issuecomment-1444975094):
> @rfcbot close
### "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
> * [ ] @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
### "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
> * [ ] @dtolnay
> * [ ] @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/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
### "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 (https://github.com/rust-lang/rust/pull/104087#issuecomment-1379582240)
> * post-monomorphization-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1409927203)
> * 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
scottmcm: These errors exist, making them hard to type isn't helping things
tmandry: Making it a thing encouraged by the language feels like a substantial change, but maybe not enough to block.
Gary: opt level affects errors. Oli has an open PR to change this.
scottmcm: That's breaking regardless of whether we stabilize inline_const.
Gary: If we can make that change, it should probably go first, just to reduce the potential breakage.
scottmcm: Do we consider it a bug that these errors don't appear at different opt levels? What lets us break that if we're willing to?
tmandry: Why opt-level-dependent?
joshtriplett: Because the compiler gets better at figuring out if code is dead at higher levels of optimization.
Gary: Optimizing out monomorphizations of functions.
scottmcm: Could we fix this without an edition change?
Gary: Look at crater impact of Oli's PR https://github.com/rust-lang/rust/pull/107510
nikomatsakis: Depending on whatever optimizations do seems bad to me.
Gary: I think there're two positions, one is to for the compiler to always eliminate a constant branch and another is not. Currently the compiler can do whatever it wants, so sometimes optimizer will change behavior.
scottmcm: obligatory mention of https://github.com/rust-lang/rust/pull/91222 (Don't monomorphize things that are unused due to if `<T as Trait>::CONST`)
scottmcm: Eventually we should let something like `if const` control monomorphization, but otherwise treat it as unknown.
nikomatsakis: Also don't love idea that we have to monomorphize functions that actually don't need it.
scottmcm: I don't want our language spec to have to spell out every kind of const propagation that's needed (C# does this).
### Consensus statement
* Want to block stabilizing inline_const behind fixing any compiler behavior that causes errors to depend on optimizations. (Need to listen for feedback from compiler folks, to find out if this is feasible.)
* Question of whether to monomorphize _all_ unused code (independent of optimizations) is something we might be comfortable deferring.
* Either way, we would like to see the results of a crater run for each of these changes.
tmandry to leave a comment.
nikomatsakis: Future caveat: Open to future changes where we exclude dependent crates from rules to monomorphize unneeded code, including optimization-dependent, so you only build code that you need. (Maybe there are better ways to achieve my goals, though.)
### "Properly allow macro expanded `format_args` invocations to uses captures" rust#106505
- **Link:** https://github.com/rust-lang/rust/pull/106505
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/106505#issuecomment-1402511990):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * ~~please-link-tests~~ resolved by https://github.com/rust-lang/rust/pull/106505#issuecomment-1416417520
>
> 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/106505#issuecomment-1402511930):
> We discussed this in the lang team meeting today. Broadly we thought that proc macros being able to emit tokens that use captures makes logical sense. Basically, a proc macro *emitting* something as a whole that one could write directly, as in https://github.com/rust-lang/rust/pull/106505/files#diff-868206cf54a88d81468a76d45e639cea40c537f2031d19f06c114e3cb329a426R44, seems entirely fine, though mixing things like `format!(concat!(…))` might still be best to reject.
>
> So I'll start a
>
> @rfcbot fcp merge
>
> but we had some requests to confirm, so...
### "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.
## Active FCPs
None.
## P-critical issues
None.
## Nominated RFCs, PRs and issues discussed this meeting
(none yet, move things from the section below as they are discussed)
### "RFC: result_ffi_guarantees" rfcs#3391
**Link:** https://github.com/rust-lang/rfcs/pull/3391
agreement that we generally want this, but we should add a caveat that structs tagged as non-exhaustive aren't guaranteed to be optimized
### "Partial stabilisation of `c_unwind`" rust#106075
**Link:** https://github.com/rust-lang/rust/pull/106075
blocked on need for docs updates
### "`overflowing_literals` should have an option for "ignore signed overflows" rust#99195
**Link:** https://github.com/rust-lang/rust/issues/99195
scottmcm: people are annoyed because people are used to writing signed literals in hex and specifying all the bits. Did we consider these cases when stabilizing?
nikomatsakis: my recollection from when we introduced this lint was that we didn't cover these kinds of cases, though it may have been discussed later.
scottmcm: yes, I think we talked about -1 at least.
### "TAIT defining scope options" rust#107645
**Link:** https://github.com/rust-lang/rust/issues/107645
nikomatsakis: from Zulip:
> I'd like to highlight option 5, which is basically:
>
> * Require that TAIT appears in the "signature" of an item for it to be a "defining item".
>* Report an error if a TAIT is constrained by a function or other item that is within the module but not a defining item.
Two patterns:
* Given a function whose return type names a TAIT and which is within (transitively) the TAIT's module, that function may constrain the TAIT
* Given an impl with an assoc type definition that names a TAIT, it may constrain it
yes accept:
```rust
type Foo = impl Debug;
fn foo() -> Foo { 22 }
```
no reject:
```rust
type Foo = impl Debug;
fn foo() {
let x: Foo = 22; // Error: constraints to be i32, but Foo does not appear in the return type
x
}
```
```rust
type Foo = impl Debug;
impl Iterator for Something {
type Item = Foo;
fn next(&mut self) -> Option<Self::Item> { Some(22) }
}
```
one question mark:
```rust
type Foo = impl Debug;
fn foo()
where
Foo: Display,
{
let x: Foo = 22; // Error: constraints to be i32, but Foo does not appear in the return type
x
}
```
this would work
```rust
type Foo = impl Debug;
fn foo(f: Foo)
where
Foo: Display,
{
println!("{f}");
}
```
tmandry: do functions within a module communicate the value, can they observe it?
nikomatsakis: no, that's never been allowed, defining items have to specify the full type, and they have to specify the full one. there is auto trait leakage outside the module. within, you currently get a cycle error, we should prob fix but backwards compatible.
tmandry: what about a case like this, should that be accepted?
```rust
type Foo = impl Debug;
impl SomeTrait for Something {
type Item = Foo;
fn next(&mut self) {
let x: Foo = 22;
}
}
```
nikomatsakis: I agree it seems a bit surprising. Probably some rule like "appears in the value of an associated type *and* the normalized value of a method" would suffice. Or we could analyze trait definition. My basic motivation is to tighten the screws as much as we reasonably can to get this out the door and support important patterns; easy to accept more patterns later.
## Nominated RFCs, PRs and issues NOT discussed this meeting
### "RFC: Start working on a Rust specification" rfcs#3355
**Link:** https://github.com/rust-lang/rfcs/pull/3355
### "Introduce terminating scope for tail expressions of breakable scopes" rust#106493
**Link:** https://github.com/rust-lang/rust/pull/106493
### "Lint ambiguous glob re-exports" rust#107880
**Link:** https://github.com/rust-lang/rust/pull/107880
Sign in with Wallet
Connect another wallet