diff options
-rw-r--r-- | ARCHITECTURE.md | 46 |
1 files changed, 27 insertions, 19 deletions
diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index a6b1bf873..d920ce2ab 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md | |||
@@ -58,27 +58,25 @@ all `//test test_name` comments into files inside `tests/data` directory. | |||
58 | See [#93](https://github.com/rust-analyzer/rust-analyzer/pull/93) for an example PR which | 58 | See [#93](https://github.com/rust-analyzer/rust-analyzer/pull/93) for an example PR which |
59 | fixes a bug in the grammar. | 59 | fixes a bug in the grammar. |
60 | 60 | ||
61 | ### `crates/ra_hir` | 61 | ### `crates/ra_db` |
62 | |||
63 | HIR (previsouly known as descriptors) provides a high-level OO acess to Rust | ||
64 | code. | ||
65 | 62 | ||
66 | The principal difference between HIR and syntax trees is that HIR is bound | 63 | We use [salsa][https://github.com/salsa-rs/salsa] crate for incremental and |
67 | to a particular crate instance. That is, it has cfg flags and features | 64 | on-demand computation. Roughly, you can think of salsa as a key-value store, but |
68 | applied. So, there relation between syntax and HIR is many-to-one. | 65 | it also can compute derived values using specified functions. The `ra_db` crate |
66 | provides a basic infrastructure for interracting with salsa. Crucially, it | ||
67 | defines most of the "input" queries: facts supplied by the client of the analyzer. | ||
69 | 68 | ||
70 | ### `crates/ra_editor` | 69 | ### `crates/ra_hir` |
71 | 70 | ||
72 | All IDE features which can be implemented if you only have access to a | 71 | HIR provides a high-level "object oriented" acess to Rust code. |
73 | single file. `ra_editor` could be used to enhance editing of Rust code | ||
74 | without the need to fiddle with build-systems, file | ||
75 | synchronization and such. | ||
76 | 72 | ||
77 | In a sense, `ra_editor` is just a bunch of pure functions which take a | 73 | The principal difference between HIR and syntax trees is that HIR is bound to a |
78 | syntax tree as an input. | 74 | particular crate instance. That is, it has cfg flags and features applied (in |
75 | theory, in practice this is to be implemented). So, there relation between | ||
76 | syntax and HIR is many-to-one. The `source_binder` modules is responsible for | ||
77 | guessing a hir for a particular source position. | ||
79 | 78 | ||
80 | The tests for `ra_editor` are `#[cfg(test)] mod tests` unit-tests spread | 79 | Underneath, hir works on top of salsa, using a `HirDatabase` trait. |
81 | throughout its modules. | ||
82 | 80 | ||
83 | ### `crates/ra_analysis` | 81 | ### `crates/ra_analysis` |
84 | 82 | ||
@@ -88,9 +86,6 @@ current state, incorporates changes and handles out `Analysis` --- an | |||
88 | immutable consistent snapshot of world state at a point in time, which | 86 | immutable consistent snapshot of world state at a point in time, which |
89 | actually powers analysis. | 87 | actually powers analysis. |
90 | 88 | ||
91 | ### `crates/ra_db` | ||
92 | This defines basic database traits. Concrete DB is defined by ra_analysis. | ||
93 | |||
94 | ### `crates/ra_lsp_server` | 89 | ### `crates/ra_lsp_server` |
95 | 90 | ||
96 | An LSP implementation which uses `ra_analysis` for managing state and | 91 | An LSP implementation which uses `ra_analysis` for managing state and |
@@ -100,6 +95,19 @@ See [#79](https://github.com/rust-analyzer/rust-analyzer/pull/79/) as an | |||
100 | example of PR which adds a new feature to `ra_editor` and exposes it | 95 | example of PR which adds a new feature to `ra_editor` and exposes it |
101 | to `ra_lsp_server`. | 96 | to `ra_lsp_server`. |
102 | 97 | ||
98 | ### `crates/ra_editor` | ||
99 | |||
100 | All IDE features which can be implemented if you only have access to a | ||
101 | single file. `ra_editor` could be used to enhance editing of Rust code | ||
102 | without the need to fiddle with build-systems, file | ||
103 | synchronization and such. | ||
104 | |||
105 | In a sense, `ra_editor` is just a bunch of pure functions which take a | ||
106 | syntax tree as an input. | ||
107 | |||
108 | The tests for `ra_editor` are `#[cfg(test)] mod tests` unit-tests spread | ||
109 | throughout its modules. | ||
110 | |||
103 | ### `crates/gen_lsp_server` | 111 | ### `crates/gen_lsp_server` |
104 | 112 | ||
105 | A language server scaffold, exposing a synchronous crossbeam-channel based API. | 113 | A language server scaffold, exposing a synchronous crossbeam-channel based API. |