aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir/src/source_binder.rs
diff options
context:
space:
mode:
authorbors[bot] <bors[bot]@users.noreply.github.com>2019-01-06 14:51:10 +0000
committerbors[bot] <bors[bot]@users.noreply.github.com>2019-01-06 14:51:10 +0000
commitcf0ce14351af03c620aca784ee2c03aad86b866e (patch)
treebffd84981df9cca1143807796dc6772ddcfe8e0b /crates/ra_hir/src/source_binder.rs
parenteaf553dade9a28b41631387d7c88b09fd0ba64e2 (diff)
parent733383446fc229a35d4432d14c295c5a01e5a87f (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.rs28
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
15use crate::{ 15use 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
21use 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.
22pub fn module_from_file_id(db: &impl HirDatabase, file_id: FileId) -> Cancelable<Option<Module>> { 24pub 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
90pub fn function_from_position( 100pub 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