Test that you can't implement Unpin for a compiler-generated future using TAIT

[Darksonn]

I came up with this while trying to break pinning. Seems like a good idea to have a test that this doesn't change.

r? @RalfJung

[rustbot]

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

[RalfJung]

That's an odd error, the type is defined in the current trait.

Is there an attribute we can add to this impl so that it is allowed to unfold the opaque? Cc @oli-obk @lcnr

View changes since the review

[Darksonn]

All compiler-generated futures should probably come with an implicit impl !Unpin so that this doesn't rely on orphan rules.

[lcnr]

opaque types are always considered to be an unknown type. You cannot get their underlying type during coherence (and we don't allow auto trait leakage during coherence either)

we may want to improve the diagnostics here, but it is very much intended that impls can't look into opaque types.

We could in theory add the functionality to reveal opaque types during coherence, and at this point either manually implement !Unpin for couroutines, forbid impls on coroutines by treating them as foreign, or sth else. But for now that doesn't matter as you cannot reveal opaque types during coherence checking at all