Show type parameter name and definition in type mismatch error messages #66014
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @davidtwco (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
|
Obviously I've failed to put correct @estebank can you reviews this please. @davidtwco sorry for the false alarm :) |
|
r? @estebank |
|
☔ The latest upstream changes (presumably #66021) made this pull request unmergeable. Please resolve the merge conflicts. |
Part of rust-lang#47319. This just adds type parameter name to type mismatch error message, so e.g. the following: ``` expected enum `std::option::Option`, found type parameter ``` becomes ``` expected enum `std::option::Option`, found type parameter `T` ```
Fixes rust-lang#47319. Shows the type parameter definition(s) on type mismatch errors so the context is clearer. Pretty much changes the following: ``` LL | bar1(t); | ^ | | | expected enum `std::option::Option`, found type parameter `T` ``` into: ``` LL | fn foo1<T>(t: T) { | - this type parameter LL | bar1(t); | ^ | | | expected enum `std::option::Option`, found type parameter `T` ```
Update the tests to reflect changes to how type mismatch errors are reported (two previous commits).
Type parameters are referenced in the error message after the previous few commits (using span label). But when the main error message already references the very same type parameter it becomes clumsy. Do not show the additional label in this case as per code review comment by @estebank. Also this contains a small style fix.
dkadashev
force-pushed
the
47319-type-param-def-location
branch
from
972664f
to
774e60b
Compare
|
@bors r+ |
|
📌 Commit 774e60b has been approved by |
bors
added
S-waiting-on-bors
…tion, r=estebank Show type parameter name and definition in type mismatch error messages Fixes rust-lang#47319 r? estebank
…tion, r=estebank Show type parameter name and definition in type mismatch error messages Fixes rust-lang#47319 r? estebank
Rollup of 11 pull requests Successful merges: - #65892 (Remove `PartialEq` and `Eq` from the `SpecialDerives`.) - #66014 (Show type parameter name and definition in type mismatch error messages ) - #66027 (Move has_panic_handler to query) - #66054 (syntax: Avoid span arithmetic for delimiter tokens) - #66068 (use silent emitter for rustdoc highlighting pass) - #66081 (let caller of check_ptr_access_align control the error message) - #66093 (Do not ICE with a precision flag in formatting str and no format arguments) - #66098 (Detect `::` -> `:` typo when involving turbofish) - #66101 (Tweak type mismatch caused by break on tail expr) - #66106 (Fix typo in explanation of `E0080`) - #66115 (rustc: remove "GlobalMetaData" dead code from hir::map::definitions.) Failed merges: r? @ghost
| @@ -5,7 +5,9 @@ LL | fn foo<A: Debug>(&self, a: &A, b: &impl Debug); | |||
| | -- type in trait | |||
| ... | |||
| LL | fn foo<B: Debug>(&self, a: &impl Debug, b: &B) { } | |||
| | ^^^^^^^^^^^ expected type parameter, found a different type parameter | |||
| | - ^^^^^^^^^^^ expected type parameter `B`, found type parameter `impl Debug` | |||
There was a problem hiding this comment.
Calling this "type parameter impl Debug" is a little confusing. What about "opaque type impl Debug", or something similar instead?
There was a problem hiding this comment.
That would be reasonable. This output is just a consequence of opaque types being represented as type parameters and having to proactively account for them. Personally I would love to split them into two to avoid a lot of special casing we end up doing, like the one we would have to do here.
Fixes #47319
r? estebank