Skip to content
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

Merged
merged 2 commits into from
Nov 21, 2021

Conversation

compiler-errors
Copy link
Member

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...

@rust-highfive
Copy link
Collaborator

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 18, 2021
..
}) => {
if let [.., arm_span] = &prior_arms[..] {
(Some(exp), Some(found)) if ty::TyS::same_type_modulo_infer(exp, found) => {
Copy link
Member Author

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.

Copy link
Contributor

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.

@nagisa
Copy link
Member

nagisa commented Nov 19, 2021

r? @estebank

@rust-highfive rust-highfive assigned estebank and unassigned jackh726 Nov 19, 2021
@estebank
Copy link
Contributor

Is this change worthwhile? Totally fine if it doesn't make sense adding.

Yes.

Should same_type_modulo_infer live in rustc_infer::infer::error_reporting or alongside the other method in rustc_middle::ty::util?

That would be ideal. That would send a clear signal to anyone that reaches for it in the future for something else.

Should we generalize this change? I wanted to change all usages, but I don't want erroneous suggestions when adding .field_name...

I'm not sure I follow the question? If you could elaborate?

r=me after moving same_type_modulo_infer to error_reporting.

@compiler-errors
Copy link
Member Author

compiler-errors commented Nov 19, 2021

Should we generalize this change? I wanted to change all usages, but I don't want erroneous suggestions when adding .field_name...

Sorry, I mean other usages of TyS::same_type in error_reporting, specifically the code in suggest_accessing_field_where_appropriate that suggests to add .field when it expects a type and finds a struct with a member. I found it gives a strange suggestion when you try to match a range against an int when i added this modulo-inferencing (and hence why i limited these changes just to the await suggestion).

Copy link
Contributor

@estebank estebank left a 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.

Comment on lines +328 to +336
(&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,
Copy link
Contributor

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.

Copy link
Member Author

@compiler-errors compiler-errors Nov 19, 2021

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?

Copy link
Contributor

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]
}
}

Copy link
Contributor

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?

Copy link
Member Author

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.

  1. In suggest_await_in_async_fn_return, the "add a semicolon" and "add .await" suggestions get applied out of order to produce dummy();.await
  2. In suggest_await_in_generic_pattern (the test I added), it adds .await twice, because there are two type errors due to the Ok and Err branches.

Copy link
Contributor

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.

@compiler-errors
Copy link
Member Author

I'd like to see the strange output for Range, but I suspect you made the right call.

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? [Range<{int}>; N] doesn't have a field start, right? I think this is just a bug, so I'll file one. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b789116e3b4c72d5c06c5deaa8a55e8e

Do you still want me to replace the other usages of TyS::same_type in this file then?

r? @estebank

@estebank
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Nov 19, 2021

📌 Commit 323a48d7b44f9b34a6cb67a6ea2105a155763119 has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 19, 2021
@compiler-errors
Copy link
Member Author

This diff is going to conflict with #91021 which changes impl Future outputs (one of which is in the new test I added...)

@bors r-

... I don't really know how bors works but I think this will keep this from getting rolled up. Then I'll try bors again.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 20, 2021
@compiler-errors
Copy link
Member Author

compiler-errors commented Nov 20, 2021

@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.

@bors
Copy link
Contributor

bors commented Nov 20, 2021

@compiler-errors: 🔑 Insufficient privileges: Not in reviewers

@compiler-errors
Copy link
Member Author

r? @estebank

@estebank
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Nov 20, 2021

📌 Commit 1f625b7 has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 20, 2021
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 20, 2021
…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`...
This was referenced Nov 20, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 20, 2021
…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
@bors bors merged commit ec2f087 into rust-lang:master Nov 21, 2021
@rustbot rustbot added this to the 1.58.0 milestone Nov 21, 2021
@compiler-errors compiler-errors deleted the modulo_infer branch December 3, 2021 07:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants