Without semantic information, you don't need to be able to _build_ code, which makes the tooling more robust.
See also https://web.stanford.edu/~mlfbrown/paper.pdf.
You can view the `syntax` crate as an entry point to rust-analyzer.
-`sytax` crate is an **API Boundary**.
+`syntax` crate is an **API Boundary**.
**Architecture Invariant:** syntax tree is a value type.
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.
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.
**Architecture Invariant:** `ide` crate's API is build out of POD types with public fields.
-The API uses editor's terminology, it talks about offsets and string labels rathe than in terms of definitions or types.
+The API uses editor's terminology, it talks about offsets and string labels rather than in terms of definitions or types.
It is effectively the view in MVC and viewmodel in [MVVM](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel).
All arguments and return types are conceptually serializable.
In particular, syntax tress and and hir types are generally absent from the API (but are used heavily in the implementation).
Shout outs to LSP developers for popularizing the idea that "UI" is a good place to draw a boundary at.
`ide` is also the first crate which has the notion of change over time.
-`AnalysisHost` is a state to which you can transactonally `apply_change`.
+`AnalysisHost` is a state to which you can transactionally `apply_change`.
`Analysis` is an immutable snapshot of the state.
Internally, `ide` is split across several crates. `ide_assists`, `ide_completion` and `ide_ssr` implement large isolated features.
These crates implement macros as token tree -> token tree transforms.
They are independent from the rest of the code.
+### `crates/cfg`
+
+This crate is responsible for parsing, evaluation and general definition of `cfg` attributes.
+
### `crates/vfs`, `crates/vfs-notify`
These crates implement a virtual fils system.
### `crates/stdx`
-This crate contains various non-rust-analyzer specific utils, which could have been in std.
+This crate contains various non-rust-analyzer specific utils, which could have been in std, as well
+as copies of unstable std items we would like to make use of already, like `std::str::split_once`.
### `crates/profile`
In particular, we generate:
-* API for working with syntax trees (`syntax::ast`, the `ungrammar` crate).
+* API for working with syntax trees (`syntax::ast`, the [`ungrammar`](https://github.com/rust-analyzer/ungrammar) crate).
* Various sections of the manual:
* features
* How to deal with synchronicity of the request?
One option is to require the client to block until the server returns the response.
Another option is to do a OT-style merging of edits from client and server.
- A third option is to do a record-replay: client applies heuristic on enter immediatelly, then applies all user's keypresses.
+ A third option is to do a record-replay: client applies heuristic on enter immediately, then applies all user's keypresses.
When the server is ready with the response, the client rollbacks all the changes and applies the recorded actions on top of the correct response.
* How to deal with multiple carets?
* Should we extend this to arbitrary typed events and not just `onEnter`?
```rust
// GOOD
-fn frbonicate(walrus: Walrus) {
+fn frobnicate(walrus: Walrus) {
...
}
```rust
// GOOD
-fn frbonicate(f: impl FnMut()) {
+fn frobnicate(f: impl FnMut()) {
frobnicate_impl(&mut f)
}
fn frobnicate_impl(f: &mut dyn FnMut()) {
}
// BAD
-fn frbonicate(f: impl FnMut()) {
+fn frobnicate(f: impl FnMut()) {
// lots of code
}
```
```rust
// GOOD
-fn frbonicate(f: &Path) {
+fn frobnicate(f: &Path) {
}
// BAD
-fn fr
bonicate(f: impl AsRef<Path>) {
+fn fr
obnicate(f: impl AsRef<Path>) {
}
```
}
```
-**Rationale:** reduce congnitive stack usage.
+**Rationale:** reduce cognitive stack usage.
## Comparisons
R_PAREN@5..6 ")"
WHITESPACE@6..7 " "
BLOCK_EXPR@7..17
- BLOCK@7..17
- L_CURLY@7..8 "{"
- WHITESPACE@8..9 " "
- BIN_EXPR@9..15
- LITERAL@9..11
- INT_NUMBER@9..11 "90"
- WHITESPACE@11..12 " "
- PLUS@12..13 "+"
- WHITESPACE@13..14 " "
- LITERAL@14..15
- INT_NUMBER@14..15 "2"
- WHITESPACE@15..16 " "
- R_CURLY@16..17 "}"
+ L_CURLY@7..8 "{"
+ WHITESPACE@8..9 " "
+ BIN_EXPR@9..15
+ LITERAL@9..11
+ INT_NUMBER@9..11 "90"
+ WHITESPACE@11..12 " "
+ PLUS@12..13 "+"
+ WHITESPACE@13..14 " "
+ LITERAL@14..15
+ INT_NUMBER@14..15 "2"
+ WHITESPACE@15..16 " "
+ R_CURLY@16..17 "}"
```
#### Optimizations
fn visibility(&self) -> Option<Visibility>;
}
-impl HasVisbility for FnDef {
+impl HasVisibility for FnDef {
fn visibility(&self) -> Option<Visibility> {
self.syntax.children().find_map(Visibility::cast)
}
### Parsing Algorithm
-We use a boring hand-crafted recursive descent + pratt combination, with a special effort of continuting the parsing if an error is detected.
+We use a boring hand-crafted recursive descent + pratt combination, with a special effort of continuing the parsing if an error is detected.
### Parser Recap
projects / rust.git / commitdiff