You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Call pinned method from Trait on generic parameter #63966
= help: items from traits can only be used if the type parameter is bounded by the trait
help: the following trait defines an item `quack`, perhaps you need to restrict type parameter `Animal` with it:
|
17 | impl<Animal: Quack + Quack> Quack for Transporter<Animal> {
| ^^^^^^^^^^^^^^^
Which clearly doesn't really solve anything.
If a take off the Pin from the Traits and it's impl and just use a &self I can get the expected Quack! from inside the transporter.
The compiler suggestion surely doesn't seams right to me, but what about the Pin? Am I missing something or is there a bug too?
help: the following traits define an item `m`, perhaps you need to restrict type parameter `T` with one of them:
|
3 | fn foo<T: First::Foo + Foo>(a: T) {
| ^^^^^^^^^^^^^^^
3 | fn foo<T: Second::Bar + Foo>(a: T) {
| ^^^^^^^^^^^^^^^^
The above suggests a trait from another module with a different name
help: the following traits define an item `m`, perhaps you need to restrict type parameter `impl Bar` with one of them:
|
9 | fn bar(b: impl Bar: First::Foo + {
| ^^^^^^^^^^^^^^^^^^^^^^
9 | fn bar(b: impl Bar: Second::Bar + {
| ^^^^^^^^^^^^^^^^^^^^^^^
and the next suggestion isn't syntactically correct.
You're trying to go from a Pin<&MyType> to a Pin<&MyField>, where &MyField is a reference to a field of MyType. This is known as a pinned projection, and has additional requirements that you must meet in order for it to be sound.
<shameless-plug>You might want to take a look at the pin-project crate (disclaiminer: I'm a contributor), which makes it easy to write safe pin projections.</shameless-plug>
Activity
memoryruins commentedon Aug 28, 2019
The suggestions are strange with other self types as well, e.g. using
BoxandArcinstead ofPin.playground
1.39.0-nightly 2019-08-23 9eae1fc0ea9b00341b8fThe above suggests a trait from another module with a different name
and the next suggestion isn't syntactically correct.
Aaron1011 commentedon Aug 29, 2019
@Jonathas-Conceicao: as @memoryruins mentioned, the diagnostic suggestions are wrong in this case.
You're trying to go from a
Pin<&MyType>to aPin<&MyField>, where&MyFieldis a reference to a field ofMyType. This is known as a pinned projection, and has additional requirements that you must meet in order for it to be sound.<shameless-plug>You might want to take a look at the pin-project crate (disclaiminer: I'm a contributor), which makes it easy to write safe pin projections.</shameless-plug>
taiki-e commentedon Aug 29, 2019
The diagnostic issue seems to dup of #57994.
Jonathas-Conceicao commentedon Aug 29, 2019
@Aaron1011, thank you for the explanation and the suggestion, that does indeed solve the error.
Regarding the suggestion, it really does seams to be a duplicate, will be closing this in favor of #57994.