Enhance type inference errors involving the ? operator
#80517
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @davidtwco (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
wabain
commented
Dec 30, 2020
| @@ -448,6 +544,13 @@ impl<'a, 'tcx> InferCtxt<'a, 'tcx> { | |||
| error_code, | |||
| ); | |||
|
|
|||
| let use_diag = local_visitor.found_use_diagnostic.as_ref(); | |||
| if let Some(use_diag) = use_diag { | |||
| if use_diag.applies_to(err_span) { | |||
There was a problem hiding this comment.
There are various cases where we shrink the span used in the error message after the HIR traversal, so this check makes sure that the note still makes sense with the chosen span.
wabain
commented
Dec 30, 2020
src/test/ui/inference/cannot-infer-async-enabled-impl-trait-bindings.stderr
Outdated
Show resolved
Hide resolved
davidtwco
approved these changes
Dec 31, 2020
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
src/test/ui/inference/cannot-infer-async-enabled-impl-trait-bindings.stderr
Outdated
Show resolved
Hide resolved
davidtwco
added
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
wabain
force-pushed
the
issue-77880-infer-error-try-conversion-msg
branch
from
e92e29a to
d46c3e3
Compare
|
Merge conflicts and suggested changes are resolved |
davidtwco
approved these changes
Jan 11, 2021
|
@bors r+ Thanks! |
|
📌 Commit d46c3e3 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch adds a special-cased note on type inference errors when the error span points to a
?return. It also makes the primary label for such errors "cannot infer type of?error" in cases where before we would have only said "cannot infer type".One beneficiary of this change is async blocks, where we can't explicitly annotate the return type and so may not generate any other help (#77880); this lets us at least print the error type we're converting from and anything we know about the type we can't fully infer. More generally, it signposts that an implicit conversion is happening that may have impeded type inference the user was expecting. We already do something similar for mismatched type errors.
The check for a relevant
?operator is built into the existing HIR traversal which looks for places that could be annotated to resolve the error. That means we could identify?uses anywhere in the function that output the type we can't infer, but this patch just sticks to adding the note if the primary span given for the error has the operator; if there are other expressions where the type occurs and one of them is selected for the error instead, it's more likely that the?operator's implicit conversion isn't the sole cause of the inference failure and that adding an additional diagnostic would just be noise. I added a ui test for one such case.The data about the
?conversion is passed around in aUseDiagnosticenum that in theory could be used to add more of this kind of note in the future. It was also just easier to pass around than something with a more specific name. There are some follow-up refactoring commits for the code that generates the error label, which was already pretty involved and made a bit more complicated by this change.