diff options
author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2020-09-13 18:28:22 +0100 |
---|---|---|
committer | GitHub <[email protected]> | 2020-09-13 18:28:22 +0100 |
commit | 0d03fe6ef57d3956e92382e0e1f1a916015191cb (patch) | |
tree | 02d51d9e08c50812b895e5b5d1b2fc30ff9150d6 /crates/hir_def/src/generics.rs | |
parent | fda6937d7f91dc723229d1045d9a57b22a846dc7 (diff) | |
parent | 529c369c9bc15a73e7a03260eca84ccef99ac281 (diff) |
Merge #5971
5971: Implement async blocks r=flodiebold a=oxalica
Fix #4018
@flodiebold already gave a generic guide in the issue. Here's some concern about implementation detail:
- Chalk doesn't support generator type yet.
- Adding generator type as a brand new type (ctor) can be complex and need to *re-introduced* builtin impls. (Like how we implement closures before native closure support of chalk, which is already removed in #5401 )
- The output type of async block should be known after type inference of the whole body.
- We cannot directly get the type from source like return-positon-impl-trait. But we still need to provide trait bounds when chalk asking for `opaque_ty_data`.
- During the inference, the output type of async block can be temporary unknown and participate the later inference.
`let a = async { None }; let _: i32 = a.await.unwrap();`
So in this PR, the type of async blocks is inferred as an opaque type parameterized by the `Future::Output` type it should be, like what we do with closure type.
And it really works now.
Well, I still have some questions:
- The bounds `AsyncBlockImplType<T>: Future<Output = T>` is currently generated in `opaque_ty_data`. I'm not sure if we should put this code here.
- Type of async block is now rendered as `impl Future<Output = OutputType>`. Do we need to special display to hint that it's a async block? Note that closure type has its special format, instead of `impl Fn(..) -> ..` or function type.
Co-authored-by: oxalica <[email protected]>
Diffstat (limited to 'crates/hir_def/src/generics.rs')
0 files changed, 0 insertions, 0 deletions