aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_def/src
Commit message (Collapse)AuthorAgeFilesLines
* Add annotation-based nameres diagnostic testsJonas Schievink2020-09-164-38/+150
|
* Track import sources and emit diagnosticsJonas Schievink2020-09-162-21/+60
|
* Leave extern crate items unresolved if they areJonas Schievink2020-09-161-1/+5
|
* Add diagnostic types for unresolved crates/importsJonas Schievink2020-09-163-19/+128
|
* Store `Import` indices for later reconstructionJonas Schievink2020-09-163-4/+9
|
* Merge #5971bors[bot]2020-09-132-2/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Implement async blocksoxalica2020-09-102-2/+8
| |
* | Implement box pattern inferenceJonas Schievink2020-09-122-1/+7
|/
* Support extern typesJonas Schievink2020-08-242-0/+6
|
* :arrow_up: ungrammarAleksey Kladov2020-08-211-1/+1
|
* Switch to expect_test from crates.ioAleksey Kladov2020-08-213-3/+3
|
* Add type safety to diagnostic codesAleksey Kladov2020-08-181-3/+3
|
* Merge #5682bors[bot]2020-08-181-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * Merge branch 'master' into add-disable-diagnosticsIgor Aleksanov2020-08-141-0/+3
| |
* | Remove deprecated Path::from_astAleksey Kladov2020-08-151-6/+0
|/ | | | Long term, we probably should make hir::Path private to hir.
* Rename ra_hir_def -> hir_defAleksey Kladov2020-08-1343-0/+15284