Update UnsafeUnpin impls involving extern types.

[zachs18]

UnsafeUnpin tracking issue: #125735

Relaxes from T: ?Sized (i.e. T: MetaSized) to T: PointeeSized for the UnsafeUnpin impls for pointers, references, and PhantomData<T>, and for the negative UnsafeUnpin impl for UnsafePinned<T>. (Compare to the impls for Freeze on lines 911-921.)

Both UnsafeUnpin and extern types (the only way to have a !MetaSized type) are unstable, so this should have no effect on stable code.

Also updates the marker_impls macro docs to use PointeeSized bound, as most uses of the macro now do.

Concretely, this change means that the following types will newly implement UnsafeUnpin:

• pointers and references to T where T is an extern type
• PhantomData<T> where T is an extern type
• either of the above where T is a struct or tuple with extern type tail

Additionally, the negative UnsafeUnpin impl for UnsafePinned<T> is also relaxed to T: PointeeSized to align with the analogous negative Freeze impl for UnsafeCell<T>, even though both structs have T: ?Sized in their declaration (which probably should be relaxed, but that is a separate issue), so this part of the change doesn't actually do anything currently, but if UnsafeCell and UnsafePinned are later relaxed to T: PointeeSized, then the negative impl will apply to the newly possible instantiations. Also cc #152645 that these impls compile at all.

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @scottmcm, libs
• @scottmcm, libs expanded to 8 candidates
• Random selection from Mark-Simulacrum, jhpratt, joboet, scottmcm

[jhpratt]

I'm unfamiliar with the Sized hierarchy proposal

@rustbot reroll

[Mark-Simulacrum]

I see in the tracking issue for Sized hierarchy (#144404) this note:

There is a default MetaSized supertrait which prevents traits from being implemented on extern types unless this was considered by the definition of the trait.

This implies to me that either this isn't effective or there's something special about UnsafeUnpin's trait (maybe the fact it's auto) that invalidates that line?

Am I correctly interpreting that PointeeSized is the 'lowest rung' of the ladder currently proposed? It's confusing to me that the RFC's current text (https://github.com/davidtwco/rfcs/blob/sized-hierarchy/text/3729-sized-hierarchy.md#guide-level-explanation) has Sized, MetaSized, and Pointee, but doesn't seem to have a PointeeSized (it makes no mention of PointeeSized at all!).

cc @davidtwco

[zachs18]

I see in the tracking issue for Sized hierarchy (#144404) this note:

There is a default MetaSized supertrait which prevents traits from being implemented on extern types unless this was considered by the definition of the trait.

This implies to me that either this isn't effective or there's something special about UnsafeUnpin's trait (maybe the fact it's auto) that invalidates that line?

Yes, auto traits do not have a MetaSized default bound (playground). IIUC, that is intentional because the "normal" way to opt-out of the default MetaSized bound (by adding a : PointeeSized supertrait bound) doesn't work for auto traits since supertrait bounds are rejected for auto traits¹.

Either way, this would not affect the impls for PhantomData<T>, references, or pointers, as those are always Sized regardless of T.

This would be important for the UnsafePinned<T> negative impl... if UnsafePinned<T> allowed T: PointeeSized, but it doesn't, and the fact that this changed impl compiles at all is #152645 which also affects the existing UnsafeCell<T> negative Freeze impl. I could split the UnsafePinned<T> change into a separate PR if that seems better, since the pointer/reference/PhantomData changes shouldn't be affected by the question of #152645 .

Am I correctly interpreting that PointeeSized is the 'lowest rung' of the ladder currently proposed? It's confusing to me that the RFC's current text (https://github.com/davidtwco/rfcs/blob/sized-hierarchy/text/3729-sized-hierarchy.md#guide-level-explanation) has Sized, MetaSized, and Pointee, but doesn't seem to have a PointeeSized (it makes no mention of PointeeSized at all!).

Yes, my understanding is that the name PointeeSized was chosen for the unstable impl instead of Pointee to not cause confusion/conflicts with the existing std::ptr::Pointee, ("PointeeSized is a different name from the RFC just to make it more obvious that it is different from std::ptr::Pointee but all the names are yet to be bikeshed anyway." from the initial PR).

---

Footnotes

1. https://github.com/rust-lang/rust/blob/main/compiler/rustc_hir_analysis/src/hir_ty_lowering/bounds.rs#L188 says that the reasoning for auto traits not having a default : MetaSized bound is "Don't add default sizedness supertraits to auto traits because it isn't possible to relax an automatically added supertrait on the defn itself". I at first thought "but doesn't trait Foo: PointeeSized {} do that? Why is it different for auto traits?" but then I tried it and got error[E0568]: auto traits cannot have super traits or lifetime bounds, which is an AST pass error, so might be more difficult to change for specifically PointeeSized due to name resolution(?). ↩

[Mark-Simulacrum]

@bors r+

[rust-bors]

📌 Commit ca1defc has been approved by Mark-Simulacrum

It is now in the queue for this repository.