Rename ra_hir -> hir

This commit is contained in:
Aleksey Kladov 2020-08-13 16:36:55 +02:00
parent 6a77ec7bbe
commit ae71a631fd
21 changed files with 61 additions and 62 deletions

46
Cargo.lock generated
View file

@ -463,6 +463,24 @@ dependencies = [
"libc", "libc",
] ]
[[package]]
name = "hir"
version = "0.0.0"
dependencies = [
"arrayvec",
"base_db",
"either",
"hir_def",
"hir_expand",
"hir_ty",
"itertools",
"log",
"profile",
"rustc-hash",
"stdx",
"syntax",
]
[[package]] [[package]]
name = "hir_def" name = "hir_def"
version = "0.0.0" version = "0.0.0"
@ -1071,9 +1089,9 @@ version = "0.1.0"
dependencies = [ dependencies = [
"base_db", "base_db",
"either", "either",
"hir",
"itertools", "itertools",
"profile", "profile",
"ra_hir",
"ra_ide_db", "ra_ide_db",
"rustc-hash", "rustc-hash",
"stdx", "stdx",
@ -1082,24 +1100,6 @@ dependencies = [
"text_edit", "text_edit",
] ]
[[package]]
name = "ra_hir"
version = "0.1.0"
dependencies = [
"arrayvec",
"base_db",
"either",
"hir_def",
"hir_expand",
"hir_ty",
"itertools",
"log",
"profile",
"rustc-hash",
"stdx",
"syntax",
]
[[package]] [[package]]
name = "ra_ide" name = "ra_ide"
version = "0.1.0" version = "0.1.0"
@ -1108,13 +1108,13 @@ dependencies = [
"cfg", "cfg",
"either", "either",
"expect", "expect",
"hir",
"indexmap", "indexmap",
"itertools", "itertools",
"log", "log",
"oorandom", "oorandom",
"profile", "profile",
"ra_assists", "ra_assists",
"ra_hir",
"ra_ide_db", "ra_ide_db",
"ra_ssr", "ra_ssr",
"rustc-hash", "rustc-hash",
@ -1131,10 +1131,10 @@ dependencies = [
"base_db", "base_db",
"either", "either",
"fst", "fst",
"hir",
"log", "log",
"once_cell", "once_cell",
"profile", "profile",
"ra_hir",
"rayon", "rayon",
"rustc-hash", "rustc-hash",
"stdx", "stdx",
@ -1149,7 +1149,7 @@ version = "0.1.0"
dependencies = [ dependencies = [
"base_db", "base_db",
"expect", "expect",
"ra_hir", "hir",
"ra_ide_db", "ra_ide_db",
"rustc-hash", "rustc-hash",
"syntax", "syntax",
@ -1236,6 +1236,7 @@ dependencies = [
"env_logger", "env_logger",
"expect", "expect",
"flycheck", "flycheck",
"hir",
"hir_def", "hir_def",
"hir_ty", "hir_ty",
"itertools", "itertools",
@ -1251,7 +1252,6 @@ dependencies = [
"proc_macro_srv", "proc_macro_srv",
"profile", "profile",
"project_model", "project_model",
"ra_hir",
"ra_ide", "ra_ide",
"ra_ide_db", "ra_ide_db",
"ra_ssr", "ra_ssr",

View file

@ -1,9 +1,9 @@
[package] [package]
edition = "2018" name = "hir"
name = "ra_hir" version = "0.0.0"
version = "0.1.0"
authors = ["rust-analyzer developers"]
license = "MIT OR Apache-2.0" license = "MIT OR Apache-2.0"
authors = ["rust-analyzer developers"]
edition = "2018"
[lib] [lib]
doctest = false doctest = false
@ -13,7 +13,6 @@ log = "0.4.8"
rustc-hash = "1.1.0" rustc-hash = "1.1.0"
either = "1.5.3" either = "1.5.3"
arrayvec = "0.5.1" arrayvec = "0.5.1"
itertools = "0.9.0" itertools = "0.9.0"
stdx = { path = "../stdx" } stdx = { path = "../stdx" }

View file

@ -9,11 +9,11 @@
//! It is written in "OO" style. Each type is self contained (as in, it knows it's //! It is written in "OO" style. Each type is self contained (as in, it knows it's
//! parents and full context). It should be "clean code". //! parents and full context). It should be "clean code".
//! //!
//! `ra_hir_*` crates are the implementation of the compiler logic. //! `hir_*` crates are the implementation of the compiler logic.
//! They are written in "ECS" style, with relatively little abstractions. //! They are written in "ECS" style, with relatively little abstractions.
//! Many types are not self-contained, and explicitly use local indexes, arenas, etc. //! Many types are not self-contained, and explicitly use local indexes, arenas, etc.
//! //!
//! `ra_hir` is what insulates the "we don't know how to actually write an incremental compiler" //! `hir` is what insulates the "we don't know how to actually write an incremental compiler"
//! from the ide with completions, hovers, etc. It is a (soft, internal) boundary: //! from the ide with completions, hovers, etc. It is a (soft, internal) boundary:
//! https://www.tedinski.com/2018/02/06/system-boundaries.html. //! https://www.tedinski.com/2018/02/06/system-boundaries.html.

View file

@ -20,5 +20,5 @@ text_edit = { path = "../text_edit" }
profile = { path = "../profile" } profile = { path = "../profile" }
base_db = { path = "../base_db" } base_db = { path = "../base_db" }
ra_ide_db = { path = "../ra_ide_db" } ra_ide_db = { path = "../ra_ide_db" }
hir = { path = "../ra_hir", package = "ra_hir" } hir = { path = "../hir" }
test_utils = { path = "../test_utils" } test_utils = { path = "../test_utils" }

View file

@ -33,7 +33,7 @@ ra_ssr = { path = "../ra_ssr" }
# ra_ide should depend only on the top-level `hir` package. if you need # ra_ide should depend only on the top-level `hir` package. if you need
# something from some `hir_xxx` subpackage, reexport the API via `hir`. # something from some `hir_xxx` subpackage, reexport the API via `hir`.
hir = { path = "../ra_hir", package = "ra_hir" } hir = { path = "../hir" }
[dev-dependencies] [dev-dependencies]
expect = { path = "../expect" } expect = { path = "../expect" }

View file

@ -3,7 +3,7 @@
//! Strings, suitable for displaying to the human. //! Strings, suitable for displaying to the human.
//! //!
//! What powers this API are the `RootDatabase` struct, which defines a `salsa` //! What powers this API are the `RootDatabase` struct, which defines a `salsa`
//! database, and the `ra_hir` crate, where majority of the analysis happens. //! database, and the `hir` crate, where majority of the analysis happens.
//! However, IDE specific bits of the analysis (most notably completion) happen //! However, IDE specific bits of the analysis (most notably completion) happen
//! in this crate. //! in this crate.

View file

@ -29,4 +29,4 @@ test_utils = { path = "../test_utils" }
# ra_ide should depend only on the top-level `hir` package. if you need # ra_ide should depend only on the top-level `hir` package. if you need
# something from some `hir_xxx` subpackage, reexport the API via `hir`. # something from some `hir_xxx` subpackage, reexport the API via `hir`.
hir = { path = "../ra_hir", package = "ra_hir" } hir = { path = "../hir" }

View file

@ -15,7 +15,7 @@ text_edit = { path = "../text_edit" }
syntax = { path = "../syntax" } syntax = { path = "../syntax" }
base_db = { path = "../base_db" } base_db = { path = "../base_db" }
ra_ide_db = { path = "../ra_ide_db" } ra_ide_db = { path = "../ra_ide_db" }
hir = { path = "../ra_hir", package = "ra_hir" } hir = { path = "../hir" }
rustc-hash = "1.1.0" rustc-hash = "1.1.0"
test_utils = { path = "../test_utils" } test_utils = { path = "../test_utils" }

View file

@ -49,7 +49,7 @@ toolchain = { path = "../toolchain" }
base_db = { path = "../base_db" } base_db = { path = "../base_db" }
ra_ide_db = { path = "../ra_ide_db" } ra_ide_db = { path = "../ra_ide_db" }
ra_ssr = { path = "../ra_ssr" } ra_ssr = { path = "../ra_ssr" }
hir = { path = "../ra_hir", package = "ra_hir" } hir = { path = "../hir" }
hir_def = { path = "../hir_def" } hir_def = { path = "../hir_def" }
hir_ty = { path = "../hir_ty" } hir_ty = { path = "../hir_ty" }
proc_macro_srv = { path = "../proc_macro_srv" } proc_macro_srv = { path = "../proc_macro_srv" }

View file

@ -148,14 +148,14 @@ Internal representations are lowered to LSP in the `rust-analyzer` crate (the on
## IDE/Compiler split ## IDE/Compiler split
There's a semi-hard split between "compiler" and "IDE", at the `ra_hir` crate. There's a semi-hard split between "compiler" and "IDE", at the `hir` crate.
Compiler derives new facts about source code. Compiler derives new facts about source code.
It explicitly acknowledges that not all info is available (i.e. you can't look at types during name resolution). It explicitly acknowledges that not all info is available (i.e. you can't look at types during name resolution).
IDE assumes that all information is available at all times. IDE assumes that all information is available at all times.
IDE should use only types from `ra_hir`, and should not depend on the underling compiler types. IDE should use only types from `hir`, and should not depend on the underling compiler types.
`ra_hir` is a facade. `hir` is a facade.
## IDE API ## IDE API

View file

@ -102,7 +102,7 @@ defines most of the "input" queries: facts supplied by the client of the
analyzer. Reading the docs of the `base_db::input` module should be useful: analyzer. Reading the docs of the `base_db::input` module should be useful:
everything else is strictly derived from those inputs. everything else is strictly derived from those inputs.
### `crates/ra_hir*` crates ### `crates/hir*` crates
HIR provides high-level "object oriented" access to Rust code. HIR provides high-level "object oriented" access to Rust code.
@ -113,10 +113,10 @@ is responsible for guessing a HIR for a particular source position.
Underneath, HIR works on top of salsa, using a `HirDatabase` trait. Underneath, HIR works on top of salsa, using a `HirDatabase` trait.
`ra_hir_xxx` crates have a strong ECS flavor, in that they work with raw ids and `hir_xxx` crates have a strong ECS flavor, in that they work with raw ids and
directly query the database. directly query the database.
The top-level `ra_hir` façade crate wraps ids into a more OO-flavored API. The top-level `hir` façade crate wraps ids into a more OO-flavored API.
### `crates/ra_ide` ### `crates/ra_ide`

View file

@ -275,7 +275,7 @@ several times, with different sets of `cfg`s enabled. The IDE-specific task of
mapping source code position into a semantic model is inherently imprecise for mapping source code position into a semantic model is inherently imprecise for
this reason, and is handled by the [`source_binder`]. this reason, and is handled by the [`source_binder`].
[`source_binder`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/source_binder.rs [`source_binder`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/source_binder.rs
The semantic interface is declared in the [`code_model_api`] module. Each entity is The semantic interface is declared in the [`code_model_api`] module. Each entity is
identified by an integer ID and has a bunch of methods which take a salsa database identified by an integer ID and has a bunch of methods which take a salsa database
@ -283,8 +283,8 @@ as an argument and returns other entities (which are also IDs). Internally, thes
methods invoke various queries on the database to build the model on demand. methods invoke various queries on the database to build the model on demand.
Here's [the list of queries]. Here's [the list of queries].
[`code_model_api`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/code_model_api.rs [`code_model_api`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/code_model_api.rs
[the list of queries]: https://github.com/rust-analyzer/rust-analyzer/blob/7e84440e25e19529e4ff8a66e521d1b06349c6ec/crates/ra_hir/src/db.rs#L20-L106 [the list of queries]: https://github.com/rust-analyzer/rust-analyzer/blob/7e84440e25e19529e4ff8a66e521d1b06349c6ec/crates/hir/src/db.rs#L20-L106
The first step of building the model is parsing the source code. The first step of building the model is parsing the source code.
@ -341,7 +341,7 @@ The algorithm for building a tree of modules is to start with a crate root
declarations and recursively process child modules. This is handled by the declarations and recursively process child modules. This is handled by the
[`module_tree_query`], with two slight variations. [`module_tree_query`], with two slight variations.
[`module_tree_query`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/module_tree.rs#L116-L123 [`module_tree_query`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/module_tree.rs#L116-L123
First, rust-analyzer builds a module tree for all crates in a source root First, rust-analyzer builds a module tree for all crates in a source root
simultaneously. The main reason for this is historical (`module_tree` predates simultaneously. The main reason for this is historical (`module_tree` predates
@ -364,7 +364,7 @@ the same, we don't have to re-execute [`module_tree_query`]. In fact, we only
need to re-execute it when we add/remove new files or when we change mod need to re-execute it when we add/remove new files or when we change mod
declarations. declarations.
[`submodules_query`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/module_tree.rs#L41 [`submodules_query`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/module_tree.rs#L41
We store the resulting modules in a `Vec`-based indexed arena. The indices in We store the resulting modules in a `Vec`-based indexed arena. The indices in
the arena becomes module IDs. And this brings us to the next topic: the arena becomes module IDs. And this brings us to the next topic:
@ -393,7 +393,7 @@ database we use includes a couple of [interners]. How to "garbage collect"
unused locations is an open question. unused locations is an open question.
[`LocationInterner`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/base_db/src/loc2id.rs#L65-L71 [`LocationInterner`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/base_db/src/loc2id.rs#L65-L71
[interners]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/db.rs#L22-L23 [interners]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/db.rs#L22-L23
For example, we use `LocationInterner` to assign IDs to definitions of functions, For example, we use `LocationInterner` to assign IDs to definitions of functions,
structs, enums, etc. The location, [`DefLoc`] contains two bits of information: structs, enums, etc. The location, [`DefLoc`] contains two bits of information:
@ -407,7 +407,7 @@ using offsets, text ranges or syntax trees as keys and values for queries. What
we do instead is we store "index" of the item among all of the items of a file we do instead is we store "index" of the item among all of the items of a file
(so, a positional based ID, but localized to a single file). (so, a positional based ID, but localized to a single file).
[`DefLoc`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/ids.rs#L127-L139 [`DefLoc`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/ids.rs#L127-L139
One thing we've glossed over for the time being is support for macros. We have One thing we've glossed over for the time being is support for macros. We have
only proof of concept handling of macros at the moment, but they are extremely only proof of concept handling of macros at the moment, but they are extremely
@ -440,7 +440,7 @@ terms of `HirFileId`! This does not recur infinitely though: any chain of
`HirFileId`s bottoms out in `HirFileId::FileId`, that is, some source file `HirFileId`s bottoms out in `HirFileId::FileId`, that is, some source file
actually written by the user. actually written by the user.
[`HirFileId`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/ids.rs#L18-L125 [`HirFileId`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/ids.rs#L18-L125
Now that we understand how to identify a definition, in a source or in a Now that we understand how to identify a definition, in a source or in a
macro-generated file, we can discuss name resolution a bit. macro-generated file, we can discuss name resolution a bit.
@ -454,14 +454,14 @@ each module into a position-independent representation which does not change if
we modify bodies of the items. After that we [loop] resolving all imports until we modify bodies of the items. After that we [loop] resolving all imports until
we've reached a fixed point. we've reached a fixed point.
[lower]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/nameres/lower.rs#L113-L117 [lower]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/nameres/lower.rs#L113-L117
[loop]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/nameres.rs#L186-L196 [loop]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/nameres.rs#L186-L196
And, given all our preparation with IDs and a position-independent representation, And, given all our preparation with IDs and a position-independent representation,
it is satisfying to [test] that typing inside function body does not invalidate it is satisfying to [test] that typing inside function body does not invalidate
name resolution results. name resolution results.
[test]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/nameres/tests.rs#L376 [test]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/nameres/tests.rs#L376
An interesting fact about name resolution is that it "erases" all of the An interesting fact about name resolution is that it "erases" all of the
intermediate paths from the imports: in the end, we know which items are defined intermediate paths from the imports: in the end, we know which items are defined
@ -496,10 +496,10 @@ there's an intermediate [projection query] which returns only the first
position-independent part of the lowering. The result of this query is stable. position-independent part of the lowering. The result of this query is stable.
Naturally, name resolution [uses] this stable projection query. Naturally, name resolution [uses] this stable projection query.
[imports]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/nameres/lower.rs#L52-L59 [imports]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/nameres/lower.rs#L52-L59
[`SourceMap`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/nameres/lower.rs#L52-L59 [`SourceMap`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/nameres/lower.rs#L52-L59
[projection query]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/nameres/lower.rs#L97-L103 [projection query]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/nameres/lower.rs#L97-L103
[uses]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/query_definitions.rs#L49 [uses]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/query_definitions.rs#L49
## Type inference ## Type inference
@ -521,10 +521,10 @@ construct a mapping from `ExprId`s to types.
[@flodiebold]: https://github.com/flodiebold [@flodiebold]: https://github.com/flodiebold
[#327]: https://github.com/rust-analyzer/rust-analyzer/pull/327 [#327]: https://github.com/rust-analyzer/rust-analyzer/pull/327
[lower the AST]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/expr.rs [lower the AST]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/expr.rs
[positional ID]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/expr.rs#L13-L15 [positional ID]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/expr.rs#L13-L15
[a source map]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/expr.rs#L41-L44 [a source map]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/expr.rs#L41-L44
[type inference]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/ty.rs#L1208-L1223 [type inference]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/hir/src/ty.rs#L1208-L1223
## Tying it all together: completion ## Tying it all together: completion

View file

@ -192,7 +192,7 @@ impl TidyDocs {
} }
let poorly_documented = [ let poorly_documented = [
"ra_hir", "hir",
"hir_expand", "hir_expand",
"ra_ide", "ra_ide",
"mbe", "mbe",