---
title: Triage meeting 2023-02-07
tags: triage-meeting
---
# T-lang meeting agenda
* Meeting date: 2023-02-07
## Attendance
* Team members: nikomatsakis, pnkfelix
* Others:
## Meeting roles
* Action item scribe: pnkfelix
* Note-taker:
## Scheduled meetings
- "Contracts proposal team review" [lang-team#190](https://github.com/rust-lang/lang-team/issues/190)
## Announcements or custom items
### Planning meeting tomorrow
Reminder to file design meeting requests!
## 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.
## Proposed FCPs
**Check your boxes!**
### "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
> * [ ] @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/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 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
### "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...
## Active FCPs
### "Relax ordering rules for `asm!` operands" rust#105798
**Link:** https://github.com/rust-lang/rust/pull/105798
## P-critical issues
None.
## Nominated RFCs, PRs and issues discussed this meeting
### "Mark RFC 1201 (naked functions) superseded by RFC 2972 (constrained naked functions)" rfcs#3223
**Link:** https://github.com/rust-lang/rfcs/pull/3223
scottmcm: I didn't give you the suggestions, oops. Probably doesn't need more discussion.
### "Stabilise inline_const" rust#104087
**Link:** https://github.com/rust-lang/rust/pull/104087
Un-nominating, will handle in upcoming design meeting.
### "RFC: Start working on a Rust specification" rfcs#3355
**Link:** https://github.com/rust-lang/rfcs/pull/3355
nikomatsakis: Update: there will be a meeting tomorrow where some of us plan to discuss how to editor could work and how to integrate this into Rust processes. My take is that this RFC should be a bit more specific about the role the spec will play in our processes before we accept it.
joshtriplett: Other question is the approval process -- lang should sign off, but what else is needed? Does it make sense to have separate FCPs, one for lang, one specifically for the logistical support provided by the foundation, since trying to do giant multi-team FCPs can take forever?
nikomatsakis: How big would this be?
joshtriplett: compiler ~~is~~ was also tagged, not clear if that is a conscious decision. Would anybody object to starting an FCP on this to start to gauge consensus?
scottmcm: can't add teams to FCPs after it started, and can't do a second FCP?
joshtriplett: no, but we can file a separate issue, or do `rfcbot poll`.
nikomatsakis: I think we should hold off until after meeting tomorrow. I hope we can emerge with clearer consensus about what should be in there which in turn will inform what teams should be tagged.
### "Stabilize cmpxchg16b_target_feature" rust#106774
**Link:** https://github.com/rust-lang/rust/pull/106774
joshtriplett: we sign off on these, but no particular reason to see this as different from other target features.
scottmcm: +1, Amanieu likes it. He's our lang team advisor for this sort of thing.
pnkfelix: Why `RUSTC_VERSION`?
scottmcm: helps with stabilizing libs stuff.
FCP started: https://github.com/rust-lang/rust/pull/106774#issuecomment-1421319274
### "Tracking issue for RFC 2515, "Permit impl Trait in type aliases"" rust#63063
**Link:** https://github.com/rust-lang/rust/issues/63063
### "TAIT defining scope options" rust#107645
**Link:** https://github.com/rust-lang/rust/issues/107645
*nikomatsakis explains background*, highlights 3 challenges
* IDE performance, main motivator
* cycle errors in some cases
* usability -- actually, current system requires pretty good understanding
scottmcm: How frequent do we think these kinds of cycle errors are?
nikomatsakis: tied to auto traits primarily. example oli gave that causes cycle error today:
```rust
#![feature(type_alias_impl_trait)]
#![allow(dead_code)]
// FIXME This should compile, but it currently doesn't
mod m {
type Foo = impl std::fmt::Debug;
//~^ ERROR: cycle detected when computing type of `m::Foo::{opaque#0}` [E0391]
pub fn foo() -> Foo {
22_u32
}
pub fn bar() {
is_send(foo());
}
fn is_send<T: Send>(_: T) {}
}
fn main() {}
```
nikomatsakis: outside m, you know that `Foo: Send`.
nikomatsakis: today this causes cycle errors inside `m`, I think intent is for this to eventually be improved.
joshtriplett: why do we leak auto trait, should we stop doing that?
nikomatsakis: no, for consistency, but also because of conditional stuff.
joshtriplett: are we adding hacks on top of hacks here to avoid having a full auto trait propagation mechanism (`Send` if such-and-such is `Send`)?
nikomatsakis: I don't think so, more like...preserving the hack.
tmandry: can the same tait be send and not send
```rust
mod m {
type Foo<T> = impl Debug;
pub fn foo<X> -> Foo<X> {
}
}
```
nikomatsakis: yes iff you have a generic param
nikomatsakis: for example, can we do this?
```rust
mod m {
type Foo = impl Debug;
fn bar() {
let x: Foo = 22_u32;
}
}
```
under current code, answer is yes, this constraints `Foo` to be `u32`.
Next proposal was "put it in the signature", but what is def'n of signature? Perhaps arg/return types, or where-clauses?
```rust
mod m {
type Foo = impl Debug;
fn bar() {
let x: Foo = 22_u32;
}
}
```
nikomatsakis: my concern is that this doesn't feel like something that "clearly" defines `Foo`...
```rust
pub fn bar()
where Foo: Send,
{
is_send(foo());
}
```
tmandry: agree, it seems off
pnkfelix: I would interpret that to mean "only callable when Foo is send"
tmandry: does mean that... but...
pnkfelix: example like `where Foo:` ... seems like it's sending no signal... but it has an effect.
```rust
#[defines(Foo)]
pub fn bar()
{
is_send(foo());
}
```
```rust
impl Foo for Bar {
type Bar = impl Debug;
#[defines(Self::Bar)] // don't expect to write this
fn foo() -> Self::Bar {
}
}
```
nikomatsakis: I'm inclined to say "only in return position"
joshtriplett: I feel like `where Foo: Send` does send a signal that it depends on the properties of foo. This is not a declaration that Foo is send. It's a declaration that bar is only callable if the type Foo is Send, and then foo, which is allowed to define Foo, calls bar, which means Foo must be Send.
nikomatsakis: I think this example would give a cycle under the proposal as written:
```rust
pub fn bar()
where Foo: Send,
{
is_send(foo())
}
```
Example that uses foo less, and behavior under Proposal 2:
```rust=
mod m {
type TAIT = impl Debug;
// Constraints: TAIT = u32
pub fn f1() -> TAIT { 22_u32 }
// What does this do?
pub fn f2a() where TAIT: Send {
// I *think* this is accepted but puts 'no constraint'
}
// What does this do?
pub fn f2b() where TAIT: Send {
is_send(f1()); // Cycle error today
}
// What does this do?
pub fn f3() where TAIT: Send {
let x: TAIT = 22_u32; // OK
}
pub fn f4() {
// ERROR: cannot constraint TAIT, cannot observe hidden type
let x: TAIT = 22_u32;
}
}
```
joshtriplett: I would expect under proposal 2 that a function in the defining module could _observe_ the type even if it isn't allowed to _constrain_ it.
nikomatsakis: I think you could do it, would be more complex, is it what we want?
```rust
fn bar() {
let mut x: impl Debug = 22_u32;
x = 44_u32; // ERROR-- RFC said intent was to not depend on precise type
}
```
joshtriplett: I thought of it as a way to not write the type.
pnkfelix: \<type type type an example that tries to make the "boundary" more explicit\>
```rust=
fn attempt_reencoding() {
let mut x = (|| -> impl Debug { 22_u32 })();
x = 44_32; // ERROR-- would this bring back people's local abstraction intent from let example above?
}
```
nikomatsakis: interesting example below, is the intent here to "hide" the fact that this is a range, or just to say `Item = u32`?
```rust=
fn bar() {
let mut x: impl Iterator<Item = u32> = 0..5;
for n in x.rev() {
// ERROR under some proposal
}
}
```
joshtriplett: I feel like it is more consistent to say "I can't call things" but I do expect to be able to assign things. Else why it is mut?
pnkfelix: The trait may have `&mut self` methods.
nikomatsakis: I am wondering if we can highlight some specific things we want to work and issue errors in other cases so that we can make forward progress and leave ourselves room to argue about the rest.
*Conclusion:* no conclusion, continue discussion off line
### "Support linking to rust dylib with --crate-type staticlib" rust#106560
**Link:** https://github.com/rust-lang/rust/pull/106560
joshtriplett: I propose that lang un-tag itself here and state that this isn't a lang issue.
General agreement that:
* There is no proper team for this right now.
* There is more expertise about linking specific in compiler than in lang right now -- except that Tyler, Josh, and Felix all kind of raised their hands. So maybe not!
* We should delegate to compiler here.
nikomatsakis: some advisors might be a good middle ground here.
### "Allow only implementing `Read::read_buf`" rust#106643
**Link:** https://github.com/rust-lang/rust/pull/106643
Blocked on PR author, un-nominating.
### "inline_const does not evaluate in unused function" rust#106617
**Link:** https://github.com/rust-lang/rust/issues/106617
scottmcm: Un-nominated in favour of https://github.com/rust-lang/lang-team/issues/195
## Nominated RFCs, PRs and issues NOT discussed this meeting
### "Introduce terminating scope for tail expressions of breakable scopes" rust#106493
**Link:** https://github.com/rust-lang/rust/pull/106493
Sign in with Wallet
Connect another wallet