aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir_def/src/lib.rs
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* Move ModuleSource back to hirAleksey Kladov2019-11-231-60/+2
|
* Privatise nameresAleksey Kladov2019-11-231-3/+2
|
* Rename CrateModuleIdAleksey Kladov2019-11-231-3/+3
|
* Move ImportIdAleksey Kladov2019-11-231-0/+4
|
* Get rid of DefDatabase2Aleksey Kladov2019-11-231-24/+21
|
* Move docs to hir_defAleksey Kladov2019-11-231-0/+1
|
* Move lang_items to hir_defAleksey Kladov2019-11-231-0/+1
|
* Use attrs rather than syntax for lang itemsAleksey Kladov2019-11-231-1/+3
|
* Move attrs query to hir_defAleksey Kladov2019-11-231-3/+30
|
* More principled sources for enums and fieldsAleksey Kladov2019-11-221-1/+12
|
* Move data to a single fileAleksey Kladov2019-11-221-4/+1
|
* Move FunctionData to hir_defAleksey Kladov2019-11-221-0/+1
|
* Move TypeAlias to hir_defAleksey Kladov2019-11-221-0/+1
|
* Move resolver to hir_defAleksey Kladov2019-11-211-0/+1
|
* Move constants to new IDAleksey Kladov2019-11-201-5/+35
| | | | This allows us to get rid of trait item index
* Don't duplicate ContainerId typeAleksey Kladov2019-11-201-22/+15
|
* Switch type aliases to new sourcesAleksey Kladov2019-11-201-5/+43
|
* Next gen IDs for functionsAleksey Kladov2019-11-201-5/+61
| | | | | | | | | | | | | | | | | The current system with AstIds has two primaraly drawbacks: * It is possible to manufacture IDs out of thin air. For example, it's possible to create IDs for items which are not considered in CrateDefMap due to cfg. Or it is possible to mixup structs and unions, because they share ID space. * Getting the ID of a parent requires a secondary index. Instead, the plan is to pursue the more traditional approach, where each items stores the id of the parent declaration. This makes `FromSource` more awkward, but also more correct: now, to get from an AST to HIR, we first do this recursively for the parent item, and the just search the children of the parent for the matching def
* Move traits to hir_defAleksey Kladov2019-11-201-1/+2
|
* Move Generics to hir_defAleksey Kladov2019-11-201-0/+24
|
* Rename Source::ast -> Source::valueAleksey Kladov2019-11-201-3/+3
|
* Sourcify some thingsAleksey Kladov2019-11-151-6/+5
| | | | | If we want to support macros properly, we need to get rid of those FileIds everywhere...
* Remove old impls infrastructureAleksey Kladov2019-11-151-0/+13
|
* Add ImplIdAleksey Kladov2019-11-151-0/+12
|
* Move body queries to hir_defAleksey Kladov2019-11-141-0/+10
|
* Move definition of exprs to hir_defAleksey Kladov2019-11-121-0/+2
|
* Unfork struct and union idsAleksey Kladov2019-11-091-12/+16
|
* Restore crate_def_map marksAleksey Kladov2019-11-031-0/+2
|
* Introduce ra_db::fixture fixture moduleAleksey Kladov2019-11-031-0/+3
| | | | The goal here is to share more testing infrastructure between crates.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 01:58:52 +0000