---
title: Triage meeting 2023-01-24
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-01-24

## Attendance

* Team members: nikomatsakis, josh, scott, pnkfelix
* Others:

## Meeting roles

* Action item scribe: simulacrum
* Note-taker: simulacrum

## Scheduled meetings

- "Contracts proposal team review" [lang-team#190](https://github.com/rust-lang/lang-team/issues/190)
- Meeting happened; we have a [document](https://hackmd.io/KqQGn5X_QAKwWxTk23E68Q?view) with questions.
- Felix: No negative feedback on questions, but Josh had questions around "do we do this at all?"
- Felix: Guiding stakeholders on criteria that are absolutely necessary vs. not.

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

### Future sizes / opsem

- Niko: We have data that Futures are big, and this costs performance. (5-15% potential improvement in one service).
- Interesting test case on our team structure, some of the optimizations are gated on opsem team decisions.
- What are the interfaces? How does lang suggest/guide/etc?
- Maybe a good design meeting topic.
- Sharing stack slots helps cut Future size but need to know when we can share.
- Niko: "Early drop" tag so that dtors can happen at any time, rather than end of scope. But large continuum.
- AI: Niko to talk with Ralf etc. about a design meeting.

### Reviving "global existentials" / "global capabilities" / insert name here

// crate1
type GlobalThing: Thing;
default type GlobalThing = SomeSpecificThing;

// elsewhere
provide crate1::GlobalThing = MyThing;

Any active work in this area? Anyone interested in reviving?

- Tyler, Niko at least are interested. Yosh may be interested (past interest).
- Josh: This seems critical for async, etc. but also many such cases in practice, including 'assume 64-bit'.

trait PlatformSize {
    const PTR_BYTES_MIN: usize;
    const PTR_BYTES_MAX: usize;
}

struct PlatformSizeRange<MIN: usize, MAX: usize>;
impl PlatformSize for PlatformSizeRange<MIN, MAX> {
    const PTR_BYTES_MIN: usize = MIN;
    const PTR_BYTES_MAX: usize = MAX;
}

// exact syntax TBD
global existential type ThePlatformSize: PlatformSize;
default ThePlatformSize = PlatformSizeRange<2, 16>;

### "Properly allow macro expanded `format_args` invocations to uses captures" rust#106505

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

Can `format_args` invocations that are the result of macro expansion use implicit format captures?

#[proc_macro]
pub fn foo(_: proc_macro::TokenStream) -> proc_macro::TokenStream {
    r#"{ let x = 5; format!("{x}") }"#.parse().unwrap()
}

- Summary in [this comment](https://github.com/rust-lang/rust/pull/106505#issuecomment-1402431501)
- Example above used to fail, now works.
- Nils: `format_args!` implicit captures only work with string literals, rather than e.g. `concat!`.
- The original check wasn't implemented well, so had bugs (including ICEs).
- Scott: `format!(concat!(...))` feels differnet
- `format!(concat!(...), ...)` not working makes sense, but if a proc macro emits normal tokens, that seems fine?
- Proc macro above emits code that would be correct if it was directly in the file -> this makes sense
- But, if the macro produced code that *didn't* work if directly written, then it doesn't make sense.

- Niko: does this example work?

macro_rules! my_format {
    ($s:expr) => {
        let a = 1;
        println!($s, "22")
    }
}

fn main() {
    let a = 0;
    my_format!("{a} {}");
}

- Niko: Do we need an FCP? Seems like this just fixes the implementation to be more correct.
- Scott: Do we have hygiene on the interpolated string literal?
- Nils: Hygiene should work fine, the `a` will be from the right context. (Confirmed).

- Niko: Let's start an FCP and file a concern for tests.

- Scott: started, see <https://github.com/rust-lang/rust/pull/106505#issuecomment-1402511930>.

### "Lower baseline expectations for i686 unix-like targets" compiler-team#548

Link: https://github.com/rust-lang/compiler-team/issues/548

Zulip: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Lower.20baseline.20expectations.20for.20i686.20unix.E2.80.A6.20compiler-team.23548/near/295113474

* Main Q: Are we concerned about supporting targets with non IEEE floating point semantics (at higher tier than 3)? Secondary: How should it be labelled, as a target?
* i686 "should" support more systems, but reducing means that you get non-IEEE floating point (i.e. x87).
* Josh: I think two questions:
* Target naming -- should not call i686 if not actually i686.
* Linux distributions expect i686 to be x87.
* And separate question of what tier these targets are at, not unreasonable to push i686 to a lower tier.
* Niko: This change seem like it could break people, can we make it?
* Josh: Yes, it can. But people could switch to the "right" target.
* Josh: The question for T-lang is whether we guarantee IEEE floating point semantics in Rust?
* Niko: I feel OK about float semantics being target-dependent.
* Josh: Is there some tie to tier level, e.g., that tier 1 must have IEEE floating point.
* Scott: f32 docs very clearly state IEEE 2008 semantics for this type.
* Mark: Can we just drop floating point from this target entirely?
* Josh: No, people want to use this target with i686 semantics for floating point.
* Niko: Seems like we might want to reduce the strength of the f32/f64 docs.
* Josh: So we're aiming to not make guarantees around the tier of target relating to floating point?
* Niko: It seems like tier vs. category of floating report is independent.
* Josh: So nothing wrong with a tier-1 target with nonstandard floating point?
* Felix: I don't want to silently agree with tier 1 level of support for a ("breaking") reinterpretation of an existing target name that is at tier 1.
* Scott: Seems like there are tests that don't pass today with debug SSE(?).
* Do we guarantee that atan works on these less standard targets?
*
* Josh: I think i686 should not be tier 1 at this point, and instead it will be reduced to tier 2 or so.
* Not saying it is tier 1, but enumerating criteria we care about for tier 1 would be good.

## 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
### "Create an Operational Semantics Team" rfcs#3346

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

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

### "Relax ordering rules for `asm!` operands" rust#105798

- **Link:** https://github.com/rust-lang/rust/pull/105798
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/105798#issuecomment-1397842231):
> 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/rust/pull/105798#issuecomment-1397842217):
> Sorry for the delay in reviewing. This looks great! I think this technically needs an FCP (since it changes the stable interface), but I don't expect it to be a controversial one at all.
>
> @rfcbot merge

## Active FCPs

None.

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

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

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

* Josh: This has had a long, long discussion in compiler. Overall context: there is desire for diagnostic-improvement attributes
* Josh: Original proposal was "anything goes" attribute, new proposal is still being refined.
* Proposal is along the lines of "we are versioning this namespace"
* Older versions are maybe not supported (i.e., don't affect diagnostics), but may work too.
* Allows some backwards compatibility.
* Josh: Goal for nominating is to:
* Do we want the namespace at all?
* Does T-lang want to approve individual attributes within the namespace?
* Does T-lang feel comfortable with the versioning proposal?
* Scott: Is this similar to tool namespaces? e.g., rustfmt::, rustdoc::?
* Josh: I am quite hesitant with a blanket grant, because I don't want cross-compat concerns around different toolchains with different prefixes.
* Josh: Even if we stabilize tool attributes, we may not want rustc using these tool-specific attributes.
* Niko: "I do want this attribute, but I do consider it part of the language specification. No effect on semantics but I want them to be portable across compilers (on a best-effort basis)."
* Josh: Agreed
* Scott: Is it rustc:: or diagnostics:: feels like the same question, right?
* Felix: Is the intention of the diagnostic attribute that all effects are *changing* error/warning messages, vs. creating new warnings/error messages where none would be otherwise emitted.
* Niko: Delegating the details is OK, but let's make sure they actually document + FCP changes rather than changing however.
* Josh: Not a blank check, needs versioning/stability guarantees.

* Scott: rustc_on_unimplemented has 15+ different sub-parts, maybe not something we want. Is there a middle ground?
* Niko: Let's take this to Zulip.

### "Tracking issue for deprecation lint `proc_macro_derive_resolution_fallback`" rust#83583

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

* Felix: Lint added at some point, it is a future-incompat lint.

struct S;
mod m {
    type A = S;
}

* Warn by default for a while.
* In a recent PR, this was pushed to a hard error in https://github.com/rust-lang/rust/pull/84022
* This caused breakage (via crater). People on that PR said "this caused breakage, but seems like the crates are unmaintained, so seems whatever".

* The critical piece this was allowing/stopping from breaking:

fn foo() {
    struct S;
    mod m {
        type A = S; // YOU CANNOT REFER TO THE S via `super::S`.
    }
}

People want code like this to work:

fn foo() {
    #[derive(...)]
    struct S;
}

* Felix: Expressiveness gap ^, can't work if expanding to `mod`. I'm not very happy with not allowing expansion to `mod`.
* This is pretty common in doctests, because those put the code into a function by default.
* Fixes proposed:
* add `use fn::S;` // new `fn` component for path constructions
* petrochenkov: `#[transparent] mod { ... }`
* pnkfelix: preferred option, say `fn` silently extend their parent scope of where they appear, and `super` within a module wihtin the `fn` refer to that extended scope. (Probably breaking change technically, but its closest to the natural semantics felix expects here)
* joshtriplett: Allow `derive` to put the type it's applied to into a module. (i.e. effectively move the type's definition into a different context from where it was origianlly defined, and then `use` it from that new place)
* Niko and Josh: You'd need to have more hygiene, but you could do that.
* Niko: would like to see some discussion about whether we're trying to keep existing semantics, or not, and if so, why? if not, why not?

## Nominated RFCs, PRs and issues NOT 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

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

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

### "Implement a lint for implicit autoref of raw pointer dereference " rust#103735

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

### "make &mut !Unpin not dereferenceable, and Box<!Unpin> not noalias" rust#106180

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

### "Introduce terminating scope for tail expressions of breakable scopes" rust#106493

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

### "inline_const does not evaluate in unused function" rust#106617

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

### "Allow only implementing `Read::read_buf`" rust#106643

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