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

# T-lang meeting agenda

* Meeting date: 2022-12-13

## Attendance

* Team members: josh, pnkfelix, nikomatsakis, Tyler, scottmcm
* Others: simulacrum, Mara, 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

### how to proceed about contracts?

nikomatsakis: I think we should shoot for the next meeting to be a high-level document set of principles

josh: I think we could just continue the discussion and questions we had

pnkfelix: one feedback I have, some of the questions are tilted towards verification, if we spend a lot of time on that when it may not be the solution we end up with, could be a waste of time.

joshtriplett: what do you mean by that?

pnkfelix: depends on what purpose of contracts are, but if it's all about end-to-end proofs, that will entail a number of contraints on the system that we end up with. It's not clear from the meeting whether we had consensus about that detail. Definitely some stakeholders who said, with Ada, contract was entirely dynamic but static had to be reached with separate tooling. It's that kind of high-level detail that I think needs to be hammered out early before you dig into the details of the limits imposed by verification. Does that make sense?

nikomatsakis: as a possible next step, maybe we should do an ad-hoc meeting to do more deep dive? With my lang team hat, I think the next doc I would like to review is that high-level one.

pnkfelix: Josh, do you think the majority of the questions were worth teasing out, won't be time ill-spent?

joshtriplett: I won't say that every question needs to be answered before people start doing work. But I do think that there may be some additional discussion that needs to happen before people start working out to make sure people aren't heading in the wrong direction. Those questions seemed as good a starting point as any to provoke the discussion. To give one of many examples, I'd like to discuss how we push for standardization here, where we don't have different tools giving different capabilities. That's the kind of thing I would want to discuss and have agreement on.

tmandry: I feel like there needs to be a champion for the overall effort. I'm not sure if there is one?

joshtriplett: A good point, if someone proposed tomorrow to have experimental feature gate, who would liaison be? There's an obvious choice, but do they know they're the obvious choice?

pnkfelix: For me, it would depend on what direction it went in.

nikomatsakis: that sort of question is exactly the kind of thing I think that high-level doc should address.

joshtriplett: Do we have requirements for that high-level doc such that if we ask for it we'll get what we actually want?

nikomatsakis: maybe we should extract the questions we want answers *to*, and then we can decide whether we want to just discuss them, or ask for a doc.

pnkfelix: indeed, we can discuss them amongst ourselves first.

nikomatsakis: pnkfelix, can you do a first pass?

pnkfelix: I think so.

re: champion, clear that there could be one, we'll revisit.

## 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
### "RFC: `c"..."` string literals" rfcs#3348

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

Action item: tmandry takes it

## Proposed FCPs

**Check your boxes!**
### "Stabilize `#![feature(target_feature_11)]`" rust#99767

- **Link:** https://github.com/rust-lang/rust/pull/99767
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/99767#issuecomment-1320937299):
> 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
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @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/99767#issuecomment-1320937292):
> @rfcbot merge

nikomatsakis: observation that oli's work on keyword generics is relevant here, you can think of SSE generation as a kind of "effect" that would propagate.

tmandry: would be nice to have an update on what new capabilities are, what we could play with.

nikomatsakis: maybe a design meeting in new year?

pnkfelix: edge case involving closures: they inherit target settings of the context in which they're defined. In order to call the fn you know feature is available while it executes and for the lifetime of what escapes from it. Is that enforced by the compiler somehow?

joshtriplett: right now, target features are assumed to be enduring, as in, if you have ever run a function that has this target feature, it's assumed you're always allowed to call code with that feature. So if you're running in the fn, and you pass out the closure, you can still run it later. The mechanism is not nearly full featured as allowing for a "lease" to use the feature, or allowing you to change modes, asymmetric multiprocessing systems, etc.

nikomatsakis: sounds like the sort of thing we might be able to express with effect system I was talking about

joshtriplett: yes, if you had properties captured by type system, could do it, but that's not a system we have a design for right now, and target feature 1.1 isn't intended to solve that problem. Sounds like target feature 2.0. Would be nice, would need a champion.

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

