-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 calling await on method call and field access #78297
Conversation
@@ -1623,6 +1669,53 @@ impl<'a, 'tcx> InferCtxt<'a, 'tcx> { | |||
self.note_error_origin(diag, cause, exp_found); | |||
} | |||
|
|||
pub fn get_impl_future_output_ty(&self, ty: Ty<'tcx>) -> Option<Ty<'tcx>> { |
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.
https://github.com/rust-lang/rust/pull/76765/files#diff-b5c71ca5f71c77ba51507d5ba5cfe4afa15578aaa8f2f0385ef88423cb69744fR88 has a similar fn but it operates on rustc_*hir*::Ty<'_>
instead of this, which I think is rustc_middle::Ty<'_>
Should they be merged? In that PR, we specifically need to check the HIR because we need to know if its an async fn, but after that we could switch to using rustc_middle
(can you get an rustc_middle::Ty
with a local def id?)
That fn also just checks the bound against the symbol Output
, this seems to find the future trait def and compare against that, that may be better (but I am not sure if rustc_hir::Ty
makes that easy)
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.
Whenever you have a ty::Ty<'tcx>
it is easier to do it this way, when you have access to the hir::Ty
that comes from the return type of the hir
fn
return type it easier to use that directly.
We might be able to unify these two methods, but I've found in the past that I've had to have the same logic twice, one for the hir
and another for ty
, so I wouldn't be too torn about the "duplication".
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.
perhaps we can merge these separately and then if I find time I can see how hard it is to merge!
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.
That sounds good.
r=me after a rebase |
When encountering a failing method or field resolution on a `Future`, look at the `Output` and try the same operation on it. If successful, suggest calling `.await` on the `Future`. This had already been introduced in rust-lang#72784, but at some point they stopped working.
1c8490e
to
28f02fb
Compare
@bors r=oli-obk |
📌 Commit 28f02fb has been approved by |
Rollup of 10 pull requests Successful merges: - rust-lang#78152 (Separate unsized locals) - rust-lang#78297 (Suggest calling await on method call and field access) - rust-lang#78351 (Move "mutable thing in const" check from interning to validity) - rust-lang#78365 (check object safety of generic constants) - rust-lang#78379 (Tweak invalid `fn` header and body parsing) - rust-lang#78391 (Add const_fn in generics test) - rust-lang#78401 (resolve: private fields in tuple struct ctor diag) - rust-lang#78408 (Remove tokens from foreign items in `TokenStripper`) - rust-lang#78447 (Fix typo in comment) - rust-lang#78453 (Fix typo in comments) Failed merges: r? `@ghost`
When encountering a failing method or field resolution on a
Future
,look at the
Output
and try the same operation on it. If successful,suggest calling
.await
on theFuture
.This had already been introduced in #72784, but at some point they
stopped working.
Built on top of #78214, only last commit is relevant.
r? @oli-obk