---
title: Triage meeting 2022-08-16
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-08-16

## Attendance

* Team members: Josh, Felix, Niko
* Others: Mark

## Meeting roles

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

## Announcements or custom items

### operational semantics team (nikomatsakis)

* UCG is making good progress
* Given a piece of MIR, what happens when it executes? When do we have UB in that execution?
* Types team has 'safe Rust' in some sense, but this team would own the unsafe/specification of miri, in some sense
* Need lang input on some of these questions, so need someone to work closely
* Felix is expressing interest!
* Next steps:
* [ ] we'll want an RFC proposing the team formation; that needs a charter (perhaps adapted from notes above)
* [ ] but before making an RFC, would be good to demonstrate concrete products. E.g. some collaborative effort around minirust or similar.
* (basically a 'proof of concept' for how the team will work, let's discuss offline --nikomatsakis)

## Action item review

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

## Pending lang team project proposals
### "Support platforms with size_t != uintptr_t" lang-team#125

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

### "Positional Associated Types" lang-team#126

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

### "Interoperability With C++ Destruction Order" lang-team#135

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

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

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

### "Async fns in traits" lang-team#150

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

### "dyn* trait" lang-team#158

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

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

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

### "Initiative: Ghost types and blocks" lang-team#161

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

### "Keyword generics" lang-team#162

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

### "Add const evaluatable `where const { <block> }`" lang-team#163

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

### "#[repr(Interoperable_2024)]" lang-team#165

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

## PRs on the lang-team repo
### "Note design constraints on hypothetical `DynSized`" lang-team#166

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

## RFCs waiting to be merged
### "Refined trait implementations" rfcs#3245

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

## Proposed FCPs

**Check your boxes!**
### "Tracking issue for `..X`, and `..=X` (`#![feature(half_open_range_patterns)]`)" rust#67264

- **Link:** https://github.com/rust-lang/rust/issues/67264
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/67264#issuecomment-1209771069):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @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/issues/67264#issuecomment-1209771052):
> @rfcbot merge
>
> We discussed this in a (not-so-recent) lang team meeting. My recollection of the consensus was that it wasn't obvious that there's a lint here obviously-valuable enough to block the existence of the feature on having it. (And, by analogy, you don't have to write `x <= 0 || x < 2` for signed numbers, just `x < 2` is enough, so a `..=2` pattern seems enough as well.) As such, I propose that we just accept this as a feature, and let people propose lints once we find out whether there's actually any confusion that results from it.
>
> Especially since patterns like this are the only way to use exhaustive matching on `isize` without a catch-all, the same way that `X..` patterns are the only way to do exhaustive matching on `usize` without a catch-all.
>
> (As an example for lints, I'd happily turn on a lint for something like "hey, that `..X` could be `0..X` because the type is unsigned", since that's easy to read+type and exhaustive integer patterns allow that without an extra wildcard arm. That would then mean that `..2` that's *not* `0..2` would subtly hint that it's signed. But that's not something I think this feature should be *blocked* on having, nor is it even something I would necessarily say belongs as warn-by-default in rustc.)

Folks take a look!

### "Tracking Issue for `#[instruction_set]` attribute (RFC 2867)" rust#74727

- **Link:** https://github.com/rust-lang/rust/issues/74727
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/74727#issuecomment-1202855460):
> Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [x] @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/issues/74727#issuecomment-1202855405):
> Okay, I reviewed the update from last year and fixed the first godbolt link (`asm!` has stabilized since it had been posted).
>
> Its an interesting question, whether to stabilize something that has clear performance issues (in terms of not meeting typical zero-cost expectations). But that is a quality-of-life issue; if users can find utility in this feature even in its current state, then that's an argument for stabilization.
>
> I'll go ahead and fire off a stabilization FCP.
>
> @rfcbot fcp merge

Folks take a look!

### "Tracking Issue for asm_sym" rust#93333

- **Link:** https://github.com/rust-lang/rust/issues/93333
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/93333#issuecomment-1182038632):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [x] @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/issues/93333#issuecomment-1182038596):
> Shall we stabilize sym in `asm!`?
>
> @rfcbot merge
>
> EDIT: Link to above stabilization report: https://github.com/rust-lang/rust/issues/93333#issuecomment-1101813004

### "Stabilize `let else`" rust#93628

- **Link:** https://github.com/rust-lang/rust/pull/93628
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383585):
> 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
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * need-consistency-rvalue-temporary-rules-between-let-and-let-else (https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523)
> * ~~not-while-rustfmt-breaks-on-it~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1032936704
> * ~~semicolon~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1059799661
> * ~~stabilization-report~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1033846359
> * ~~summarize-concerns~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1056785904
>
> 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/93628#issuecomment-1029383577):
> Shall we stabilize `let else` syntax? We've had many demonstrated uses, including extensively throughout `rust-lang/rust`, we've seen the value of it, and there aren't any known issues with it.
>
> @rfcbot merge

This is almost entirely ready, but there are a last few PRs to address some drop-order issues.

It may beat if-let-chain due to [#100513](https://github.com/rust-lang/rust/issues/100513), or they may land at the same time.

### "Stabilize generic associated types" rust#96709

- **Link:** https://github.com/rust-lang/rust/pull/96709
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/96709#issuecomment-1181931476):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @compiler-errors
> * [ ] @cramertj
> * [x] @jackh726
> * [x] @joshtriplett
> * [ ] @lcnr
> * [x] @nikomatsakis
> * [ ] @oli-obk
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @spastorino
>
> 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/96709#issuecomment-1181931456):
> @rfcbot fcp merge
>
> ... (elided) ...

joshtriplett: I checked my box.

nikomatsakis: we scheduled a review?

joshtriplett: For benefit of folks who need an overview, we have a review scheduled for the last design meeting of the month. I think that's the 31st.

nikomatsakis: I had been considering proposing a requirement that some GATs are `'static` to avoid the sharper edges in the current implementation.

scottmcm: I saw some threads that said lending iterators doesn't work, is that true?

nikomatsakis: true, polonius is required to make lending iterator work, also the implied bounds problem, which can be sidestepped with `'static`. I think a lot of the times that people use this in practice they have `'static` types.

joshtriplett: async methods in traits aren't blocked on polonius, right?

nikomatsakis: correct.

### "Strengthen invalid_value lint to forbid uninit primitives, adjust docs to say that's UB" rust#98919

- **Link:** https://github.com/rust-lang/rust/pull/98919
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/98919#issuecomment-1209747163):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @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/98919#issuecomment-1209747142):
> @rfcbot fcp merge
>
> As Ralf said in https://github.com/rust-lang/rust/pull/98919#issuecomment-1175349254, I think we should do this.
>
> For extra clarity, I don't think this says "we'll never have freeze". We can still have the possibility of a "get an unspecified but fixed bit pattern" functionality *as a separate method* in the future. I just don't think that `MaybeUninit::assume_init` (or, worse, `mem::uninitialized::<i32>()`) should be how that's spelled.
>
> If we're defacto going to have to put `noundef` on non-`MaybeUninit` function parameters, then trying to carve out some sort of "well integers could be `undef` but not when you pass them as arguments" feels more troublesome than helpful.

scottmcm: Ralf has a good comment. Just committing to "no, you cannot have poison or undef values in ordinary integers, only allowed in maybe-init integers".

Not saying that we won't do freeze, but just saying that won't "include a freeze in assume-init", rather than making freeze automatic.

nikomatsakis: If I understand, you are saying, while we can still add an explicit freeze, we are deciding not to do an *implicit* freeze.

joshtriplett/scottmcm clarify that it is still POSSIBLE to do an implicit freeze (that's less UB), but the idea here is to say we don't expect to do that.

scottmcm: most places do not want an implicit freeze, particularly in miri, as it makes it harder for miri to detect issues.

joshtriplett: seems like miri COULD detect issues, but it'd be more subtle, like valgrind style. e.g. even if you freeze something, there are probably things you shouldn't be doing with frozen values

nikomatsakis: e.g. valgrind says you can't branch on an uninit bit

scottmcm: but if it's frozen, you want to be able to branch on it. *gives an example about fast float* -- the idea is that you can't fully trust the result, but you can check `isnan`. Or even if you're just trying to read it, if you freeze a bunch of bytes, but still want to put it in a `NonzeroU32`

nikomatsakis: in cases where I've intentionally worked with uninit memory, that sounds right,the whole idea was that you would know that, whichever branch you take, it will be ok. Being able to explicit freeze would be ideal.

scottmcm: most data structures that would use uninit, e.g. implement vec as a `Box<[MaybeUninit<T>]>`, then freezing that by default would mask bugs.

scottmcm: other piece I called out is that if we de facto have parameters be "noundef" for LLVM performance, trying to carve out an intermediate place, like "it can be undef as long as you don't cross a function boundary"...

nikomatsakis: straw poll to get a sense if anyone is opposed to this change?

scottmcm: ...josh had a bunch of comments?

joshtriplett: trying to decide where I'm feeling at the moment. I tend to get frustrated by changes that are in the direction of "how we handle undefined integers", but I'm not sure if that means that I don't think we should have to mark them as such. As long as we have a freeze available in the future, I am not sure if I feel it has to happen that by default.

nikomatsakis: it would be good to use this as a prototype for "how would this issue get resolved once opsem team exists".

nikomatsakis: I do think it's important to be able to work with uninit/frozen memory, but I also think those cases are subtle, and it's good to be explicit about it.

scottmcm: the rules for shifting undefined integers are particularly subtle. llvm is kind of giving up and moving to poison. I don't know if we want rules like "if you have an undef, and you shift it left by 1, is the bottom bit not undef anymore" etc.

*a sense of foreboding fills the room*

pnkfelix: I'm getting deja vu, did we raise that example last week?

### "Holding a non-Send Copy type across a yield should be allowed" rust#99104

- **Link:** https://github.com/rust-lang/rust/issues/99104
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/99104#issuecomment-1201982157):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * needs-exact-proposed-rule (https://github.com/rust-lang/rust/issues/99104#issuecomment-1209723811)
>
> 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/issues/99104#issuecomment-1201982136):
> @rfcbot merge

*no discussion needed just now*

## Active FCPs
### "Tracking issue for RFC 2046, label-break-value" rust#48594

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

scottmcm: I finally got around to writing "the big comment"!

joshtriplett: ...huh?

scottmcm: a couple of years back there was a comment linking graydon's blog post about limiting the impact of features on the size of Rust's eventual spec. I wroteup some thoughts about how complex it would be and how worried I would be.

nikomatsakis: Agree with the comment that this doesn't add any new capabilities. Reminds of how `loop` feels so much better than `while true`. One of Rust's great contributions to programming languages.

### "Positional Associated Types" lang-team#126

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

### "Interoperability With C++ Destruction Order" lang-team#135

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

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

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

### "Async fns in traits" lang-team#150

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

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

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

### "Initiative: Ghost types and blocks" lang-team#161

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

### "Keyword generics" lang-team#162

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

## P-critical issues

None. :tada:

## Nominated RFCs, PRs and issues discussed this meeting

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

### "let_chains desugaring is wrong" rust#100513

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

joshtriplett: Was nominated for purposes of "we need to fix this, should we roll this back". General sentiment seems to be "yes, we should". Likely to revert this for 1.64 and try again later.

nikomatsakis: "COE". I feel like we should add this to a checklist of "stuff to double check".

joshtriplett: also temporary lifetimes?

nikomatsakis: I don't disagree but it feels like neither here nor there. The point is that we should in any "desugaring" feature, we should be testing that things are freed in the expecting order.

scottmcm: would be a cool edition project

nikomatsakis: would like to see people clarify which ones are most surprising.

simulacrum: but before doing that we should be testing that they are behaving as expected. I know est31 and someone else added some tests, but fairly limited in scope.

pnkfelix: I'm trying to imagine a coverage tests for evaluating the shape of the AST. Do we ever check the destruction order between this temporary and another?

nikomatsakis: maybe as a first step, a template for stabilization reports, e.g. "show me the tests for destructor ordering".

simulacrum: the example in this case is simple enough, but without fuzzing or some other example, it's easy to say "yes we have tests" and everybody is happy.

nikomatsakis: I feel like both of these cases were very simple tests.

simulacrum: surely getting back tests first would be a start.

joshtriplett: c-smith generates "valid but weird AST". I wonder if we could have a rustsmith that does something similar. That could then say "let's generate a giant pile of weird tests" and test what the result is. Then we could review those rules.

nikomatsakis: good point. interesting.

simulacrum: we had some researchers generating tests and ICEs.

joshtriplett: on the one hand, fuzzing seems useful, but fuzzing along wouldn't solve *this* problem, without some add'l rule like "let's generate test cases and check for expected ordering". And we'd need a heuristic for "does it match what we expect".

nikomatsakis: also thinking that it'd be good to write out the expected rules.

scottmcm: in this case the rfc didn't match impl.

*pnkfelix points out that csmith tests compilers against each other.*

### "Extend and expose API for {:x?} and {:X?} formatting" rust#99138

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

joshtriplett: this got covered in libs-api. I don't think we should do anything. The proposal here is related to "you're deriving Debug, and you're builtin types (integers) are being printed as decimal by default, which isn't actually what you want, so you override that at the point where you are printing in `Debug` mode to say 'actually I want hex', but ideally your `Debug` impl would print them in the format you want them by default; the inconvenience is that you couldn't `Derive` debug. In libs meeting we thought the better action was to improve derive"

scottmcm: I think i'm good to call this libs-api and "success".

nikomatsakis: +1

pnkfelix: your assertion Josh is that the in most cases this can be determined at the point of derive-debug?

joshtriplett: correct. For Display impls, you want a lot of fine-grained control, and you might want that at the point of printing. For Debug printing, point is to print the data structure in the most understandable fashion possible; debug impls should know the best to print their datastructure, and in general a Debug impl would know "hey this is a set of flags" etc, you shouldn't need to override that.

nikomatsakis: I only kind of buy that. You might have an `Option<usize>` (which are flags).

joshtriplett: you could still provide an override for that field.

nikomatsakis: You might be passing around flags outside of a data structure.

scottmcm: I can imagine 3 or 4 soln's but none are lang.

nikomatsakis: Agree.

joshtriplett: Just say that we discussed and agree it's the purview of libs-api. I'll also remove lang tag?

nikomatsakis: yep.

### "Tracking Issue for `#[instruction_set]` attribute (RFC 2867)" rust#74727

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

*cleared nomination, in pFCP*

### "Add mem_uninitialized lint to FCW lint on uses" rust#100342

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

joshtriplett: This is racheting up the complaints about `std::mem::uninitialized` so that they also warn in dependencies.

nikomatsakis: presumably because we expect to change them?

scottmcm: a bunch of these are already UB.

simulacrum: is this libs-api? The issue which spawns this is libs-api.

nikomatsakis: Feels like it's in a weird spot. The decision about what is UB feels like lang, but the decision about whether to remove it or deprecate it feels like libs-api.

scottmcm: If libs-api wants to increase lint level of something that is going to be deprecared, seems ok.

nikomatsakis: I'm ok to relabel it as libs-api.

ACTION ITEM: nikomatsakis to add comment (done)

### "Allow `impl Fn() -> impl Trait` in return position" rust#93582

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

joshtriplett: does this still need to be nominated?

> So, this was temporary blocked on impl Trait being broken, but I believe the issues were fixed, etc, and now everything should work. The only test that doesn't pass anymore is src/test/ui/impl-trait/impl-fn-predefined-lifetimes.rs, but maybe this is how it should be.
>
> Anyway, I've added the feature gate and a tracking issue.

joshtriplett: right, we were not comfortable with insta-stable. Nightly only with a feature gate doesn't require an FCP.

nikomatsakis: it doesn't need an FCP, but it does need a lang team sponsor. I'd like to ensure there's a write-up that identifies the concerns we had.

joshtriplett: I think it was something with precedence?

nikomatsakis: I think I had a concern about the behavior of `'_`, I'll have to find the write-up.

ACTION ITEM: nikomatsakis to do the above.

### "Make forward compatibility lint deprecated_cfg_attr_crate_type_name deny by default" rust#99784

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

simulacrum: we allow `#![cfg_attr(foo, crate_type = 'bin')]`. This is currently got a lint against it. This is proposing to make that deny-by-default.

joshtriplett: I would be opposed to making this a hard error, but I think a deny is fine.

nikomatsakis: are you opposed to making this a hard error *ever* or just now?

joshtriplett: reply hazy. ask again later.

scottmcm: I think if we're just changing a lint level, we don't need a full fcp?

joshtriplett: ramping up a lint can cause breakage, or change people's behavior, I feel like that's not completely reversible.

nikomatsakis: I agree, actually, I think changing a lint can have a very big impact.

scottmcm: yeah, 2nd is not strong enough.

joshtriplett: I'm going to drop the lang nominated tag and start an FCP.

*checkboxes now available*

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503

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

### "`#[track_caller]` erroneously points to macro call" rust#95152

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

### "Implement pointee metadata unsizing via a TypedMetadata<T\> container" rust#97052

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

### "Loosen shadowing check inside macro contexts (attempt 2)." rust#100453

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