- **Link:** https://github.com/rust-lang/rust/pull/105085
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/105085#issuecomment-1339855315):
> 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
> * [ ] @pnkfelix
> * [ ] @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/105085#issuecomment-1339855262):
> Discussed in today's @rust-lang/lang meeting. Looks good, let's confirm consensus via FCP:
>
> @rfcbot merge

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

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

joshtriplett: Filed a concern that we need to specify process for adding a new member. Don't anticipate this being a problem. Should opsem decide its own membership, or should lang team decide it?

nikomatsakis: I expect them to decide their own membership.

joshtriplett: Yes, I just think we should say it.

pnkfelix: Does any team not follow that model?

joshtriplett: Yes, things like libs-contributors, compiler-contributors.

pnkfelix: I don't think of those as capital "T" teams like "T-lang", but it's true.

nikomatsakis: notably they lack decision making power, but yes.

### "Tracking issue for the "efiapi" calling convention" rust#65815

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

### "Stabilize default_alloc_error_handler" rust#102318

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

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

### "always check alignment during CTFE" rust#104616

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

Note from Ralf 10 days ago:

https://github.com/rust-lang/rust/pull/104616#issuecomment-1336154077

> we'd like to enable alignment checking in CTFE by default. It turns out this does not impose any measurable performance cost, so there doesn't seem to be any reason not to detect this UB.
>
> However, this change could break code that violates alignment during CTFE. Out of an abundance of caution, this PR makes failed alignment checks emit a deny-by-default lint that shows up in cargo's future-breakage reports. That means we don't break users of crates that fail this check. We plan to turn this into a hard error a few releases down the road.

scottmcm: I think we should say "talked about it and it sounds great", no need for FCP.

joshtriplett: we have in the past used deny-lints as mechanisms for catching this kind of thing, which has been a source of stress on const eval in the past that took a while to get there. Was the state of crater run such that there were enough problems? This says 0 regressions. Oli says 1 item that wouldn't have been found by crater. I'm wondering if we need to do a deny-by-default lint. Maybe just make an error?

scottmcm: I'd be happy to say that lang is happy to make this change. We're good to trust Oli + compiler's judgment to stage it as they feel appropriate. I assume if it was a major difficulty on const eval, then Oli or Ralf would've said "can we just do it directly".

joshtriplett: +1, I'm in favor of handing discretion

**Consensus:** hand over discretion

joshtriplett: Does someone have time to write a quick comment?

pnkfelix, with surprising and suspicious enthusiasm: I'll do it!!! I'll do it!!

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

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

joshtriplett: Previously talked about this with the name "Safe ABI". I've renamed it since then because safe was a bit of a misnomer. Strict superset of the C ABI, and it turns out C has unsafe things (!). Proposal here is for an experimental feature gate, in order to experiment with building a "better than C" ABI. I'd be happy to be a liaison for this. Might also make sense for Tyler to be, or both of us, since Tyler is working on this as well. Wanted to know if there are any concerns. Standard process here is that we have to write an RFC before it stops being experimental.

scottmcm: I have two opposite feelings. I think process is that an experienced contributor can just sort of do this, and that's ok, as long as impact on compiler isn't too high, so great, go ahead.

joshtriplett: I had hesitation because I didn't want to second my own proposal, wanted to give space for objections.

scottmcm: It feels like there's a lot of exploratory here. Makes me wish there was a place to experiment with that that wasn't the "good luck getting a PR in less than 2 days" compiler.

joshtriplett: I'm not expecting to do detailed iterative experimentation. I anticipate this being: now that it's approved, we'll do a bunch of design work, large PR, rinse and repeat, don't anticipate this being hampered by it taking a long time to get PRs into rustc.

tmandry: I have a couple of bigger picture questions I never got around to asking. It seems like this is moving in the direction of creating an expanded C FFI that is a standard across multiple languages, not just Rust. Should we open it up to other languages, e.g. Swift, if they'd be interested; if so, at what stage?

Mara: my idea was to author a blog post as soon as we have something interesting to share, this will catch enough attention that folks from zig/swift/whatever would show up. I think we should start out with our own draft.

Josh: :+1:

tmandry: Sounds reasonable. I remember discussing with you something more akin to a Rust 2022 ABI. This kind of morphed into something different than that. I'm wondering what considerations were.

