Always implement Unpin for PhantomData

[tomaka]

This PR makes it so that PhantomData<T> implements Unpin no matter what T is.

Interestingly enough, the situation is the same for Send and Sync. PhantomData only implements Send if T: Send and Sync if T: Sync. I don't know whether that's on purpose, or if it's an overlook.

[rust-highfive]

r? @aidanhs

(rust_highfive has picked a reviewer for you, use r? to override)

[seanmonstar]

It's on purpose for Send and Sync. A common pattern is PhantomData<Rc<()>> to ensure a type is !Send.

In my opinion, it's probably better to keep the same with Unpin, in case someone were to expect the same rules.

[Mark-Simulacrum]

r? @cramertj perhaps? Not sure who the "owners" in this space are today.

[nagisa]

It's on purpose for Send and Sync.

Is it? Where was that ratified? Do we have tests to ensure this continues to hold?

A common pattern is PhantomData<Rc<()>> to ensure a type is !Send.

Seems like an invalid pattern to me, at least in vacuum. It is not semver breaking to add additional impls for PhantomData because it is Send, Sync and Unpin ∀T (by the virtue of being a ZST without any attached semantics) but doing so would potentially make unsafe code using this pattern unsound.

That being said, if it does have a widespread usage and this behaviour is not yet ratified in e.g. documentation, we may want to ratify it sooner rather than later.

[seanmonstar]

Here's the first one I found in libstd:

rust/src/libstd/sys/unix/args.rs

Line 25 in fe499a7

_dont_send_or_sync_me: PhantomData<*mut ()>,

[tomaka]

It's worth mentioning the PhantomPinned type whose purpose is to not implement Unpin.
People are expected to use PhantomPinned rather than PhantomData<SomethingUnpin>.

[nagisa]

Here's the first one I found in libstd

libstd is not a typical codebase, because it can assume significantly more than any other rust codebase and use all the unstable details it wants.

Either way, I think we either document/ratify PhantomData<T> to behave just like T for the purposes of propagating autotraits (so the current behaviour for Send, Sync and Unpin and we do not land this PR) or we go ahead and implement Send, Sync, Unpin and all similar auto traits for PhandomData<T> by considering behaviour of the type regardless of its generic.

[Dylan-DPC-zz]

@tomaka @aidanhs @rust-lang/libs any updates?

[tomaka]

I guess we can close as wont-fix.