---
tags: weekly-meeting
---

# 2023-05-08 triage meeting

## Nominated issues

### [A Pin unsoundness involving an `impl DerefMut for Pin<&dyn LocalTrait>`](https://github.com/rust-lang/rust/issues/85099)

Background: https://github.com/rust-lang/rust/issues/85099#issuecomment-835788350

@pnkfelix said...
>Visiting for P-high 2023 Q1 review.
>
>I'd like to hear what T-types has to say about @withoutboats 's suggestion in the previous comment that we should, at minimum, add a negative impl of `DerefMut` for `Pin<P>`, or maybe even going so far as to exclude `DerefMut` from `#[fundamental]` entirely.
>
>(It sounds like something we might need to tie to the 2024 edition? Or maybe we justify it as a soundness fix.)
>

### [PhantomData: fix documentation wrt interaction with dropck](https://github.com/rust-lang/rust/pull/103413)

FCP only to confirm that the updated documentation is correct?

### [Account for late-bound lifetimes in generics](https://github.com/rust-lang/rust/pull/103448) and [Make late_bound_lifetime_arguments a hard error](https://github.com/rust-lang/rust/pull/108782)

OP:
Currently, functions have two kinds of lifetime parameters: early-bound (which appear in where clauses or do not appear in inputs), and late-bound. Late-bound lifetimes do not appear in generics, they only exist inside the function signature. For instance, take this code:

fn foo<'a, 'b, T>() where T: 'b {}
       ^^  ^^
     late  early

Then we have `generics_of(foo) = ['b, T]` and `fn_sig(foo::<'b, T>) = for<'a> fn()`.

This PR proposes to make all lifetimes on functions early-bound.

@BoxyUwU also said:
>The intention long term is to make all lifetimes late bound, I would have thought this would mean we should be removing this lint not making it a hard error since otherwise you would be unable to ever turbofish lifetime args. not to mention we may end up with late bound type and const parameters, not being able to turbofish any generic arguments seems not great.

Comment from Jack: We should discuss how we expect this to work long term. I think we likely expect no distinction between early and late bound lifetimes.

### [Allow impl on projection](https://github.com/rust-lang/rust/pull/107263)

This comes from experimentation to lazily normalize type aliases and add them as a `TyAlias` variant (https://github.com/rust-lang/rust/pull/97974 and https://github.com/rust-lang/rust/pull/103985).

Allows

pub trait Identity {
    type Identity: ?Sized;
}

impl<T: ?Sized> Identity for T {
    type Identity = Self;
}

pub struct I8<const F: i8>;

impl <I8<{i8::MIN}> as Identity>::Identity {
    pub fn foo(&self) {}
}

Comment from Jack:
Do we *technically* need this? Or could we special-case this for only "projections" coming from type aliases?

### [Erase late bound regions for dropped instances](https://github.com/rust-lang/rust/pull/107936)

Comment from Jack: This PR is obviously wrong (see below), but we should think about how to solve this correctly.

This currently fails to compile:

pub struct Wrapper(fn(val: &()));

impl fmt::Debug for Wrapper {
    fn fmt<'a>(&'a self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        f.debug_tuple("Wrapper").field(&self.0 as &fn(&'a ())).finish() // <- because of this
    }
}

fn useful(_: &()) {
}

fn main() {
    println!("{:?}", Wrapper(useful));
}

This PR erases late-bound regions when creating a `ty::Instance<'tcx>`.

@BoxyUwU said:
>This PR is incorrect as is:
>Erasing late bound regions is wrong, for<'a> fn(&'a ()) and fn(&'static ()) are different types not just from lifetimes but also to hir typeck and and TypeId. it is possible to implement the same trait for both types and have differing behaviour. In this specific case of fn ptrs they have no drop glue so its not observable

>A targetted fix just for drop in place of fn ptrs is not enough, this problem is not restricted to fn ptrs or drop in place. From looking at rustc_codegen_ssa for a bit (all day 😭) this is a problem for all cases where we have mir like _7 = _8 and typeof(_8) is a supertype of typeof(_7) rather than equal to it. If we then unsize _7 we will create a vtable as if it had _8's type which is exploitable to create unsoundness (which is demonstrated in the original issue now)

### [Normalize obligations before matching them against a candidate](https://github.com/rust-lang/rust/pull/109115)

Just a missed normalization?

@aliemjay asks:
>Doesn't this have the same problems as @BoxyUwU's attempt at deferred projection equality? particularly the type enum regression.

### [stop adding outlives requirements to dropck for [T; 0]](https://github.com/rust-lang/rust/issues/110288)

Some concern here about const generics.

A decent summary by @lcnr: https://github.com/rust-lang/rust/issues/110288#issuecomment-1517872777

## Types FCPs

### [Tracking issue for RFC 2515, "Permit impl Trait in type aliases"](https://github.com/rust-lang/rust/issues/63063)

Not a types FCP, but read if interested

### [PhantomData: fix documentation wrt interaction with dropck](https://github.com/rust-lang/rust/pull/103413)

(Discussed above)

### [Resolve inherent associated functions & constants defined on function pointer types](https://github.com/rust-lang/rust/pull/108347)

Question: Consistency to allow incoherent impls on fn ptrs, or require impls using `FnPtr` trait?

See https://github.com/rust-lang/rust/issues/108270

If we don't want to allow incoherent impls on fn ptrs, then we should error for the impl here: https://github.com/rust-lang/rust/issues/108270

### [Make typeck aware of uninhabited types](https://github.com/rust-lang/rust/pull/108993)

This certainly is a *nice* change, but do we want to do this *now*? (As opposed to waiting until we can flesh this out in a-mir-formality)?

### [do not allow inference in predicate_must_hold (alternative approach)](https://github.com/rust-lang/rust/pull/110100)

See summary by @compiler-errors in https://github.com/rust-lang/rust/pull/110100#issuecomment-1507562924

This basically weakens our inference a little, with only a single crater regression.

### [stop adding outlives requirements to dropck for `[T; 0]`](https://github.com/rust-lang/rust/issues/110288)

(Discussed above)