Allow #[pin_project(!Unpin)] to `impl !Unpin`

[ssbr]

Suppose I have the following trait definition:

trait Trait {}
impl<T: Unpin> Trait for T {}

And I use it from another crate. Then this will not have overlapping impls:

struct Struct;
impl !Unpin for Struct {}
impl Trait for Struct {}

... because Rust understands that this doesn't overlap with the blanket impl in the trait definition. But this will not work:

struct Struct2(std::marker::PhantomPinned);
impl Trait for Struct {}

Nor will any other trick that isn't a straight up impl !Unpin.

Right now, if you use pin_project with a struct, you cannot impl !Unpin for that struct, which means that struct cannot implement Trait if it does not fall under the blanket impl. Would you accept a PR adding some way to impl !Unpin? For example, something like:

// creates an `impl !Unpin`, instead of an impl Unpin conditional on the impossible
#[pin_project(!Unpin=negative_impls)]
struct Struct { ... }

( In particular, I want this for https://github.com/google/crubit/blob/main/rs_bindings_from_cc/support/ctor.rs )

[taiki-e]

I'm not opposed to supporting unstable features under an explicit option.

However, negative_impls breaks pin_project's soundness (#340), so I prefer not to provide features that require negative_impls to be enabled until that problem is fixed.

[taiki-e]

#340 has been fixed so I mark this as no longer blocked.

That said, we now know that there is a way to emulate full native_impls on stable Rust (#340 (comment)), so we can also consider using that in #[pin_project(!Unpin)]. (Aside from whether we want to rely on it, since it sounds like a compiler bug)

[danielhenrymantilla]

Btw, the same trick observed in #340 would allow to perform a negative impl here, without needing an unstable feature (although an opt-in for the proper unstable feature usage would probably be desirable).

See https://docs.rs/negative for a PoC