-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Point at opaque and closure type definitions in type errors #66463
Point at opaque and closure type definitions in type errors #66463
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
r? @Centril |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
f0219b0
to
bbab797
Compare
4ebcc3f
to
6678094
Compare
This comment has been minimized.
This comment has been minimized.
@@ -25,6 +31,12 @@ LL | let _: i32 = Leak::leak(hide(0_i32)); | |||
error[E0308]: mismatched types | |||
--> $DIR/equality2.rs:38:10 | |||
| | |||
LL | fn hide<T: Foo>(x: T) -> impl Foo { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be a good idea to add an additional explanation when the mismatch is due to the substs of an opaque type, as the current message seems quite self-contradictory. Maybe something like:
the expected opaque type (created from foo::<u32>)
the found opaque type (created from foo::<i32>)
note: a distinct opaque type is created for each distinct set of generic arguments provided to `foo`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking about how to properly tackle this case. It is certainly confusing, but I would like to tackle it specifically and not as part of this PR. Would you mind filing a follow up ticket for this with your thoughts, @Aaron1011?
I think the wording you present is reasonable, but might require some tweaking, as the created from foo::<_>
messages might be hard to accomplish.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened #68020
6678094
to
3efc92a
Compare
This comment has been minimized.
This comment has been minimized.
0c03db6
to
33ae322
Compare
Addressed the comments and rebased. |
@bors r+ |
📌 Commit 33ae322 has been approved by |
…e-types, r=Centril Point at opaque and closure type definitions in type errors Fixes rust-lang#57266, fixes rust-lang#67117.
…e-types, r=Centril Point at opaque and closure type definitions in type errors Fixes rust-lang#57266, fixes rust-lang#67117.
Rollup of 6 pull requests Successful merges: - #66463 (Point at opaque and closure type definitions in type errors) - #67501 (Reduce special treatment for zsts) - #67820 (Parse the syntax described in RFC 2632) - #67922 (rustc_ast_lowering: misc cleanup & rustc dep reductions) - #68071 (Extend support of `_` in type parameters) - #68073 (expect `fn` after `const unsafe` / `const extern`) Failed merges: r? @ghost
Fixes #57266, fixes #67117.