Commit Graph

416 Commits

Author SHA1 Message Date
Jonas Schievink
44f4510caa Store Import indices for later reconstruction 2020-09-16 12:35:09 +02:00
Charles Lew
b302f69b7c Update chalk to 0.27 and adapt to chalk changes. 2020-09-15 22:37:05 +08:00
bors[bot]
0d03fe6ef5
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 <oxalicc@pm.me>
2020-09-13 17:28:22 +00:00
Jonas Schievink
07a704e31c Implement box pattern inference 2020-09-12 21:18:57 +02:00
oxalica
251ef93ac3
Implement async blocks 2020-09-10 20:01:23 +08:00
Aleksey Kladov
c692b5d76d ⬆️ expect-test 2020-08-28 14:47:14 +02:00
Jonas Schievink
f3ac19e8cd Support extern types 2020-08-24 22:02:55 +02:00
Pavan Kumar Sunkara
335add49db Add description for crates that will be published 2020-08-24 13:07:22 +02:00
Pavan Kumar Sunkara
a8fa5cd42e Add version to deps in cargo.toml 2020-08-24 11:10:41 +02:00
Aleksey Kladov
863b1fb731 ⬆️ ungrammar 2020-08-21 19:14:05 +02:00
Aleksey Kladov
b0fd3faf36 Switch to expect_test from crates.io 2020-08-21 13:19:31 +02:00
Aleksey Kladov
8146669542 Add type safety to diagnostic codes 2020-08-18 18:39:43 +02:00
bors[bot]
b8dfc331ab
Merge #5682
5682: Add an option to disable diagnostics r=matklad a=popzxc

As far as I know, currently it's not possible to disable a selected type of diagnostics provided by `rust-analyzer`.

This causes an inconvenient situation with a false-positive warnings: you either have to disable all the diagnostics, or you have to ignore these warnings.

There are some open issues related to this problem, e.g.: https://github.com/rust-analyzer/rust-analyzer/issues/5412, https://github.com/rust-analyzer/rust-analyzer/issues/5502

This PR attempts to make it possible to selectively disable some diagnostics on per-project basis.

Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
2020-08-18 12:04:49 +00:00
Aleksey Kladov
2052d33b9b Remove deprecated Path::from_ast
Long term, we probably should make hir::Path private to hir.
2020-08-15 18:22:16 +02:00
Igor Aleksanov
c26c911ec1 Merge branch 'master' into add-disable-diagnostics 2020-08-14 07:34:07 +03:00
Aleksey Kladov
b28c54a2c2 Rename ra_hir_def -> hir_def 2020-08-13 16:29:33 +02:00