aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_def/src/nameres.rs
Commit message (Collapse)AuthorAgeFilesLines
* internal: move diagnostics to hirAleksey Kladov2021-05-251-244/+8
| | | | | | | | | | | | | | | | | | | | | | | The idea here is to eventually get rid of `dyn Diagnostic` and `DiagnosticSink` infrastructure altogether, and just have a `enum hir::Diagnostic` instead. The problem with `dyn Diagnostic` is that it is defined in the lowest level of the stack (hir_expand), but is used by the highest level (ide). As a first step, we free hir_expand and hir_def from `dyn Diagnostic` and kick the can up to `hir_ty`, as an intermediate state. The plan is then to move DiagnosticSink similarly to the hir crate, and, as final third step, remove its usage from the ide. One currently unsolved problem is testing. You can notice that the test which checks precise diagnostic ranges, unresolved_import_in_use_tree, was moved to the ide layer. Logically, only IDE should have the infra to render a specific range. At the same time, the range is determined with the data produced in hir_def and hir crates, so this layering is rather unfortunate. Working on hir_def shouldn't require compiling `ide` for testing.
* Precompute macro fragment kindJonas Schievink2021-05-091-1/+1
|
* Don't store call-site text offsets in hygiene infoJonas Schievink2021-05-061-0/+1
|
* Add failing local items testJonas Schievink2021-04-211-0/+14
|
* Include path in `unresolved-macro-call` diagnosticJonas Schievink2021-04-161-4/+9
|
* Store `#[derive]` attribute ID along macro invocJonas Schievink2021-04-091-1/+1
|
* Use named fields in `MacroCallKind`Jonas Schievink2021-04-081-14/+14
|
* Use exhaustive matches in shrink_to_fit implsJonas Schievink2021-04-041-5/+19
|
* Use shrink_to_fit to reduce DefMap sizesJonas Schievink2021-04-031-0/+11
|
* resolver: manually traverse nested block scopesJonas Schievink2021-03-221-0/+17
|
* Rename derive-specific APIsJonas Schievink2021-03-191-2/+2
|
* Record custom derive helpers in `DefMap`Jonas Schievink2021-03-181-1/+11
| | | | Also clean up proc macro attribute parsing a bit
* Rename `item_tree` query to `file_item_tree`Jonas Schievink2021-03-181-1/+1
|
* Fix `find_path` when inner items are presentJonas Schievink2021-03-011-0/+12
|
* For unresolved macros, hightlight only the last segmentAleksey Kladov2021-02-281-0/+14
|
* is_visible_from_def_map: handle block expressionsJonas Schievink2021-02-231-0/+6
|
* Make `with_ancestor_maps` publicJonas Schievink2021-02-091-1/+1
|
* Don't keep the parent DefMap alive via ArcJonas Schievink2021-02-041-19/+41
| | | | | This seems like it could easily leak a lot of memory since we don't currently run GC
* Split out ItemScope::dump from DefMap::dumpJonas Schievink2021-02-031-21/+1
|
* Add newline between block and crate mapsJonas Schievink2021-02-031-0/+1
|
* Update `DefMap` and `block_def_map` docsJonas Schievink2021-02-031-1/+10
|
* Shortcut `block_def_map` if there's no inner itemsJonas Schievink2021-02-031-4/+9
| | | | | This previously didn't work, but apparently only because of the wonky test setup
* Fix resolution of `crate` paths from within blocksJonas Schievink2021-02-021-0/+5
| | | | | They resolve to the crate root, not the DefMap's root module (which can be a block)
* Use the right `DefMap` when looking up modulesJonas Schievink2021-02-021-0/+4
|
* Revert "Use block_def_map in body lowering"Jonas Schievink2021-02-021-4/+2
|
* Shortcut `block_def_map` if there's no inner itemsJonas Schievink2021-02-011-2/+4
| | | | | This previously didn't work, but apparently only because of the wonky test setup
* Fix incorrect `FileId` and remove broken shortcutJonas Schievink2021-01-281-9/+3
| | | | | Apparently we were using the crate's root file instead of the file containing the block.
* Fix legacy macro resolution in block expressionsJonas Schievink2021-01-271-0/+11
|
* Intern block locations and handle them in ModuleIdJonas Schievink2021-01-251-47/+26
|
* Create all `ModuleId`s through a `DefMap` methodJonas Schievink2021-01-251-0/+4
| | | | | `ModuleId` needs to be able to represent blocks, and only the associated `DefMap` will know how to construct that `ModuleId`
* Include `countme` crate to count important data structures.Aleksey Kladov2021-01-211-0/+3
|
* Add name resolution query for block expressionsJonas Schievink2021-01-211-17/+78
|
* Treat BlockExpr as a potential module originJonas Schievink2021-01-201-2/+10
|
* DefMap: hide remaining crate-visible fieldsJonas Schievink2021-01-201-3/+15
|
* Make public DefMap fields privateJonas Schievink2021-01-201-2/+10
|
* Rename `CrateDefMap` to `DefMap`Jonas Schievink2021-01-181-6/+6
|
* prepare to publish el libro de arenaAleksey Kladov2021-01-141-1/+1
|
* Remove some unneeded string allocationsLukas Wirth2020-12-311-1/+1
|
* Avoid a couple of allocationsLaurențiu Nicola2020-12-291-1/+1
|
* More accurately place proc-macro diagnosticJonas Schievink2020-11-271-3/+38
|
* Publish diagnostics for macro expansion errorsJonas Schievink2020-11-271-2/+50
|
* Don't store `SyntaxNodePtr` in `CrateDefMap`Jonas Schievink2020-11-261-4/+5
| | | | It is volatile across reparses and makes incrementality worse.
* Emit better #[cfg] diagnosticsJonas Schievink2020-10-221-4/+12
|
* Rename UnconfiguredCode -> InactiveCodeJonas Schievink2020-10-201-1/+1
|
* Add a (hint) diagnostic for unconfigured itemsJonas Schievink2020-10-201-1/+14
|
* Rename declaration_name -> display_nameAleksey Kladov2020-10-201-5/+1
| | | | | | | | Declaration names sounds like a name of declaration -- something you can use for analysis. It empathically isn't, and is just a label displayed in various UI. It's important not to confuse the two, least we accidentally mix semantics with UI (I believe, there's already a case of this in the FamousDefs at least).
* Properly name the fieldKirill Bulatov2020-10-021-1/+1
|
* Add diagnostic types for unresolved crates/importsJonas Schievink2020-09-161-12/+81
|
* Rename ra_hir_def -> hir_defAleksey Kladov2020-08-131-0/+326
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-02 23:12:50 +0000