Only shown relevant type params in E0283 label#90709
Conversation
|
r? @nagisa (rust-highfive has picked a reviewer for you, use r? to override) |
nagisa
left a comment
There was a problem hiding this comment.
A test where multiple parameters are not inferred would be nice too. Of particular interest would be a function that returns an array where both the value type and const length could not be inferred.
compiler/rustc_infer/src/infer/error_reporting/need_type_info.rs
Outdated
Show resolved
Hide resolved
compiler/rustc_infer/src/infer/error_reporting/need_type_info.rs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I'm slightly worried about the handling of ty::Errors that come in as part of the input as they become indistinguishable from those that are produced by this TypeFolder, but its probably fine…
There was a problem hiding this comment.
I would think that any naturally ocurring ty::Error should be displayed as _ anyways. Worst case scenario on the next wave of errors the user will be told to fill it in.
compiler/rustc_infer/src/infer/error_reporting/need_type_info.rs
Outdated
Show resolved
Hide resolved
compiler/rustc_infer/src/infer/error_reporting/need_type_info.rs
Outdated
Show resolved
Hide resolved
5c807b1 to
0f668ff
Compare
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Outstanding: changing this to also use _ for the first two params here. Can be done as a follow up.
|
☔ The latest upstream changes (presumably #90352) made this pull request unmergeable. Please resolve the merge conflicts. |
3ce5b5e to
e462819
Compare
|
@bors r+ |
|
@bors r=nagisa The bot seems to have been taking a nap. |
|
📌 Commit e462819 has been approved by |
…=nagisa Only shown relevant type params in E0283 label When we point at a binding to suggest giving it a type, erase all the type for ADTs that have been resolved, leaving only the ones that could not be inferred. For small shallow types this is not a problem, but for big nested types with lots of params, this can otherwise cause a lot of unnecessary visual output.
…=nagisa Only shown relevant type params in E0283 label When we point at a binding to suggest giving it a type, erase all the type for ADTs that have been resolved, leaving only the ones that could not be inferred. For small shallow types this is not a problem, but for big nested types with lots of params, this can otherwise cause a lot of unnecessary visual output.
|
Failed in a rollup, maybe just needs a small rebase and fixup..? |
e462819 to
b988151
Compare
|
@bors r=nagisa |
|
⌛ Testing commit b988151 with merge 21f0c7aafcdf0c6622a2f03305a57efcfb2cbf79... |
|
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #91539) made this pull request unmergeable. Please resolve the merge conflicts. |
When we point at a binding to suggest giving it a type, erase all the type for ADTs that have been resolved, leaving only the ones that could not be inferred. For small shallow types this is not a problem, but for big nested types with lots of params, this can otherwise cause a lot of unnecessary visual output.
When the value of a const param isn't inferred, replace it with the param name from the definition.
b988151 to
7271d1f
Compare
|
@bors r=nagisa |
|
📌 Commit 7271d1f has been approved by |
…=nagisa Only shown relevant type params in E0283 label When we point at a binding to suggest giving it a type, erase all the type for ADTs that have been resolved, leaving only the ones that could not be inferred. For small shallow types this is not a problem, but for big nested types with lots of params, this can otherwise cause a lot of unnecessary visual output.
…=nagisa Only shown relevant type params in E0283 label When we point at a binding to suggest giving it a type, erase all the type for ADTs that have been resolved, leaving only the ones that could not be inferred. For small shallow types this is not a problem, but for big nested types with lots of params, this can otherwise cause a lot of unnecessary visual output.
…=nagisa Only shown relevant type params in E0283 label When we point at a binding to suggest giving it a type, erase all the type for ADTs that have been resolved, leaving only the ones that could not be inferred. For small shallow types this is not a problem, but for big nested types with lots of params, this can otherwise cause a lot of unnecessary visual output.
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#90709 (Only shown relevant type params in E0283 label) - rust-lang#91551 (Allow for failure of subst_normalize_erasing_regions in const_eval) - rust-lang#91570 (Evaluate inline const pat early and report error if too generic) - rust-lang#91571 (Remove unneeded access to pretty printer's `s` field in favor of deref) - rust-lang#91610 (Link to rustdoc_json_types docs instead of rustdoc-json RFC) - rust-lang#91619 (Update cargo) - rust-lang#91630 (Add missing whitespace before disabled HTML attribute) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…=nagisa Only shown relevant type params in E0283 label When we point at a binding to suggest giving it a type, erase all the type for ADTs that have been resolved, leaving only the ones that could not be inferred. For small shallow types this is not a problem, but for big nested types with lots of params, this can otherwise cause a lot of unnecessary visual output.
When we point at a binding to suggest giving it a type, erase all the
type for ADTs that have been resolved, leaving only the ones that could
not be inferred. For small shallow types this is not a problem, but for
big nested types with lots of params, this can otherwise cause a lot of
unnecessary visual output.