-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Suggest await
in more situations where infer types are involved
#91022
Conversation
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
.. | ||
}) => { | ||
if let [.., arm_span] = &prior_arms[..] { | ||
(Some(exp), Some(found)) if ty::TyS::same_type_modulo_infer(exp, found) => { |
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.
What a strange diff. This didn't do anything except for replace same_type
with same_type_modulo_infer
and run the autoformatter, which caused an extra block to get added in.
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.
If you look at it hiding whitespace changes, the diff looks more reasonable. This happens because the line went over 100 columns, so it decided to reformat the arm into a block. It's fine.
r? @estebank |
Yes.
That would be ideal. That would send a clear signal to anyone that reaches for it in the future for something else.
I'm not sure I follow the question? If you could elaborate? r=me after moving |
Sorry, I mean other usages of |
0e39384
to
323a48d
Compare
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.
Ah! I see what you mean. I'd like to see the strange output for Range
, but I suspect you made the right call. It's preferable to not give a suggestion than giving a misleading suggestion.
(&ty::Int(_), &ty::Infer(ty::InferTy::IntVar(_))) | ||
| (&ty::Infer(ty::InferTy::IntVar(_)), &ty::Int(_) | &ty::Infer(ty::InferTy::IntVar(_))) | ||
| (&ty::Float(_), &ty::Infer(ty::InferTy::FloatVar(_))) | ||
| ( | ||
&ty::Infer(ty::InferTy::FloatVar(_)), | ||
&ty::Float(_) | &ty::Infer(ty::InferTy::FloatVar(_)), | ||
) | ||
| (&ty::Infer(ty::InferTy::TyVar(_)), _) | ||
| (_, &ty::Infer(ty::InferTy::TyVar(_))) => true, |
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 pretty sure there's code like this somewhere.
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.
Yeah, this is from fn equals(Ty, Ty) -> bool
.
We could possibly unify them by adding an enum Mode { None, NumInfer, Infer }
or something. The complication is that this equals fn cares about the non-Ty substs in Adt, where TyS::same_ty (and the function I added) doesn't...
Thoughts?
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 see. fn equals
has to make sure the whole type are the same because this is used to determine whether it can be replaced with _
in the output. It's fine.
//~^ ERROR mismatched types [E0308] | ||
} | ||
} | ||
|
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 wonder, can this test be marked as // run-rustfix
?
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.
// run-rustfix
seems to produce broken output.
- In
suggest_await_in_async_fn_return
, the "add a semicolon" and "add .await" suggestions get applied out of order to producedummy();.await
- In
suggest_await_in_generic_pattern
(the test I added), it adds.await
twice, because there are two type errors due to theOk
andErr
branches.
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.
Ah, I see. Fair enough, leave as is.
Here's the output for that case. diff --git a/src/test/ui/half-open-range-patterns/exclusive_range_pattern_syntax_collision.stderr b/src/test/ui/half-open-range-patterns/exclusive_range_pattern_syntax_collision.stderr
index a6f8563a047..1df7fd59f57 100644
--- a/src/test/ui/half-open-range-patterns/exclusive_range_pattern_syntax_collision.stderr
+++ b/src/test/ui/half-open-range-patterns/exclusive_range_pattern_syntax_collision.stderr
@@ -8,6 +8,10 @@ LL | [_, 99.., _] => {},
|
= note: expected struct `std::ops::Range<{integer}>`
found type `{integer}`
+help: you might have meant to use field `start` whose type is `{integer}`
+ |
+LL | match [5..4, 99..105, 43..44].start {
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wait... this is just wrong, isn't it? Do you still want me to replace the other usages of r? @estebank |
@bors r+ |
📌 Commit 323a48d7b44f9b34a6cb67a6ea2105a155763119 has been approved by |
323a48d
to
1f625b7
Compare
@bors r=estebank Fixed up the test output for the test. (I don't know how to use bors... I think this will work) edit: Guess not. |
@compiler-errors: 🔑 Insufficient privileges: Not in reviewers |
r? @estebank |
@bors r+ |
📌 Commit 1f625b7 has been approved by |
…ebank Suggest `await` in more situations where infer types are involved Currently we use `TyS::same_type` in diagnostics that suggest adding `.await` to opaque future types. This change makes the suggestion slightly more general, when we're comparing types like `Result<T, E>` and `Result<_, _>` which happens sometimes in places like `match` patterns or `let` statements with partially-elaborated types. ---- Question: 1. Is this change worthwhile? Totally fine if it doesn't make sense adding. 2. Should `same_type_modulo_infer` live in `rustc_infer::infer::error_reporting` or alongside the other method in `rustc_middle::ty::util`? 3. Should we generalize this change? I wanted to change all usages, but I don't want erroneous suggestions when adding `.field_name`...
…askrgr Rollup of 6 pull requests Successful merges: - rust-lang#89741 (Mark `Arc::from_inner` / `Rc::from_inner` as unsafe) - rust-lang#90927 (Fix float ICE) - rust-lang#90994 (Fix ICE `rust-lang#90993`: add missing call to cancel) - rust-lang#91018 (Adopt let_else in more places in rustc_mir_build) - rust-lang#91022 (Suggest `await` in more situations where infer types are involved) - rust-lang#91088 (Revert "require full validity when determining the discriminant of a value") Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Currently we use
TyS::same_type
in diagnostics that suggest adding.await
to opaque future types.This change makes the suggestion slightly more general, when we're comparing types like
Result<T, E>
andResult<_, _>
which happens sometimes in places likematch
patterns orlet
statements with partially-elaborated types.Question:
same_type_modulo_infer
live inrustc_infer::infer::error_reporting
or alongside the other method inrustc_middle::ty::util
?.field_name
...