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/source_binder.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/source_binder.rs')
-rw-r--r-- | crates/ra_hir/src/source_binder.rs | 28 |
1 files changed, 20 insertions, 8 deletions
diff --git a/crates/ra_hir/src/source_binder.rs b/crates/ra_hir/src/source_binder.rs index 29a3960e9..b7e3ff9b0 100644 --- a/crates/ra_hir/src/source_binder.rs +++ b/crates/ra_hir/src/source_binder.rs | |||
@@ -13,11 +13,13 @@ use ra_syntax::{ | |||
13 | }; | 13 | }; |
14 | 14 | ||
15 | use crate::{ | 15 | use crate::{ |
16 | HirDatabase, Module, Function, SourceItemId, | 16 | HirDatabase, Function, SourceItemId, |
17 | module::ModuleSource, | 17 | module_tree::ModuleSource, |
18 | DefKind, DefLoc, AsName, | 18 | DefKind, DefLoc, AsName, |
19 | }; | 19 | }; |
20 | 20 | ||
21 | use crate::code_model_api::Module; | ||
22 | |||
21 | /// Locates the module by `FileId`. Picks topmost module in the file. | 23 | /// Locates the module by `FileId`. Picks topmost module in the file. |
22 | pub fn module_from_file_id(db: &impl HirDatabase, file_id: FileId) -> Cancelable<Option<Module>> { | 24 | pub fn module_from_file_id(db: &impl HirDatabase, file_id: FileId) -> Cancelable<Option<Module>> { |
23 | let module_source = ModuleSource::new_file(file_id.into()); | 25 | let module_source = ModuleSource::new_file(file_id.into()); |
@@ -34,7 +36,7 @@ pub fn module_from_declaration( | |||
34 | let child_name = decl.name(); | 36 | let child_name = decl.name(); |
35 | match (parent_module, child_name) { | 37 | match (parent_module, child_name) { |
36 | (Some(parent_module), Some(child_name)) => { | 38 | (Some(parent_module), Some(child_name)) => { |
37 | if let Some(child) = parent_module.child(&child_name.as_name()) { | 39 | if let Some(child) = parent_module.child(db, &child_name.as_name())? { |
38 | return Ok(Some(child)); | 40 | return Ok(Some(child)); |
39 | } | 41 | } |
40 | } | 42 | } |
@@ -84,7 +86,15 @@ fn module_from_source( | |||
84 | .modules_with_sources() | 86 | .modules_with_sources() |
85 | .find(|(_id, src)| src == &module_source); | 87 | .find(|(_id, src)| src == &module_source); |
86 | let module_id = ctry!(m).0; | 88 | let module_id = ctry!(m).0; |
87 | Ok(Some(Module::new(db, source_root_id, module_id)?)) | 89 | let def_loc = DefLoc { |
90 | kind: DefKind::Module, | ||
91 | source_root_id, | ||
92 | module_id, | ||
93 | source_item_id: module_source.0, | ||
94 | }; | ||
95 | let def_id = def_loc.id(db); | ||
96 | |||
97 | Ok(Some(Module::new(def_id))) | ||
88 | } | 98 | } |
89 | 99 | ||
90 | pub fn function_from_position( | 100 | pub fn function_from_position( |
@@ -114,7 +124,8 @@ pub fn function_from_module( | |||
114 | module: &Module, | 124 | module: &Module, |
115 | fn_def: ast::FnDef, | 125 | fn_def: ast::FnDef, |
116 | ) -> Function { | 126 | ) -> Function { |
117 | let file_id = module.source().file_id(); | 127 | let loc = module.def_id.loc(db); |
128 | let file_id = loc.source_item_id.file_id; | ||
118 | let file_items = db.file_items(file_id); | 129 | let file_items = db.file_items(file_id); |
119 | let item_id = file_items.id_of(file_id, fn_def.syntax()); | 130 | let item_id = file_items.id_of(file_id, fn_def.syntax()); |
120 | let source_item_id = SourceItemId { | 131 | let source_item_id = SourceItemId { |
@@ -123,8 +134,8 @@ pub fn function_from_module( | |||
123 | }; | 134 | }; |
124 | let def_loc = DefLoc { | 135 | let def_loc = DefLoc { |
125 | kind: DefKind::Function, | 136 | kind: DefKind::Function, |
126 | source_root_id: module.source_root_id, | 137 | source_root_id: loc.source_root_id, |
127 | module_id: module.module_id, | 138 | module_id: loc.module_id, |
128 | source_item_id, | 139 | source_item_id, |
129 | }; | 140 | }; |
130 | Function::new(def_loc.id(db)) | 141 | Function::new(def_loc.id(db)) |
@@ -147,7 +158,8 @@ pub fn macro_symbols( | |||
147 | Some(it) => it, | 158 | Some(it) => it, |
148 | None => return Ok(Vec::new()), | 159 | None => return Ok(Vec::new()), |
149 | }; | 160 | }; |
150 | let items = db.input_module_items(module.source_root_id, module.module_id)?; | 161 | let loc = module.def_id.loc(db); |
162 | let items = db.input_module_items(loc.source_root_id, loc.module_id)?; | ||
151 | let mut res = Vec::new(); | 163 | let mut res = Vec::new(); |
152 | 164 | ||
153 | for macro_call_id in items | 165 | for macro_call_id in items |