-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
fix: Fix return type of async closures. #12958
Conversation
crates/hir-ty/src/infer/expr.rs
Outdated
// Use the first type parameter as the output type of future. | ||
// existential type AsyncBlockImplTrait<InnerType>: Future<Output = InnerType> | ||
let impl_trait_id = crate::ImplTraitId::AsyncBlockTypeImplTrait(self.owner, *body); | ||
let opaque_ty_id = self.db.intern_impl_trait_id(impl_trait_id).into(); | ||
dbg!(&ret_ty); | ||
TyKind::OpaqueType(opaque_ty_id, Substitution::from1(Interner, ret_ty)) | ||
.intern(Interner) |
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.
This was mostly copied from the Expr::Async
arm on line 152 above.
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.
This uses AsyncBlockTypeImplTrait
but isn't an async block.
Should a new variant be added to ImplTraitId
? Or maybe AsyncBlockTypeImplTrait
should be renamed?
20d3b5a
to
2a6bdd1
Compare
let f = async move |x: i32| x + 42; | ||
f; | ||
// ^ |i32| -> impl Future<Output = i32> |
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.
It now gives correct hints for the example in #12957. (The |
☔ The latest upstream changes (presumably #13165) made this pull request unmergeable. Please resolve the merge conflicts. |
2afae76
to
f9e8c6e
Compare
☔ The latest upstream changes (presumably #13209) made this pull request unmergeable. Please resolve the merge conflicts. |
Can someone knowing the type system side of r-a have a look at this? |
There landed some changes revolving the closure inference code (we have landed support for generators), can you update this PR to make use of the same machinery? That will probably tell if your current approach works out fine as well. |
Yes, I should have time this weekend to look into that. |
f9e8c6e
to
49897ee
Compare
I rebased, but I didn't change to use the new machinery yet. I should be able to look into that sometime this week. |
☔ The latest upstream changes (presumably #14222) made this pull request unmergeable. Please resolve the merge conflicts. |
I went ahead and moved this to the new machinery, I hope you don't mind :) |
@bors r+ |
☀️ Test successful - checks-actions |
May fix #12957