aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_def/src
Commit message (Collapse)AuthorAgeFilesLines
...
| * | Fix `mut self` not emitting mutable binding on `self` useLukas Wirth2020-10-111-1/+4
| |/
* | Merge #5917bors[bot]2020-10-124-12/+18
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5917: Add a command to open docs for the symbol under the cursor r=matklad a=zacps #### Todo - [ ] Decide if there should be a default keybind or context menu entry - [x] Figure out how to get the documentation path for methods and other non-top-level defs - [x] Design the protocol extension. In future we'll probably want parameters for local/remote documentation URLs, so that should maybe be done in this PR? - [x] Code organisation - [x] Tests Co-authored-by: Zac Pullar-Strecker <[email protected]>
| * | Update tests for new function fieldZac Pullar-Strecker2020-10-081-12/+12
| | |
| * | Differentiate method/tymethod by determining 'defaultness'Zac Pullar-Strecker2020-10-083-0/+6
| |/ | | | | | | | | | | | | | | | | Currently a method only has defaultness if it is a provided trait method, but this will change when specialisation is available and may need to become a concept known to hir. I opted to go for a 'fewest changes' approach given specialisation is still under development.
* / adt: correctly inherit field visibility from enumJonas Schievink2020-10-091-9/+19
|/ | | | | | | Previously, "find all references" on a variant field wouldn't find any references outside the defining module. This is because variant fields were incorrectly assumed to be private, like struct fields without explicit visibility, but they actually inherit the enum's visibility.
* Add test makrAleksey Kladov2020-10-061-0/+2
|
* Constrain ImportMap to only store simple pathsAleksey Kladov2020-10-061-10/+26
|
* Move ModPath->ast::Path function to IDE layerAleksey Kladov2020-10-061-21/+1
| | | | closes #6092
* Merge #6124bors[bot]2020-10-062-6/+6
|\ | | | | | | | | | | | | | | | | | | | | | | 6124: Better normalized crate name usage r=jonas-schievink a=SomeoneToIgnore Closes https://github.com/rust-analyzer/rust-analyzer/issues/5343 Closes https://github.com/rust-analyzer/rust-analyzer/issues/5932 Uses normalized name for code snippets (to be able to test the fix), hover messages and documentation rewrite links (are there any tests for those?). Also renamed the field to better resemble the semantics. Co-authored-by: Kirill Bulatov <[email protected]>
| * Properly name the fieldKirill Bulatov2020-10-022-6/+6
| |
* | Merge #6139bors[bot]2020-10-061-109/+138
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6139: Make find_path_prefixed configurable r=matklad a=Veykril This makes `find_path_prefixed` more configurable allowing one to choose whether it always returns absolute paths, self-prefixed paths or to ignore local imports when building the path. The config names are just thrown in here, taking better names if they exist :) This should fix #6131 as well? Co-authored-by: Lukas Wirth <[email protected]>
| * | Make find_path_prefixed configurableLukas Wirth2020-10-051-109/+138
| |/
* / Account for proc macro helpers when parsing attrJonas Schievink2020-10-052-1/+9
|/
* Merge #6019bors[bot]2020-09-291-4/+22
|\ | | | | | | | | | | | | | | 6019: Remove make::path_from_text r=matklad a=Veykril This removes the `make::path_from_text` function, which according to a note should've been private. I removed it since it didn't really serve a purpose as it was simply wrapping `make::ast_from_text`. Co-authored-by: Lukas Wirth <[email protected]>
| * Remove make::path_from_textLukas Wirth2020-09-161-4/+22
| |
* | Merge #6033bors[bot]2020-09-283-15/+176
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6033: Make name resolution resolve proc macros instead of relying purely on the build system r=matklad a=jonas-schievink This makes name resolution look at proc-macro declaration attributes like `#[proc_macro_derive]` and defines the right proc macro in the macro namespace, fixing unresolved custom derives like `thiserror::Error` (which can cause false positives, now that we emit diagnostics for unresolved imports). This works even when proc-macro support is turned off, in which case we fall back to a dummy expander that always returns an error. IMO this is the right way to handle at least the name resolution part of proc. macros, while the *expansion* itself should rely on the build system to build and provide the macro DLL. It does mean that they may go out of sync, but we can provide diagnostics if that happens (something like "could not find macro X in crate Y – ensure that all files of crate Y are saved"). I think it is valuable to be able to reason about proc macros even when we can't expand them, since proc macro expansion can break between Rust releases or users might not want to turn it on for performance reasons. It allows us to provide better diagnostics on any proc macro invocation we're not expanding (like a weak warning that informs the user that proc macro support is turned off, or that it has been disabled because the server crashed). Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5763 Co-authored-by: Jonas Schievink <[email protected]>
| * | Add more comments about proc macro resolutionJonas Schievink2020-09-281-0/+20
| | |
| * | Simplify iterator chainJonas Schievink2020-09-281-5/+2
| | |
| * | Remove incorrect docsJonas Schievink2020-09-181-6/+0
| | |
| * | Reduce visibility of non-proc-macrosJonas Schievink2020-09-183-0/+85
| | | | | | | | | | | | | | | proc-macro crates only export proc-macros, but currently other items are also considered public (and show up in completion)
| * | Remove obsolete proc macro collection codeJonas Schievink2020-09-181-19/+0
| | | | | | | | | | | | The new attribute-based resolution takes care of this
| * | Use hir_def to resolve proc macrosJonas Schievink2020-09-182-2/+54
| | |
| * | 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 <[email protected]>
| * | | 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 <[email protected]>
| * 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 <[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
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-21 13:51:04 +0000