diff options
author | Lukas Wirth <[email protected]> | 2021-02-03 12:40:24 +0000 |
---|---|---|
committer | Lukas Wirth <[email protected]> | 2021-02-03 12:46:51 +0000 |
commit | f82ce500a9c72a4153850f15e17b60388e95b2af (patch) | |
tree | bf5314dd20eb90e5b68872f11a5e0e269bcc8fe4 /docs/dev/architecture.md | |
parent | 81a9ad3672d547b2f5d265766bbb6c79909fb2da (diff) |
Fix spelling mistakes in docs/dev
Diffstat (limited to 'docs/dev/architecture.md')
-rw-r--r-- | docs/dev/architecture.md | 15 |
1 files changed, 10 insertions, 5 deletions
diff --git a/docs/dev/architecture.md b/docs/dev/architecture.md index feda20dd7..e97e082fc 100644 --- a/docs/dev/architecture.md +++ b/docs/dev/architecture.md | |||
@@ -115,7 +115,7 @@ This is important because it is possible to useful tooling using only syntax tre | |||
115 | Without semantic information, you don't need to be able to _build_ code, which makes the tooling more robust. | 115 | Without semantic information, you don't need to be able to _build_ code, which makes the tooling more robust. |
116 | See also https://web.stanford.edu/~mlfbrown/paper.pdf. | 116 | See also https://web.stanford.edu/~mlfbrown/paper.pdf. |
117 | You can view the `syntax` crate as an entry point to rust-analyzer. | 117 | You can view the `syntax` crate as an entry point to rust-analyzer. |
118 | `sytax` crate is an **API Boundary**. | 118 | `syntax` crate is an **API Boundary**. |
119 | 119 | ||
120 | **Architecture Invariant:** syntax tree is a value type. | 120 | **Architecture Invariant:** syntax tree is a value type. |
121 | The tree is fully determined by the contents of its syntax nodes, it doesn't need global context (like an interner) and doesn't store semantic info. | 121 | The tree is fully determined by the contents of its syntax nodes, it doesn't need global context (like an interner) and doesn't store semantic info. |
@@ -198,14 +198,14 @@ It is an **API Boundary**. | |||
198 | If you want to use IDE parts of rust-analyzer via LSP, custom flatbuffers-based protocol or just as a library in your text editor, this is the right API. | 198 | If you want to use IDE parts of rust-analyzer via LSP, custom flatbuffers-based protocol or just as a library in your text editor, this is the right API. |
199 | 199 | ||
200 | **Architecture Invariant:** `ide` crate's API is build out of POD types with public fields. | 200 | **Architecture Invariant:** `ide` crate's API is build out of POD types with public fields. |
201 | The API uses editor's terminology, it talks about offsets and string labels rathe than in terms of definitions or types. | 201 | The API uses editor's terminology, it talks about offsets and string labels rather than in terms of definitions or types. |
202 | It is effectively the view in MVC and viewmodel in [MVVM](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel). | 202 | It is effectively the view in MVC and viewmodel in [MVVM](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel). |
203 | All arguments and return types are conceptually serializable. | 203 | All arguments and return types are conceptually serializable. |
204 | In particular, syntax tress and and hir types are generally absent from the API (but are used heavily in the implementation). | 204 | In particular, syntax tress and and hir types are generally absent from the API (but are used heavily in the implementation). |
205 | Shout outs to LSP developers for popularizing the idea that "UI" is a good place to draw a boundary at. | 205 | Shout outs to LSP developers for popularizing the idea that "UI" is a good place to draw a boundary at. |
206 | 206 | ||
207 | `ide` is also the first crate which has the notion of change over time. | 207 | `ide` is also the first crate which has the notion of change over time. |
208 | `AnalysisHost` is a state to which you can transactonally `apply_change`. | 208 | `AnalysisHost` is a state to which you can transactionally `apply_change`. |
209 | `Analysis` is an immutable snapshot of the state. | 209 | `Analysis` is an immutable snapshot of the state. |
210 | 210 | ||
211 | Internally, `ide` is split across several crates. `ide_assists`, `ide_completion` and `ide_ssr` implement large isolated features. | 211 | Internally, `ide` is split across several crates. `ide_assists`, `ide_completion` and `ide_ssr` implement large isolated features. |
@@ -254,6 +254,10 @@ A single `rust-analyzer` process can serve many projects, so it is important tha | |||
254 | These crates implement macros as token tree -> token tree transforms. | 254 | These crates implement macros as token tree -> token tree transforms. |
255 | They are independent from the rest of the code. | 255 | They are independent from the rest of the code. |
256 | 256 | ||
257 | ### `crates/cfg` | ||
258 | |||
259 | This crate is responsible for parsing, evaluation and general definition of `cfg` attributes. | ||
260 | |||
257 | ### `crates/vfs`, `crates/vfs-notify` | 261 | ### `crates/vfs`, `crates/vfs-notify` |
258 | 262 | ||
259 | These crates implement a virtual fils system. | 263 | These crates implement a virtual fils system. |
@@ -265,7 +269,8 @@ For this reason, all path APIs generally take some existing path as a "file syst | |||
265 | 269 | ||
266 | ### `crates/stdx` | 270 | ### `crates/stdx` |
267 | 271 | ||
268 | This crate contains various non-rust-analyzer specific utils, which could have been in std. | 272 | This crate contains various non-rust-analyzer specific utils, which could have been in std, as well |
273 | as copies of unstable std items we would like to make use of already, like `std::str::split_once`. | ||
269 | 274 | ||
270 | ### `crates/profile` | 275 | ### `crates/profile` |
271 | 276 | ||
@@ -285,7 +290,7 @@ There are tests to check that the generated code is fresh. | |||
285 | 290 | ||
286 | In particular, we generate: | 291 | In particular, we generate: |
287 | 292 | ||
288 | * API for working with syntax trees (`syntax::ast`, the `ungrammar` crate). | 293 | * API for working with syntax trees (`syntax::ast`, the [`ungrammar`](https://github.com/rust-analyzer/ungrammar) crate). |
289 | * Various sections of the manual: | 294 | * Various sections of the manual: |
290 | 295 | ||
291 | * features | 296 | * features |