---
title: Triage meeting 2022-12-20
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-12-20

## Attendance

* Team members: niko, scott, josh, tyler
* Others: simulacrum, dtolnay

## Meeting roles

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

## Scheduled meetings
- "Contracts and Automated Reasoning for Rust" [lang-team#181](https://github.com/rust-lang/lang-team/issues/181)

## Announcements or custom items

### PR on team repo

nikomatsakis:

* https://github.com/rust-lang/team/pull/901
* next step is to post a blog post
* Josh or I planned to do it but I forgot which of us

### no meeting next week

vacation time

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals

None.

## PRs on the lang-team repo
### "change links for sections as they don't work on the website" lang-team#187

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

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**

### "Create an Operational Semantics Team" rfcs#3346

- **Link:** https://github.com/rust-lang/rfcs/pull/3346
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3346#issuecomment-1337560322):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @compiler-errors
> * [x] @cramertj
> * [x] @jackh726
> * [ ] @joshtriplett
> * [x] @lcnr
> * [x] @nikomatsakis
> * [x] @oli-obk
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @spastorino
>
> Concerns:
>
> * process-for-adding-members (https://github.com/rust-lang/rfcs/pull/3346#issuecomment-1349567620)
>
> 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/3346#issuecomment-1337560286):
> @rfcbot merge
>
> This has been under discussion for some time! I am excited about seeing this team get started.

### "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
> * [ ] @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/pull/104087#issuecomment-1350231871):
> Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
>
> @rfcbot fcp merge

scottmcm:

* Tracking issue was accidentally closed
* I think your concern is resolved Josh
* Josh: Looks like it was.
* don't need to discuss in the meeting

## Active FCPs
### "Stabilize `#![feature(target_feature_11)]`" rust#99767

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

### "Stop promoting all the things" rust#105085

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Tracking issue for RFC 2515, "Permit impl Trait in type aliases"" rust#63063

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

nikomatsakis: these are the so-called TAITs..

type Foo = impl Debug;

..key unblocker for all kinds of stuff, especially functions in traits. This has been a long time coming, so let's do it!

scottmcm: Are there any places in libs where libs was counting on not being able to name things? This gives a more obvious way to name the `!` type, for example. Well, I guess it would still not be `!` but an opaque type.

joshtriplett: I don't expect that to be a problem but you already have the ability to name `!` in various ways, I think.

scottmcm: I don't have anything coming to mind. But it seemed worth double checking.

dtolnay: something that comes to mind -- sometimes they have a public trait and they add an inaccessible type. If impl trait would let people name that type, there could be some surprises.

// library
mod private {
    pub struct Private;
}
pub trait Trait {
    fn dont_define_this(_private: private::Private) {}
}

// downstream
type MyPrivate = impl Sized;
impl Trait for MyType {
    fn dont_define_this(_private: MyPrivate) {}
}

joshtriplett: people do use it for opacity, but I don't think this would introduce a new means of naming that type.

dtolnay: it doesn't count as a defining use to use it as an argument of a trait method?

joshtriplett: your library would have to overly add use a TAIT...

scottmcm: ...I don't think this requires the library be using a TAIT, if your library is returning a type I can't otherwise name, I can now do that, even if I couldn't have otherwise done so.

joshtriplett: you can write a TAIT, like `type Foo = impl SomeTrait`, but you can't guarantee it's the same type as other hidden impl trait written in a library?

Example:

// foreign library
pub fn foo() -> PrivateType {}

// new library

type Sneaky = impl Debug;
pub fn _never_called() -> Sneaky { foo() }

// … now I can name `Sneaky` which I couldn't before …
// (though whether this enables anything I'm unsure)

// foreign library
pub fn foo() -> PrivateType {}

trait Foreign {
    fn dont_define(f: PrivateType);
}

// locally
type Alias = impl Debug;

fn foo() {
    let alias: Alias;
    <ForeignType as Foreign>::dont_define(alias);
}

impl Foreign for MyType {
    fn dont_define(f: Alias)
}

nikomatsakis: I don't believe this compiles today...

[playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=df2d095355a61791ec5a98794a5a4807)

### "Panic on invalid usages of `MaybeUninit::uninit().assume_init()`" rust#100423

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

scottmcm: ... *niko misses a bunch of context*

joshtriplett: Two questions. Are we ok with doing it, and are we ok with doing it invisibly? The first one seems like yes. The concerns expressed were that it's magic and hard to debug. I wonder if we can solve that problem an explicit attribute on "assume init", something that says, "don't allow this after `uninit`"? Could flag that there's behavior here...?

scottmcm: What is difficult to debug about it? Ralf's comment says "there is panic-str-no-unwind" which aborts with a message. Assuming we have a nice panic message, I think it should be quite debuggable?

joshtriplett: Yes. But I can imagine scenarios where you hit this but you are writing code that doesn't expect to panic, and you look right past this chunk of code since you don't see any way it can produce a panic. e.g. remote debugging of a program with a limited channel to get information out. Documentation would likely help with that, and a flag might help too so if people look at source code.

scottmcm: If goal is to make it visible from source code, maybe just a comment in the source?

Gary: can we add an intrinsic call to "assume init" as a marker of "compiler has magic transformation of this function"?

scottmcm: intrinsic is probably easier...

mark: I wonder, long term, once we have the discussion around contracts, this feels very much in the land of "I want to have some ghost state that says I can't call this method after that other one".

nikomatsakis: I'm a bit concerned about the "best-effort" nature of this. Not super enthused. If we adopt a more principled way to detect this in the future, maybe it won't line up with this analysis? But it does seem useful.

scottmcm: Is there a way to say "lang is ok with this but also fine with compiler scoping the amount of work/messaging to what they are happy with this"

nikomatsakis: Do we have a sense for how many real-world bugs this will catch?

scottmcm: I think it depends what "help" means here. I think there's a lot of this in the wild, but mostly people who changed from `mem::uninitialized` to this, so it's sort of "it'll help people because there are too many still doing this" but also "those people are not wanting help".

tmandry: crater run?

simulacrum: often in code that's hard to cover by crate.

nikomatsakis: can't we make this a hard error for purposes of crater run?

scottmcm: not UB to have the code

simulacrum: my memory is that there are quite a few of these; the code started panicking, so they added this, which doesn't really fix the UB. I do worry that those people, if we do cause them panics, are going to say "ok, well, I'll split it across a line and put a mem-identity or something".

nikomatsakis: why is this not a lint?

scottmcm/simulacrum: I think it already is

nikomatsakis: oh.

Yup: <https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=998ec15fab5a34349512ec647e290e79>

warning: the type `u32` does not permit being left uninitialized
 --> src/lib.rs:3:5
  |
3 |     MaybeUninit::uninit().assume_init()
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |     |
  |     this code causes undefined behavior when executed
  |     help: use `MaybeUninit<T>` instead, and only call `assume_init` after initialization is done
  |
  = note: integers must not be uninitialized
  = note: `#[warn(invalid_value)]` on by default

joshtriplett: Only advantage of panicking (uncond.) but not hard error is if we expect the code to be dead, right?

simulacrum: can't make it a hard error -- somewhat annoying to do so -- because it could occur in generic code.

joshtriplett: isn't that invalid for any type?

simulacrum: we allow it fortypes that have a valid bitpattern (maybe not)

scottmcm: e.g., ZSTs

jakob: regardless, allowed for any type `T` that you are allowed to leave uninit

scottmcm: pretty common for an array of `MaybeUninit`, per jakob's point

garyguo: `uninit_array` is implemented this way https://doc.rust-lang.org/src/core/mem/maybe_uninit.rs.html#352

jakob: can't determine if it's UB before mono

joshtriplett: I'd still rather see a post-monomorphization error than a runtime panic

scottmcm: you can write a "if sizeof(T) == 0, do this". (We might consider doing something like "Add mem::conjure_zst for creating ZSTs out of nothing #95385" for that case. Of course, `mem::zeroed()` is also good for ZSTs.)

scottmcm: we could do `uninit_array` using `[const{ MaybeUninit::uninit() }; N]` now, so this `MaybeUninit::uninit().assume_init()` is less needed now.

outstanding concerns:

* impact on existing users and crates?
* unpredictability of the analysis?
*

jakob: maybe worth having a deisgn meeting around this. This is not the only sort of optimization we have that's going to detect uncond UB. Broader question: if something somewhere detects the

nikomatsakis: I agree that a design meeting to get our strategy straight makes sense. I am pretty sympathetic to this PR, but I'd like to have

joshtriplett: would anyone hard object if this were to go forward?

tmandry: I would want to know the impact on users who can't do anything about the problem -- eg., library consumers. Crater run might not catch all issues, but would help you understand how many people's CI is going to break by landing this.

nikomatsakis: having thought about it somemore, I think I withdraw my concern about unpredictability, it seems strictly better to detect UB than not.

scottmcm: are we happy with "if people complain about things on beta"...?

joshtriplett: it seems exceedingly likely that people using this pattern will complain and ask for more time. I don't want to assume we'll back it out, though we should consider doing so.

scottmcm: we are linting on this pattern for known types.

nikomatsakis: I'm not super happy with the "try beta and see what happens" approach.

nikomatsakis: I wonder about an RFC laying out the strategy: compiler is going to make UB into panics where it can, and we'll have some way to opt-in to more expensive checks.

simulacrum: seems related to the const unsafe UB RFC? I think that could make sense.

nikomatsakis: goal is communication as much as anything

scottmcm: had a similar case with detecting misaligned pointers

tmandry: I like that approach, ties into something I was going to say, if we had a flag to relax this, it woudl go a long way to making it not a hard step function "oh this is landed".

nikomatsakis: that's exactly the kind of thing I think we might settle on through the RFC process. and/or tying to editions.

scottmcm: if we treat this like the debug alignment checks, or integer overflow, one way to catch people who wrote code more than people who use it woudl be to do debug mode

nikomatsakis: I guess I assumed that would be the case..? oh, it's unconditional

joshtriplett: does give people ability to turn something off...

joshtriplett: seems like we won't reach consensus, I wonder if we should get someone to ask for a specific proposal on this issue. Somebody want to take point?

tmandry: I'll take it.

nikomatsakis: maybe sync up with pnkfelix on that

### "More deriving on packed structs" rust#104429

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

tmandry: wanted to raise this one up.

joshtriplett: proposal was nominated because it broke some crates, but it also *unbroke* crates, which wasn't clear before.

Nomination summary: https://github.com/rust-lang/rust/pull/104429#issuecomment-1320909245

nikomatskais: do we have a sense for how many?

joshtriplett: not sure, but an old version of winapi is included, so the transition dep graph is large

scottmcm: I think Ralf fixed that version, but if they pinned it...

scottmcm: Ignoring any practicalities, I agree with this summary: https://github.com/rust-lang/rust/pull/104429#issuecomment-1319643988

nikomatsakis: I'm in favor of going ahead here. IT seems like a case where it makes sense to bend the stability rules -- the derive is kind of incoherent, this fixes more than it breaks, it doesn't impact anything major in a bad way, we should move forward.

action item: nikomatsakis

### "Experimental feature gate proposal `interoperable_abi`" rust#105586

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

joshtriplett: are we ready to merge this PR? does anybody object to this going forward as an experiment?

*no objections*

scottmcm: I'm scared :ghost:, but I have no objections to people trying it :)

tmandry: I can do a lightweight liaison role

### "PhantomData: fix documentation wrt interaction with dropck" rust#103413

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

### "Tracking Issue for "C-unwind ABI", RFC 2945" rust#74990

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

nikomatsakis: Background is that

joshtriplett: It sounds like part of the proposal is how precisely we want to move forward. Should we stabilize C-unwind and then make changes to C later on? Other way we could do it is to offer a cfg option.

nikomatsakis: It's not a big change in codegen? Oh, do we catch-and-panic.

nikomatsakis: I think we should give people time to adapt. always better.

joshtriplett: concrete proposal:

* stabilize C-unwind
* document the deadline in release notes
* reach out to known crates (libjpeg, ruby)

joshtriplett: who wants to write the FCP?

nikomatsakis: I would recommend first we create a feature gate split and then open a PR stabilizing just the one feature gate. Cleaner.

gary: this will cause some extra UB for nightly crates, because you'd need an add'l feature gate to cause an uncaught panic to trigger an abort vs just causing UB.

nikomatsakis: ah, yes, the perils of being on nightly I guess.

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

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

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

### "Clearly specify the `instruction_set` inlining restrictions" reference#1307

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