Fix spelling mistakes in docs/dev

docs/dev/architecture.md

@@ -115,7 +115,7 @@ This is important because it is possible to useful tooling using only syntax tre
 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.
@@ -198,14 +198,14 @@ It is an **API Boundary**.
 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.
@@ -254,6 +254,10 @@ A single `rust-analyzer` process can serve many projects, so it is important tha
 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.
@@ -265,7 +269,8 @@ For this reason, all path APIs generally take some existing path as a "file syst
 
 ### `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`
 
@@ -285,7 +290,7 @@ There are tests to check that the generated code is fresh.
 
 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

docs/dev/lsp-extensions.md

@@ -238,7 +238,7 @@ As proper cursor positioning is raison-d'etat for `onEnter`, it uses `SnippetTex
 * 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`?

docs/dev/style.md

@@ -159,7 +159,7 @@ Express function preconditions in types and force the caller to provide them (ra
 
 ```rust
 // GOOD
-fn frbonicate(walrus: Walrus) {
+fn frobnicate(walrus: Walrus) {
     ...
 }
 
@@ -374,7 +374,7 @@ Avoid making a lot of code type parametric, *especially* on the boundaries betwe
 
 ```rust
 // GOOD
-fn frbonicate(f: impl FnMut()) {
+fn frobnicate(f: impl FnMut()) {
     frobnicate_impl(&mut f)
 }
 fn frobnicate_impl(f: &mut dyn FnMut()) {
@@ -382,7 +382,7 @@ fn frobnicate_impl(f: &mut dyn FnMut()) {
 }
 
 // BAD
-fn frbonicate(f: impl FnMut()) {
+fn frobnicate(f: impl FnMut()) {
     // lots of code
 }
 ```
@@ -391,11 +391,11 @@ Avoid `AsRef` polymorphism, it pays back only for widely used libraries:
 
 ```rust
 // GOOD
-fn frbonicate(f: &Path) {
+fn frobnicate(f: &Path) {
 }
 
 // BAD
-fn frbonicate(f: impl AsRef<Path>) {
+fn frobnicate(f: impl AsRef<Path>) {
 }
 ```
 
@@ -705,7 +705,7 @@ fn foo() -> Option<Bar> {
 }
 ```
 
-**Rationale:** reduce congnitive stack usage.
+**Rationale:** reduce cognitive stack usage.
 
 ## Comparisons
 

docs/dev/syntax.md

@@ -92,19 +92,18 @@ FN@0..17
     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
@@ -387,7 +386,7 @@ trait HasVisibility: AstNode {
     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)
     }
@@ -527,7 +526,7 @@ In practice, incremental reparsing doesn't actually matter much for IDE use-case
 
 ### 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