Uh oh!
There was an error while loading. Please reload this page.
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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Centril
commented
Nov 16, 2019
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
bbab797CompareUh oh!
There was an error while loading. Please reload this page.
4ebcc3f to
6678094Compare
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
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.
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.
6678094 to
3efc92aCompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This comment has been minimized.
This comment has been minimized.
0c03db6 to
33ae322CompareAddressed the comments and rebased. |
Centril
commented
Jan 9, 2020
@bors r+ |
bors
commented
Jan 9, 2020
📌 Commit 33ae322 has been approved by |
…e-types, r=Centril Point at opaque and closure type definitions in type errors Fixesrust-lang#57266, fixesrust-lang#67117.
…e-types, r=Centril Point at opaque and closure type definitions in type errors Fixesrust-lang#57266, fixesrust-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.