5 files changed, 104 insertions, 52 deletions

diff --git a/docs/dev/README.md b/docs/dev/README.md
index 9c0af68e3..9b9b18102 100644
--- a/docs/dev/README.md
+++ b/docs/dev/README.md
@@ -114,6 +114,14 @@ npm run lint
 
 Do see [./style.md](./style.md).
 
+# How to ...
+
+* ... add an assist? [#7535](https://github.com/rust-analyzer/rust-analyzer/pull/7535)
+* ... add a new protocol extension? [#4569](https://github.com/rust-analyzer/rust-analyzer/pull/4569)
+* ... add a new configuration option? [#7451](https://github.com/rust-analyzer/rust-analyzer/pull/7451)
+* ... add a new completion? [#6964](https://github.com/rust-analyzer/rust-analyzer/pull/6964)
+* ... allow new syntax in the parser? [#7338](https://github.com/rust-analyzer/rust-analyzer/pull/7338)
+
 # Logging
 
 Logging is done by both rust-analyzer and VS Code, so it might be tricky to
diff --git a/docs/dev/architecture.md b/docs/dev/architecture.md
index feda20dd7..56ebaa3df 100644
--- a/docs/dev/architecture.md
+++ b/docs/dev/architecture.md
@@ -9,9 +9,9 @@ Yet another resource is this playlist with videos about various parts of the ana
 
 https://www.youtube.com/playlist?list=PL85XCvVPmGQho7MZkdW-wtPtuJcFpzycE
 
-Note that the guide and videos are pretty dated, this document should be in generally fresher.
+Note that the guide and videos are pretty dated, this document should be, in general, fresher.
 
-See also this implementation-oriented blog posts:
+See also these implementation-related blog posts:
 
 * https://rust-analyzer.github.io/blog/2019/11/13/find-usages.html
 * https://rust-analyzer.github.io/blog/2020/07/20/three-architectures-for-responsive-ide.html
@@ -27,9 +27,9 @@ On the highest level, rust-analyzer is a thing which accepts input source code f
 
 More specifically, input data consists of a set of test files (`(PathBuf, String)` pairs) and information about project structure, captured in the so called `CrateGraph`.
 The crate graph specifies which files are crate roots, which cfg flags are specified for each crate and what dependencies exist between the crates.
-This the input (ground) state.
+This is the input (ground) state.
 The analyzer keeps all this input data in memory and never does any IO.
-Because the input data are source code, which typically measures in tens of megabytes at most, keeping everything in memory is OK.
+Because the input data is source code, which typically measures in tens of megabytes at most, keeping everything in memory is OK.
 
 A "structured semantic model" is basically an object-oriented representation of modules, functions and types which appear in the source code.
 This representation is fully "resolved": all expressions have types, all references are bound to declarations, etc.
@@ -42,7 +42,7 @@ The underlying engine makes sure that model is computed lazily (on-demand) and c
 
 ## Code Map
 
-This section talks briefly about various important directories an data structures.
+This section talks briefly about various important directories and data structures.
 Pay attention to the **Architecture Invariant** sections.
 They often talk about things which are deliberately absent in the source code.
 
@@ -62,7 +62,7 @@ VS Code plugin.
 ### `libs/`
 
 rust-analyzer independent libraries which we publish to crates.io.
-It not heavily utilized at the moment.
+It's not heavily utilized at the moment.
 
 ### `crates/parser`
 
@@ -110,19 +110,19 @@ in particular: it shows off various methods of working with syntax tree.
 
 See [#93](https://github.com/rust-analyzer/rust-analyzer/pull/93) for an example PR which fixes a bug in the grammar.
 
-**Architecture Invariant:** `syntax` crate is completely independent from the rest of rust-analyzer, it knows nothing about salsa or LSP.
-This is important because it is possible to useful tooling using only syntax tree.
+**Architecture Invariant:** `syntax` crate is completely independent from the rest of rust-analyzer. It knows nothing about salsa or LSP.
+This is important because it is possible to make useful tooling using only the syntax tree.
 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.
 Using the tree as a store for semantic info is convenient in traditional compilers, but doesn't work nicely in the IDE.
 Specifically, assists and refactors require transforming syntax trees, and that becomes awkward if you need to do something with the semantic info.
 
-**Architecture Invariant:** syntax tree is build for a single file.
+**Architecture Invariant:** syntax tree is built for a single file.
 This is to enable parallel parsing of all files.
 
 **Architecture Invariant:**  Syntax trees are by design incomplete and do not enforce well-formedness.
@@ -131,7 +131,7 @@ If an AST method returns an `Option`, it *can* be `None` at runtime, even if thi
 ### `crates/base_db`
 
 We use the [salsa](https://github.com/salsa-rs/salsa) crate for incremental and on-demand computation.
-Roughly, you can think of salsa as a key-value store, but it also can compute derived values using specified functions. The `base_db` crate provides basic infrastructure for interacting with salsa.
+Roughly, you can think of salsa as a key-value store, but it can also compute derived values using specified functions. The `base_db` crate provides basic infrastructure for interacting with salsa.
 Crucially, it 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: everything else is strictly derived from those inputs.
 
@@ -160,11 +160,11 @@ These crates also define various intermediate representations of the core.
 
 `Body` stores information about expressions.
 
-**Architecture Invariant:** this crates are not, and will never be, an api boundary.
+**Architecture Invariant:** these crates are not, and will never be, an api boundary.
 
-**Architecture Invariant:** these creates explicitly care about being incremental.
+**Architecture Invariant:** these crates explicitly care about being incremental.
 The core invariant we maintain is "typing inside a function's body never invalidates global derived data".
-Ie, if you change body of `foo`, all facts about `bar` should remain intact.
+i.e., if you change the body of `foo`, all facts about `bar` should remain intact.
 
 **Architecture Invariant:** hir exists only in context of particular crate instance with specific CFG flags.
 The same syntax may produce several instances of HIR if the crate participates in the crate graph more than once.
@@ -188,24 +188,24 @@ We first resolve the parent _syntax_ node to the parent _hir_ element.
 Then we ask the _hir_ parent what _syntax_ children does it have.
 Then we look for our node in the set of children.
 
-This is the heart of many IDE features, like goto definition, which start with figuring out a hir node at the cursor.
+This is the heart of many IDE features, like goto definition, which start with figuring out the hir node at the cursor.
 This is some kind of (yet unnamed) uber-IDE pattern, as it is present in Roslyn and Kotlin as well.
 
 ### `crates/ide`
 
-The `ide` crate build's on top of `hir` semantic model to provide high-level IDE features like completion or goto definition.
+The `ide` crate builds on top of `hir` semantic model to provide high-level IDE features like completion or goto definition.
 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.
@@ -232,7 +232,7 @@ All other requests are processed in background.
 
 **Architecture Invariant:** the server is stateless, a-la HTTP.
 Sometimes state needs to be preserved between requests.
-For example, "what is the `edit` for the fifth's completion item of the last completion edit?".
+For example, "what is the `edit` for the fifth completion item of the last completion edit?".
 For this, the second request should include enough info to re-create the context from scratch.
 This generally means including all the parameters of the original request.
 
@@ -249,23 +249,28 @@ These crates deal with invoking `cargo` to learn about project structure and get
 They use `crates/path` heavily instead of `std::path`.
 A single `rust-analyzer` process can serve many projects, so it is important that server's current directory does not leak.
 
-### `crates/mbe`, `crated/tt`, `crates/proc_macro_api`, `crates/proc_macro_srv`
+### `crates/mbe`, `crates/tt`, `crates/proc_macro_api`, `crates/proc_macro_srv`
 
 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.
+These crates implement a virtual file system.
 They provide consistent snapshots of the underlying file system and insulate messy OS paths.
 
 **Architecture Invariant:** vfs doesn't assume a single unified file system.
-IE, a single rust-analyzer process can act as a remote server for two different machines, where the same `/tmp/foo.rs` path points to different files.
+i.e., a single rust-analyzer process can act as a remote server for two different machines, where the same `/tmp/foo.rs` path points to different files.
 For this reason, all path APIs generally take some existing path as a "file system witness".
 
 ### `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
@@ -314,7 +319,7 @@ That is, rust-analyzer requires unwinding.
 
 ### Testing
 
-Rust Analyzer has three interesting [systems boundaries](https://www.tedinski.com/2018/04/10/making-tests-a-positive-influence-on-design.html) to concentrate tests on.
+Rust Analyzer has three interesting [system boundaries](https://www.tedinski.com/2018/04/10/making-tests-a-positive-influence-on-design.html) to concentrate tests on.
 
 The outermost boundary is the `rust-analyzer` crate, which defines an LSP interface in terms of stdio.
 We do integration testing of this component, by feeding it with a stream of LSP requests and checking responses.
@@ -323,8 +328,8 @@ For this reason, we try to avoid writing too many tests on this boundary: in a s
 Heavy tests are only run when `RUN_SLOW_TESTS` env var is set.
 
 The middle, and most important, boundary is `ide`.
-Unlike `rust-analyzer`, which exposes API, `ide` uses Rust API and is intended to use by various tools.
-Typical test creates an `AnalysisHost`, calls some `Analysis` functions and compares the results against expectation.
+Unlike `rust-analyzer`, which exposes API, `ide` uses Rust API and is intended for use by various tools.
+A typical test creates an `AnalysisHost`, calls some `Analysis` functions and compares the results against expectation.
 
 The innermost and most elaborate boundary is `hir`.
 It has a much richer vocabulary of types than `ide`, but the basic testing setup is the same: we create a database, run some queries, assert result.
@@ -338,7 +343,7 @@ See the `marks` module in the `test_utils` crate for more.
 All required library code must be a part of the tests.
 This ensures fast test execution.
 
-**Architecture Invariant:** tests are data driven and do not test API.
+**Architecture Invariant:** tests are data driven and do not test the API.
 Tests which directly call various API functions are a liability, because they make refactoring the API significantly more complicated.
 So most of the tests look like this:
 
@@ -368,8 +373,48 @@ There's no additional checks in CI, formatting and tidy tests are run with `carg
 
 **Architecture Invariant:** tests do not depend on any kind of external resources, they are perfectly reproducible.
 
+### Error Handling
+
+**Architecture Invariant:** core parts of rust-analyzer (`ide`/`hir`) don't interact with the outside world and thus can't fail.
+Only parts touching LSP are allowed to do IO.
+
+Internals of rust-analyzer need to deal with broken code, but this is not an error condition.
+rust-analyzer is robust: various analysis compute `(T, Vec<Error>)` rather than `Result<T, Error>`.
+
+rust-analyzer is a complex long-running process.
+It will always have bugs and panics.
+But a panic in an isolated feature should not bring down the whole process.
+Each LSP-request is protected by a `catch_unwind`.
+We use `always` and `never` macros instead of `assert` to gracefully recover from impossible conditions.
+
 ### Observability
 
-I've run out of steam here :)
 rust-analyzer is a long-running process, so its important to understand what's going on inside.
-We have hierarchical profiler (`RA_PROFILER=1`) and object counting (`RA_COUNT=1`).
+We have several instruments for that.
+
+The event loop that runs rust-analyzer is very explicit.
+Rather than spawning futures or scheduling callbacks (open), the event loop accepts an `enum` of possible events (closed).
+It's easy to see all the things that trigger rust-analyzer processing, together with their performance
+
+rust-analyzer includes a simple hierarchical profiler (`hprof`).
+It is enabled with `RA_PROFILE='*>50` env var (log all (`*`) actions which take more than `50` ms) and produces output like:
+
+```
+85ms - handle_completion
+    68ms - import_on_the_fly
+        67ms - import_assets::search_for_relative_paths
+             0ms - crate_def_map:wait (804 calls)
+             0ms - find_path (16 calls)
+             2ms - find_similar_imports (1 calls)
+             0ms - generic_params_query (334 calls)
+            59ms - trait_solve_query (186 calls)
+         0ms - Semantics::analyze_impl (1 calls)
+         1ms - render_resolution (8 calls)
+     0ms - Semantics::analyze_impl (5 calls)
+```
+
+This is cheap enough to enable in production.
+
+
+Similarly, we save live object counting (`RA_COUNT=1`).
+It is not cheap enough to enable in prod, and this is a bug which should be fixed.
diff --git a/docs/dev/lsp-extensions.md b/docs/dev/lsp-extensions.md
index d7f287894..b2defa737 100644
--- a/docs/dev/lsp-extensions.md
+++ b/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`?
diff --git a/docs/dev/style.md b/docs/dev/style.md
index e2f1b6996..0482bc190 100644
--- a/docs/dev/style.md
+++ b/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
 
diff --git a/docs/dev/syntax.md b/docs/dev/syntax.md
index 1edafab68..737cc7a72 100644
--- a/docs/dev/syntax.md
+++ b/docs/dev/syntax.md
@@ -92,19 +92,18 @@ [email protected]
     [email protected] ")"
   [email protected] " "
   [email protected]
-    [email protected]
-      [email protected] "{"
-      [email protected] " "
-      [email protected]
-        [email protected]
-          [email protected] "90"
-        [email protected] " "
-        [email protected] "+"
-        [email protected] " "
-        [email protected]
-          [email protected] "2"
-      [email protected] " "
-      [email protected] "}"
+    [email protected] "{"
+    [email protected] " "
+    [email protected]
+      [email protected]
+        [email protected] "90"
+      [email protected] " "
+      [email protected] "+"
+      [email protected] " "
+      [email protected]
+        [email protected] "2"
+    [email protected] " "
+    [email protected] "}"
 ```
 
 #### 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