Move hir_def::keys to hir_def::dyn_map

This commit is contained in:
Lukas Wirth 2023-04-06 19:49:33 +02:00
parent 40c068f502
commit 12b069f434
7 changed files with 9 additions and 8 deletions

View file

@ -10,9 +10,8 @@ use syntax::ast::HasDocComments;
use crate::{ use crate::{
db::DefDatabase, db::DefDatabase,
dyn_map::DynMap, dyn_map::{keys, DynMap},
item_scope::ItemScope, item_scope::ItemScope,
keys,
src::{HasChildSource, HasSource}, src::{HasChildSource, HasSource},
AdtId, AssocItemId, DefWithBodyId, EnumId, EnumVariantId, FieldId, ImplId, Lookup, MacroId, AdtId, AssocItemId, DefWithBodyId, EnumId, EnumVariantId, FieldId, ImplId, Lookup, MacroId,
ModuleDefId, ModuleId, TraitId, VariantId, ModuleDefId, ModuleId, TraitId, VariantId,

View file

@ -21,6 +21,8 @@
//! //!
//! This is a work of fiction. Any similarities to Kotlin's `BindingContext` are //! This is a work of fiction. Any similarities to Kotlin's `BindingContext` are
//! a coincidence. //! a coincidence.
pub mod keys;
use std::{ use std::{
hash::Hash, hash::Hash,
marker::PhantomData, marker::PhantomData,

View file

@ -20,8 +20,7 @@ use crate::{
body::{Expander, LowerCtx}, body::{Expander, LowerCtx},
child_by_source::ChildBySource, child_by_source::ChildBySource,
db::DefDatabase, db::DefDatabase,
dyn_map::DynMap, dyn_map::{keys, DynMap},
keys,
src::{HasChildSource, HasSource}, src::{HasChildSource, HasSource},
type_ref::{LifetimeRef, TypeBound, TypeRef}, type_ref::{LifetimeRef, TypeBound, TypeRef},
AdtId, ConstParamId, GenericDefId, HasModule, LifetimeParamId, LocalLifetimeParamId, AdtId, ConstParamId, GenericDefId, HasModule, LifetimeParamId, LocalLifetimeParamId,

View file

@ -24,7 +24,6 @@ pub mod per_ns;
pub mod item_scope; pub mod item_scope;
pub mod dyn_map; pub mod dyn_map;
pub mod keys;
pub mod item_tree; pub mod item_tree;

View file

@ -14,7 +14,7 @@
//! expression, an item definition. //! expression, an item definition.
//! //!
//! Knowing only the syntax gives us relatively little info. For example, //! Knowing only the syntax gives us relatively little info. For example,
//! looking at the syntax of the function we can realise that it is a part of an //! looking at the syntax of the function we can realize that it is a part of an
//! `impl` block, but we won't be able to tell what trait function the current //! `impl` block, but we won't be able to tell what trait function the current
//! function overrides, and whether it does that correctly. For that, we need to //! function overrides, and whether it does that correctly. For that, we need to
//! go from [`ast::Fn`] to [`crate::Function`], and that's exactly what this //! go from [`ast::Fn`] to [`crate::Function`], and that's exactly what this
@ -88,9 +88,11 @@
use base_db::FileId; use base_db::FileId;
use hir_def::{ use hir_def::{
child_by_source::ChildBySource, child_by_source::ChildBySource,
dyn_map::DynMap, dyn_map::{
keys::{self, Key},
DynMap,
},
hir::{BindingId, LabelId}, hir::{BindingId, LabelId},
keys::{self, Key},
AdtId, ConstId, ConstParamId, DefWithBodyId, EnumId, EnumVariantId, FieldId, FunctionId, AdtId, ConstId, ConstParamId, DefWithBodyId, EnumId, EnumVariantId, FieldId, FunctionId,
GenericDefId, GenericParamId, ImplId, LifetimeParamId, MacroId, ModuleId, StaticId, StructId, GenericDefId, GenericParamId, ImplId, LifetimeParamId, MacroId, ModuleId, StaticId, StructId,
TraitAliasId, TraitId, TypeAliasId, TypeParamId, UnionId, VariantId, TraitAliasId, TraitId, TypeAliasId, TypeParamId, UnionId, VariantId,