Joshtriplett: Two things worth solving. Having a stable ABI for interoperability between languages: why do Python/Rust have to go through C to express a safe string? The other is interoperating between two versions of Rust. First of those, we can still use that for interoperability between Rust, but the second one would have less consideration for whether any other language will ever care. Can express things like e.g., vtable layout that we might not get to as soon with "interoperable ABI". So I think these are two distinct efforts. Wouldn't want to unify them, though if we find that it works well enough, great.

mara: I expect that if we have slices etc this will get a lot of attention since those are concepts that other languages like zig have.

tmandry: makes sense.

mara: did you see the diagram I posted?

*tmandry admires it*

tmandry: depending on overhead, I think I can volunteer to be a liaison, I don't think I can get actively involved in the design.

joshtriplett: ok. let's talk async. liaison should be low overhead and doesn't have to be actively involved in design.

mara: I'll be driving it and I think I know folks well enough that it's not a high overhead role in this case

joshtriplett: +1, ok! Process is merge PR, work behind the feature gate, next doc is an RFC. Will also create Zulip stream.

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

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

joshtriplett: Mara put this together after our previous meeting. I nominated it. Not exclusively lang. Covers lang, libs-api. There's a request for foundation to cover funding someone to work on this. Variety of things going on here. I think this is the right starting point. RFC isn't the spec, it's "We should have a spec, and here are the requirements for it".

mara: I think impetus for starting the FCP should come from lang, since that's where we discussed it, though the checkboxes are for multiple teams.

joshtriplett: Always hard when there are multiple teams to decide who should initiate. I agree in kicking off FCP from lang. More a matter of bringing it to peoples' attention for discussion.

scottmcm: Is there a specific question that we have to answer in triage?

joshtriplett: "Do we want a spec"

...some discussion about what we need to cover in triage meeting...

joshtriplett: I wanted to check if there's any reason not to handle this through the FCP process.

mara: I wanted to make sure you all know that lang team should initiate FCP, else it might sit forever.

tmandry: foundation aware of this?

mara: yes

joshtriplett: we should discuss separately how to select/hire the person doing coordination at the Foundation

### "Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report" rust#103418

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

Example code:

macro_rules! foo {
    () => {
        true;
    }
}

fn main() {
    let val = match true {
        true => false,
        _ => foo!()
    };
}

pnkfelix: Currently there's a lint to remove the `;` from above. The PR is saying we should make this future-incompat. It is not clear to me if this is t-compiler or t-lang decision, but I notice that the lang team had requested approval in this area in the past. I don't think an FCP is needed here but wanted to make people aware of it.

joshtriplett: sounds like we already reached decision, but we requested being nominated, and so you are nominating.

pnkfelix: do we want to be nominated for a hard error?

joshtriplett: I don't think we agreed on that, should prob second FCP.

pnkfelix: lang team approved warn by default.

*some debate about whether it is deny-by-default, conclusion: not*

Consensus: we are happy, remove nomination, no further action needed from lang.

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

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

scottmcm: Ralf has a nice comment.

joshtriplett: Didn't we discuss this?

pnkfelix/scottmcm: We did, but don't remember if we reached a conclusion.

joshtriplett: everybody ok with detecting these invalidate usages and producing panics? definitely best effort, if you have arbitrary flow in between `MaybeUnit::uninit()` and `assume_init`, it won't necessarily catch it.

garyguo: there was consensus before that "this is UB anyway, making it panic shouldn't be a problem". But some concern from Ralf that making UB into panic is not very usual, so T-lang should have a look.

scottmcm: I thought we did this in a bunch of places. If you call `mem::uninitialized` on something that can't be ....

garyguo: this is done in MIR opt pass, not library

scottmcm: I don't draw such a line there, esp. as an intrinsic is involved

...

tmandry: quesion for me is empirical: performance, does it break people's programs in practice, that sort of thing? I don't have a problem with the *idea* of it.

pnkfelix: why not make it a lint, didn't ralf ask this?

tmandry: he did; ideally this check takes place post monomorphization.

joshtriplett: calling time

### "Stabilize default_alloc_error_handler" rust#102318

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

In FCP, nomination dropped

## Nominated RFCs, PRs and issues NOT discussed this meeting

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

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

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

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

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

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

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

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