aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir_def/src/lib.rs
Commit message (Collapse)AuthorAgeFilesLines
* Rename ast::ImplBlock -> ast::ImplDefAleksey Kladov2020-02-291-1/+1
|
* More manual clippy fixesKirill Bulatov2020-02-181-2/+2
|
* Introduce AsMacroCall traitEdwin Cheng2020-02-171-1/+62
|
* Introduce SourceBinderAleksey Kladov2020-01-151-1/+1
|
* find_path WIPFlorian Diebold2020-01-111-0/+1
|
* Remove visibility query, instead add struct field visibility to dataFlorian Diebold2019-12-261-23/+0
| | | | | Methods should be handled the same, and for items the visibility will be in the def map.
* Add infrastructure for visibility on syntax and hir_def levelFlorian Diebold2019-12-261-0/+25
|
* Move LocalImportIdAleksey Kladov2019-12-211-4/+0
|
* Remove imports from hirAleksey Kladov2019-12-211-1/+1
|
* Revert "Merge #2629"Aleksey Kladov2019-12-211-0/+4
| | | | | This reverts commit cdc9d682b066b110e0a44e5f8f1c574b38c16ba9, reversing changes made to 90ef070db3dce0a7acb9cd11d0b0d72de13c9d79.
* Privatize LocalImportIDAleksey Kladov2019-12-211-4/+0
|
* Merge #2624bors[bot]2019-12-201-0/+1
|\ | | | | | | | | | | | | | | 2624: Separate module item from module scope r=matklad a=matklad bors r+ Co-authored-by: Aleksey Kladov <[email protected]>
| * Add item_scope moduleAleksey Kladov2019-12-201-0/+1
| |
* | Add support macros in impl blocksEdwin Cheng2019-12-201-0/+1
|/
* Reduce copy-paste some moreAleksey Kladov2019-12-201-13/+1
|
* Use generic ItemLoc for implsAleksey Kladov2019-12-201-23/+4
|
* Remove more copy-pasteAleksey Kladov2019-12-201-121/+29
|
* Remove more copy-pasteAleksey Kladov2019-12-201-57/+30
|
* Support for nested traitsAleksey Kladov2019-12-201-3/+3
|
* Support for nested statics, consts and type aliasesAleksey Kladov2019-12-201-3/+3
|
* Support for nested ADTAleksey Kladov2019-12-201-4/+5
|
* Introduce `ContainerId`Aleksey Kladov2019-12-201-4/+18
|
* Rename ContainerId -> AssocContainerIdAleksey Kladov2019-12-201-9/+9
|
* Add body as a possible container for itemsAleksey Kladov2019-12-191-12/+12
|
* Remove old location infraAleksey Kladov2019-12-121-61/+4
|
* Move enum&union to new locAleksey Kladov2019-12-121-13/+37
|
* Move structs to new locAleksey Kladov2019-12-121-6/+18
|
* Move traits to the new locAleksey Kladov2019-12-121-9/+21
|
* Switch to the new location for implsAleksey Kladov2019-12-121-9/+21
|
* Rename GenericParam -> TypeParamAleksey Kladov2019-12-071-4/+4
| | | | We don't have LifetimeParam yet, but they are planned!
* Classify name works for TypeParamsAleksey Kladov2019-12-071-0/+14
|
* Store GenericParams in arenaAleksey Kladov2019-12-071-0/+10
|
* DynMapAleksey Kladov2019-12-061-1/+4
| | | | | This might, or might not help us to reduce boilerplate associated with plumbing values from analysis to the IDE layer
* Introduce ChildFromSourceAleksey Kladov2019-12-051-0/+1
|
* Move source-related traits to a separate moduleAleksey Kladov2019-11-281-51/+3
|
* Use InFile for AstIdAleksey Kladov2019-11-281-5/+5
|
* Rename Source -> InFileAleksey Kladov2019-11-281-13/+13
|
* Rename module_id -> local_idAleksey Kladov2019-11-271-1/+1
|
* Move TyAleksey Kladov2019-11-271-1/+1
|
* DecoupleAleksey Kladov2019-11-271-0/+10
|
* Introduce hir::TypeAleksey Kladov2019-11-261-0/+10
| | | | It should provide a convenient API over more low-level Ty
* Fixme for union fieldsAleksey Kladov2019-11-251-0/+1
|
* Fix hir for ast::UnionDefAleksey Kladov2019-11-251-18/+14
|
* Merge #2396bors[bot]2019-11-241-6/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2396: Switch to variant-granularity field type inference r=flodiebold a=matklad r? @flodiebold Previously, we had a `ty` query for each field. This PR switcthes to a query per struct, which returns an `ArenaMap` with `Ty`s. I don't know which approach is better. What is bugging me about the original approach is that, if we do all queries on the "leaf" defs, in practice we get a ton of queries which repeatedly reach into the parent definition to compute module, resolver, etc. This *seems* wasteful (but I don't think this is really what causes any perf problems for us). At the same time, I've been looking at Kotlin, and they seem to use the general pattern of analyzing the *parent* definition, and storing info about children into a `BindingContext`. I don't really which way is preferable. I think I want to try this approach, where query granularity generally mirrors the data granularity. The primary motivation for me here is probably just hope that we can avoid adding a ton of helpers to a `StructField`, and maybe in general avoid the need to switch to a global `StructField`, using `LocalStructFieldId` most of the time internally. For external API (ie, for `ra_ide_api`), I think we should continue with fine-grained `StructField::ty` approach, which internally fetches the table for the whole struct and indexes into it. In terms of actual memory savings, the results are as follows: ``` This PR: 142kb FieldTypesQuery (deps) 38kb FieldTypesQuery Status Quo: 208kb TypeForFieldQuery (deps) 18kb TypeForFieldQuery ``` Note how the table itself occupies more than twice as much space! I don't have an explanation for this: a plausible hypothesis is that single-field structs are very common and for them the table is a pessimisation. THere's noticiable wallclock time difference. Co-authored-by: Aleksey Kladov <[email protected]>
| * Switch to variant-granularity field type inferenceAleksey Kladov2019-11-241-6/+7
| |
* | Implement HasModule for AdtIdAleksey Kladov2019-11-241-0/+10
|/
* CleanupAleksey Kladov2019-11-241-6/+9
|
* SimplifyAleksey Kladov2019-11-241-15/+0
|
* Switch to StaticLoc for staticsAleksey Kladov2019-11-241-5/+32
|
* Pull macro upAleksey Kladov2019-11-241-14/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-19 22:31:19 +0000