diff options
author | bors[bot] <bors[bot]@users.noreply.github.com> | 2019-01-06 14:51:10 +0000 |
---|---|---|
committer | bors[bot] <bors[bot]@users.noreply.github.com> | 2019-01-06 14:51:10 +0000 |
commit | cf0ce14351af03c620aca784ee2c03aad86b866e (patch) | |
tree | bffd84981df9cca1143807796dc6772ddcfe8e0b /crates/ra_hir/src/db.rs | |
parent | eaf553dade9a28b41631387d7c88b09fd0ba64e2 (diff) | |
parent | 733383446fc229a35d4432d14c295c5a01e5a87f (diff) |
Merge #429
429: Reorganize hir public API in terms of code model r=matklad a=matklad
Recently, I've been thinking about introducing "object orient code model" API for rust: a set of APIs with types like `Function`, `Module`, etc, with methods like `get_containing_declaration()`, `get_type()`, etc.
Here's how a similar API might look like in .Net land:
https://docs.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.semanticmodel?view=roslyn-dotnet
https://docs.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.imethodsymbol?view=roslyn-dotnet
The main feature of such API is that it can be powered by different backends. For example, one can imagine a backend based on salsa, and a backend which reads all the data from a specially prepared JSON file. The "OO" bit is interesting mostly in this "can swap implementations via dynamic dispatch" aspect, the actual API could have a more database/ECS flavored feeling.
It's not clear at this moment how exactly should we implement such a dynamically (or if we even need dynamism in the first pace) swapable API in Rust, but I'd love to experiment with this a bit.
For starters, I propose creating a `code_model_api` which contains various definition types and their public methods (mandatory implemented as one-liners, so that the API has a header-file feel). Specifically, I propose that each type is a wrapper around some integer ID, and that all methods of it accept a `&db` argument. The actual impl goes elsewhere: into the db queries or, absent a better place, into the `code_model_api_impl`. In the first commit, I've moved the simplest type, `Crate`, over to this pattern.
I *think* that we, at least initially, will be used types from `code_model_api` *inside* `hir` as well, but this is not required: we might pick a different implementation down the line, while preserving the API.
Long term I'd love to replace the `db: &impl HirDatabase` argument by a `mp: &dyn ModelProvider`, implement `ModelProvider` for `T: HirDatabase`, and move `code_model_api` into the separate crate, which does not depend on `hir`.
@flodiebold you've recently done some `Def`s work, would do you think of this plan? Could it become a good API in the future, or is it just a useless boilerplate duplicating method signatures between `code_model_api` and `code_model_impl`?
Co-authored-by: Aleksey Kladov <[email protected]>
Diffstat (limited to 'crates/ra_hir/src/db.rs')
-rw-r--r-- | crates/ra_hir/src/db.rs | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/crates/ra_hir/src/db.rs b/crates/ra_hir/src/db.rs index 96a3c60b9..e4249de14 100644 --- a/crates/ra_hir/src/db.rs +++ b/crates/ra_hir/src/db.rs | |||
@@ -9,8 +9,8 @@ use crate::{ | |||
9 | query_definitions, | 9 | query_definitions, |
10 | FnSignature, FnScopes, | 10 | FnSignature, FnScopes, |
11 | macros::MacroExpansion, | 11 | macros::MacroExpansion, |
12 | module::{ModuleId, ModuleTree, ModuleSource, | 12 | module_tree::{ModuleId, ModuleTree, ModuleSource}, |
13 | nameres::{ItemMap, InputModuleItems}}, | 13 | nameres::{ItemMap, InputModuleItems}, |
14 | ty::{InferenceResult, Ty}, | 14 | ty::{InferenceResult, Ty}, |
15 | adt::{StructData, EnumData}, | 15 | adt::{StructData, EnumData}, |
16 | impl_block::ModuleImplBlocks, | 16 | impl_block::ModuleImplBlocks, |
@@ -71,9 +71,9 @@ pub trait HirDatabase: SyntaxDatabase | |||
71 | use fn query_definitions::file_item; | 71 | use fn query_definitions::file_item; |
72 | } | 72 | } |
73 | 73 | ||
74 | fn submodules(source: ModuleSource) -> Cancelable<Arc<Vec<crate::module::imp::Submodule>>> { | 74 | fn submodules(source: ModuleSource) -> Cancelable<Arc<Vec<crate::module_tree::Submodule>>> { |
75 | type SubmodulesQuery; | 75 | type SubmodulesQuery; |
76 | use fn query_definitions::submodules; | 76 | use fn crate::module_tree::Submodule::submodules_query; |
77 | } | 77 | } |
78 | 78 | ||
79 | fn input_module_items(source_root_id: SourceRootId, module_id: ModuleId) -> Cancelable<Arc<InputModuleItems>> { | 79 | fn input_module_items(source_root_id: SourceRootId, module_id: ModuleId) -> Cancelable<Arc<InputModuleItems>> { |
@@ -86,7 +86,7 @@ pub trait HirDatabase: SyntaxDatabase | |||
86 | } | 86 | } |
87 | fn module_tree(source_root_id: SourceRootId) -> Cancelable<Arc<ModuleTree>> { | 87 | fn module_tree(source_root_id: SourceRootId) -> Cancelable<Arc<ModuleTree>> { |
88 | type ModuleTreeQuery; | 88 | type ModuleTreeQuery; |
89 | use fn crate::module::imp::module_tree; | 89 | use fn crate::module_tree::ModuleTree::module_tree_query; |
90 | } | 90 | } |
91 | 91 | ||
92 | fn impls_in_module(source_root_id: SourceRootId, module_id: ModuleId) -> Cancelable<Arc<ModuleImplBlocks>> { | 92 | fn impls_in_module(source_root_id: SourceRootId, module_id: ModuleId) -> Cancelable<Arc<ModuleImplBlocks>> { |