Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing error message with type unification of impl Traits #63167

Open
adamlesinski opened this issue Jul 31, 2019 · 5 comments

Comments

@adamlesinski
Copy link

commented Jul 31, 2019

It took a colleague explaining to me that the return type of a function returning an impl Trait is unique across function definitions for me to understand the following error: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4ceda076c82b01ea279e8864518ab5d9

This becomes more important for async/await because of the automatic translation of async fn foo() -> i64 to fn foo() -> impl Future<Output = i64>: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=b109446a49d22a632e395aacaa2cb8ff

In the first case, can the error maybe call out that the opaque types are different due to how the compiler treats them? And for the second error, can this be called out in async-specific language. That error happens when you forget to call .await.

@Centril

This comment has been minimized.

Copy link
Member

commented Jul 31, 2019

In the first case, can the error maybe call out that the opaque types are different due to how the compiler treats them?

How about?:

   = note: expected type `impl Foo` (opaque type)
              found type `impl Foo` (opaque type)

   = note: distinct uses of `impl Trait` result in different opaque types

And for the second error, can this be called out in async-specific language. That error happens when you forget to call .await.

In the second case I think we should suggest that the .awaits be moved into the branches tho this may be complicated to encode as a diagnostic.

cc @estebank

@adamlesinski

This comment has been minimized.

Copy link
Author

commented Jul 31, 2019

In the first case, can the error maybe call out that the opaque types are different due to how the compiler treats them?

How about?:

   = note: expected type `impl Foo` (opaque type)
              found type `impl Foo` (opaque type)

   = note: distinct uses of `impl Trait` result in different opaque types

This is perfect! It's the exact hint I needed to understand the problem :)

And for the second error, can this be called out in async-specific language. That error happens when you forget to call .await.

In the second case I think we should suggest that the .awaits be moved into the branches tho this may be complicated to encode as a diagnostic.

cc @estebank

Agreed, this is definitely a bit trickier. I'll defer to you on the best way to message this error.

@Arnavion

This comment has been minimized.

Copy link

commented Jul 31, 2019

In the first case, can the error maybe call out that the opaque types are different due to how the compiler treats them?

Doesn't it already does so?

17 | |         two()
   | |         ^^^^^ expected opaque type, found a different opaque type
@estebank

This comment has been minimized.

Copy link
Contributor

commented Jul 31, 2019

@Centril what is the correct nomenclature for a regular, non-opaque type that we could use here? With that we could say something like "consider materializing to an explicit type in both branches from the opaque type" and "for impl std::future::Future you can .await them on both branches to unify the types". This is rough wording, but gives an idea of what I'm thinking.

@Centril

This comment has been minimized.

Copy link
Member

commented Jul 31, 2019

@estebank The antonym of opaque is transparent but I'm not sure that is situationally good to use here. ISTM you'd want to say something like "use an enum with variants for both cases" (at least that's the advice I'd give in person). I'd go for a non-actionable description as a first pass at this problem and consider an improvement later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.