hir/db.rs
1//! Re-exports various subcrates' databases and queries so that the calling code
2//! can depend only on `hir`. This breaks abstraction boundary a bit, it would
3//! be cool if we didn't do that.
4//!
5//! But we need this for at least LRU caching at the query level.
6pub use hir_def::{file_item_tree, set_expand_proc_attr_macros};
7pub use hir_ty::db::HirDatabase;