aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_def
Commit message (Collapse)AuthorAgeFilesLines
...
| * | Add testJonas Schievink2020-09-181-0/+32
| | |
* | | Merge #6085bors[bot]2020-09-281-0/+7
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6085: Mark unresolved imports diagnostic as experimental r=jonas-schievink a=jonas-schievink It causes a lot of false positives for people. We collected all of the known ones during the last week. Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
| * | | Mark unresolved imports diagnostic as experimentalJonas Schievink2020-09-281-0/+7
| |/ /
* / / Don't unnecessarily unnest imports for import insertionLukas Wirth2020-09-251-43/+127
|/ /
* | Rename `CustomDerive` to `ProcMacro`Jonas Schievink2020-09-181-1/+1
| | | | | | | | | | It handles fn-like macros too, and will handle attribute macros in the future
* | Invert condition to unindent codeJonas Schievink2020-09-181-158/+157
| |
* | Give `ExternCrate` a `Name`, not a `ModPath`Jonas Schievink2020-09-175-18/+11
| |
* | Merge #6016bors[bot]2020-09-1710-72/+388
|\ \ | |/ |/| | | | | | | | | | | | | | | 6016: Emit diagnostics for unresolved imports and extern crates r=jonas-schievink a=jonas-schievink AFAIK, we don't have any major bugs in name resolution that would cause a lot of false positives here (except procedural attribute macro support and some rare issues around `#[path]` on module files), so these are *not* marked as experimental diagnostics right now. I noticed that diagnostics in a file sometimes don't get displayed after opening, but require some edit to be performed. This seems like a preexisting issue though. Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
| * Don't diagnose imports whose base crate is missingJonas Schievink2020-09-172-17/+64
| |
| * 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
| |
* | Lower extern type alias as foreign opaque type.Charles Lew2020-09-161-0/+2
| |
* | Update chalk to 0.27 and adapt to chalk changes.Charles Lew2020-09-153-3/+6
|/
* 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 <oxalicc@pm.me>
| * Implement async blocksoxalica2020-09-102-2/+8
| |
* | Implement box pattern inferenceJonas Schievink2020-09-122-1/+7
|/
* :arrow_up: expect-testAleksey Kladov2020-08-281-1/+1
|
* Support extern typesJonas Schievink2020-08-242-0/+6
|
* Add description for crates that will be publishedPavan Kumar Sunkara2020-08-241-0/+1
|
* Add version to deps in cargo.tomlPavan Kumar Sunkara2020-08-241-10/+10
|
* :arrow_up: ungrammarAleksey Kladov2020-08-211-1/+1
|
* Switch to expect_test from crates.ioAleksey Kladov2020-08-214-4/+4
|
* 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 <popzxc@yandex.ru>
| * 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-1344-0/+15319