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

# T-lang meeting agenda

* Meeting date: 2022-09-13

## Attendance

* Team members: nikomatsakis, pnkfelix
* Others: dtolnay

## Meeting roles

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

## Scheduled meetings

Taking September off:

* [lang-team#171](https://github.com/rust-lang/lang-team/issues/171) on the 28th

## Announcements or custom items

### Async functions in traits stakeholders meeting

Went over the proposed async functions in traits design, reading this document

[Async functions in traits](https://hackmd.io/9AH8Zr9ESMmur0n6Nix96w?view)

...also various PRs landed, including some preliminary support for `impl Trait in Trait`.

### Draft blog post about unsafe

pnkfelix: I put up a draft blog post about transmuting between integers and pointers and how it's UB in const eval. miri only checked it lazilly before, but now we're catching it earlier. Longer term I want to attack runtime transmutes between integers/pointers and now I want to attack every foundation that they're built on.

nikomatsakis: :scream:

pnkfelix: It's not that bad, but I really want to ask questions like, do we really need to support "one past the end pointers", could that be UB? So much of what we're talking about is built on what seem to be shaky foundations. Ralf's argument is very good. If you accept the premises, then you arrive at his conclusion. And maybe it's right. But if it is, we should be doing a lot to lint against any instance of such.

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

### "add `#[never_call]` attribute" lang-team#170

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

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

nikomatsakis to review.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "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:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * rust-reference (https://github.com/rust-lang/rust/issues/93333#issuecomment-1217057760)
>
> 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

### "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:
>
> * early-storage-dead-of-stack-value (https://github.com/rust-lang/rust/issues/99104#issuecomment-1241026856)
> * 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

nikomatsakis: cancelled

### "Stop using `Reveal::All` before borrowck" rust#101478

- **Link:** https://github.com/rust-lang/rust/pull/101478
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/101478#issuecomment-1243731912):
> Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @compiler-errors
> * [ ] @cramertj
> * [ ] @jackh726
> * [ ] @joshtriplett
> * [x] @lcnr
> * [ ] @nikomatsakis
> * [x] @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/101478#issuecomment-1243731843):
> This pull request changes the compiler to stop using `Reveal::All` at any point until `borrowck` is completed. Using `Reveal::All` means that it is possible to inspect
> - the underlying type of opaque types
> - the value of a "defaulted" associated item (requires `feature(specialization)`)
>
> **This breaks existing stable code**
>
> This mostly impacts const evaluation in the type system, i.e. const generics. We stop leaking the type of opaque types, making them pretty much unusable in constants in the type system. For examples, see the added tests in `ui/impl-trait/in-ctfe`.
>
> This is desirable as observing the concrete type of opaque types should not be possible during typeck, and more importantly, trying to reveal the concrete type can cause cycles, as seen in `ui/type-alias-impl-trait/in-where-clauses.rs`. Even worse, current work on implied bounds will move implied bounds into the `param_env`, making them less special and unblocking future work. With this work, `fn foo<'a>() -> &'a impl Send` adds the implied bound `impl Send: 'a` to `foo`, causing a cycle if ctfe is used while type-checking `foo`.
>
> It also changes `transmute` checking to not use `Reveal::All`. While we could move `transmute` checking out of the `typeck` query, using `Reveal::All` also feels wrong here. See `ui/impl-trait/transmute` for this. Keeping `Reveal::All` for `transmute` checking may also make it harder to properly integrate the size check in the type system in the future.
>
> A crater run found 2 regressions:
>
> ## [`mijit`](https://github.com/apt1002/mijit/)
>
> Transmute in a test between an opaque type and the underlying concrete type. Opened PR fixing this in https://github.com/apt1002/mijit/pull/51.
>
> ## [`name-it`](https://github.com/GoldsteinE/name-it)
>
> This crate cannot really be fixed, as it [fundamentally requires this pattern](https://github.com/GoldsteinE/name-it/blob/47544a062a950279fc49c8c3832b7b8e13febb8d/src/lib.rs#L104-L114):
> ```rust
> use std::mem;
> fn returns_opaque() -> impl Sized {
> 0u8
> }
>
> struct NamedOpaqueType {
> data: [mem::MaybeUninit<u8>; size_of_fut(returns_opaque)]
> }
>
> const fn size_of_fut<FUT>(x: fn() -> FUT) -> usize {
> mem::size_of::<FUT>()
> }
> ```
> For this to work, we would be required to add the notion of "opaque values" to CTFE. I don't know how complex of a change this would be, but expect it to not be trivial. While really unfortunate, I propose to accept the breakage of this crate. Hopefully the crate will be fully obsolete due to stable TAIT in the near future.
>
> @rfcbot fcp merge

nikomatsakis: we were exposing more information than we ought to because we were exposing hidden types. Open question as to whether to handle `size_of` an impl Trait. This is already exposing information that's quite unstable.

pnkfelix: lang or types.

nikomatsakis: feels to me like the intersection of the two.

simulacrum: it is surprising that at typeck time... I'd expect it to always work or not.

nikomatsakis: seems like we need to follow-up on this, as I don't quite understand how the special case would work.

## Active FCPs
### "RFC: Statics in patterns" rfcs#3305

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

### "Rust Style Team" rfcs#3309

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

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

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

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

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

### "Commit to safety rules for dyn trait upcasting" rust#101336

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

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

## Nominated RFCs, PRs and issues discussed this meeting

### "Commit to safety rules for dyn trait upcasting" rust#101336

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

Unnominated.

### "Simple postfix macros" rfcs#2442

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

last time we discussed and there was discussion between josh/scott, but they'r enot here.

### "RFC: Statics in patterns" rfcs#3305

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

### "Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503

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

This needs a summary. Write-up and relabled.

### "Tracking issue for `std::hint::black_box`" rust#64102

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

No new content, removing nomination.

### "Warn when casting an enum that is fieldless but not C-like" rust#92700

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

> Discussed in the lang team meeting today. Based on the age of this PR, and the fact that we've had several design meetings on this but never come to any clear conclusions, we're going to close this PR for now. We're still blocked on a proposal for a consistent set of rules, essentially. We agree it would be nice to see this resolved! (cc @jswrenn)

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

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

pnkfelix, from thread: (This is specifically blocked on me reading over the proposal and the comment thread to better understand the problem being solved and the merits of the proposed solution.)

### "impl DispatchFromDyn for Cell and UnsafeCell" rust#97373

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

> From the PR: Implementing DispatchFromDyn enables a type to be used as a self type, if that type also implements Deref. Since Cell and UnsafeCell don't implement Deref actually making use of these changes requires a custom wrapper type and nighty features (as is shown in the test).

Net effect of this is that you can write a type like `CellPtr`:

struct CellPtr<'a, T: ?Sized>(Cell<&'a T>);

impl<'a, T: ?Sized> Deref for CellPtr<'a, T> {
    type Target = T;

    fn deref(&self) -> &T {
        self.0.get()
    }
}

impl<'a, T: Unsize<U> + ?Sized, U: ?Sized> CoerceUnsized<CellPtr<'a, U>> for CellPtr<'a, T> {}
impl<'a, T: Unsize<U> + ?Sized, U: ?Sized> DispatchFromDyn<CellPtr<'a, U>> for CellPtr<'a, T> {}

Conclusion: this has no stable impact, but is it a direction we want to go?

Rationable: they're experimenting with a `Gc` type and want to be able todo stuff like this.

nikomatsakis: I like enabling experimentation, but I want some sort of comment explaining why it's here.

nikomatsakis to leave comment saying "we're in favor for but we'd like to see a comment that explains why this impl exists".

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

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

removing nomination

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

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

### "repr(transparent) could accept singleton ZST with alignment > 1." rust#100954

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

pnkfelix: "what led me to do that"

### "Document `label_break_value` in the reference" reference#1263

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

FElix to leave a comment.

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