`__UnpinStruct` is restricting the pinned field.

[ogoffart]

Unless I misunderstand something, it seems the logic to put the field in __UnpinStruct is reversed, as it checks that the #[pin]'ed field are Unpin.

For example:

// This structure cannot be moved
struct Property {
    pin: std::marker::PhantomPinned
}

#[pin_project::pin_project]
struct Container {
    #[pin]
    xxx : Property
}

Result in this error:

error[E0277]: the trait bound `std::marker::PhantomPinned: std::marker::Unpin` is not satisfied in `__unpin_scope_Container::__UnpinStructContainer`
   |
20 | #[pin_project::pin_project]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ within `__unpin_scope_Container::__UnpinStructContainer`, the trait `std::marker::Unpin` is not implemented for `std::marker::PhantomPinned`
   |

__UnpinStruct constraints all the pin'ed types. But I believe it should be the opposite, only the types that are not pinned should satisfy Unpin.

[Aaron1011]

This logic is current. __UnpinStruct: Unpon is used as a bound for the pin-projected strict. That is, you can only treat pin projections as Unpin when all of the pinned types are also Unpin (I.e. when IRS safe to ignore the fact that they are pinned).

[taiki-e]

This error is because the Unpin implementation provided by pin_project adds a Unpin bound to a field that is known not to implement Unpin (It doesn't matter if it is explicit). This can be resolved if RFC 2056 (rust-lang/rust#48214) stabilizes.

The workaround I know is using pin_project(UnsafeUnpin) and not providing a manual UnsafeUnpin implementation. EDIT: this is wrong.

pin-project/src/lib.rs

Lines 93 to 95 in 1b0e552

	/// Note that if you specify `#[pin_project(UnsafeUnpin)]`, but do *not*
	/// provide an impl of `UnsafeUnpin`, your type will never implement [`Unpin`].
	/// This is effectly the same thing as adding a [`PhantomPinned`] to your type

However, perhaps we can provide an option to support this. (Add the PhantomPinned argument to pin_project or parse the field to automatically adjust the Unpin implementation. Personally, I prefer to pass arguments explicitly.) EDIT: Perhaps automatic detection will not actually work.

(FYI: I found this problem about two weeks ago and added two tests.)

• pin-project/tests/ui/pin_project/phantom-pinned.rs
  

  pin-project/tests/ui/pin_project/phantom-pinned.stderr

  Lines 1 to 16 in 1b0e552

  	error[E0277]: the trait bound `std::marker::PhantomPinned: std::marker::Unpin` is not satisfied in `UnpinStructFoo`
  	--> $DIR/phantom-pinned.rs:10:1
  	|
  	10 | #[pin_project]
  	| ^^^^^^^^^^^^^^ within `UnpinStructFoo`, the trait `std::marker::Unpin` is not implemented for `std::marker::PhantomPinned`
  	|
  	= help: the following implementations were found:
  	<std::marker::PhantomPinned as std::marker::Unpin>
  	= note: required because it appears within the type `Inner`
  	= note: required because it appears within the type `UnpinStructFoo`
  	= help: see issue #48214
  	= help: add `#![feature(trivial_bounds)]` to the crate attributes to enable
  	error: aborting due to previous error
  	For more information about this error, try `rustc --explain E0277`.

• pin-project/tests/ui/pin_project/trivial_bounds.rs

[ogoffart]

Actually, the full error message tells that the problem is because of rust-lang/rust#48214

This reduce the utility of this macro if it can only be done for generic types.

Maybe the pin_project macro should add a <T = ()>

[taiki-e]

@ogoffart

Maybe the pin_project macro should add a <T = ()>

I'm not sure about how does this resolve the problem - Could you explain in a little more detail?

[ogoffart]

Because having a generic in the structure work around the issue 48214.
But i actually think pin_project should not add that, because it would also then add a field which we don't want.

I don't understand how to use pin_project(UnsafeUnpin) to work this around. It just change the error to

error[E0277]: the trait bound `Container: pin_project::UnsafeUnpin` is not satisfied

[taiki-e]

I don't understand how to use pin_project(UnsafeUnpin) to work this around. It just change the error to

Oops, sorry, my comment is wrong. It doesn't work.

[taiki-e]

Hmm... I'm not sure how to support this without unstable features (I think it needs trivial_bounds or optin_builtin_traits).

cc @cramertj @RalfJung @Nemo157 Do you know a workaround for this?

[taiki-e]

EDIT: This is wrong

We can partially support this if we use the same way that we prohibit manual implementation of Drop, but it will probably not work well with struct that has generics.

struct Inner(PhantomPinned);

// #[pin_project(!Unpin)]
struct Foo {
    // #[pin]
    pinned: Inner,
}

impl Unpin for Foo {} //~ ERROR conflicting implementations of trait `test::MustNotImplUnpin` for type `test::Foo`:

// pin_project generates the following code.
trait MustNotImplUnpin {}
impl<T: Unpin> MustNotImplUnpin for T {}
impl MustNotImplUnpin for Foo {}

playground

(Replacing generics with () on impl MustNotImplUnpin will probably resolve some problems, but it won't work for generics with trait bounds.)

[ogoffart]

@taiki-e your MustNotImplUnpin does not seem to work. I get the compilation error even if i comment the impl Unpin

[taiki-e]

Oh... you are right.