Forbid manual Unpin impls for structurally pinned types

[frank-king]

Part of pin_ergonomics. It forbids to impl Unpin for T where T is an ADT marked with #[pin_v2].

[rustbot]

r? @madsmtm

rustbot has assigned @madsmtm.
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

[madsmtm]

The change itself seems simple, but I'd prefer to have someone from t-types review it.
r? types

If no-one there feels like they have the capacity, feel free to assign it back to me.

[bors]

☔ The latest upstream changes (presumably #146348) made this pull request unmergeable. Please resolve the merge conflicts.

[BoxyUwU]

r? BoxyUwU

[BoxyUwU]

What's the reason for wanting to forbid such impls? Is it just because it's probably pointless to have pin_v2 on an Unpin type, or is there some soundness concern here?

[frank-king]

It is for soundness concern.

For a type T annotated with #[pin_v2], it is allowed to project Pin<&mut T> to its field Pin<&mut U> safely (even if U: !Unpin). If T is allowed to impl Unpin manually, then &mut U could be obtained from &mut T that dereferenced by Pin<&mut T>, which breaks the safety contract of Pin<&mut U> for U: !Unpin.

[BoxyUwU]

If its soundness critical, I would add tests for impls of unpin for type aliases for adts marked pin_v2, e.g. impl Unpin for <Foo as Identity>::Assoc impl Unpin for Identity<Foo> (with lazy_type_alias feature enabled) and impl Unpin for TAIT (where TAIT is Foo).

rn your logic implicitly ignores all the cases where the self type is a non-adt 🤔 which I think is fine because we enforce that impls of Unpin are always for ADTs? But having tests is good :) It would probably also be good to explicitly match on the TyKind and in non Adt cases (which we expect to be unreachable) delay a bug maybe 🤔 that way you don't get unsoundness here if it goes wrong just an ICE

[BoxyUwU]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[frank-king]

@rustbot ready