5 files changed, 28 insertions, 25 deletions

diff --git a/docs/dev/README.md b/docs/dev/README.md
index d6fae5295..b91013f13 100644
--- a/docs/dev/README.md
+++ b/docs/dev/README.md
@@ -58,8 +58,6 @@ Use `env RUN_SLOW_TESTS=1 cargo test` to run the full suite.
 
 We use bors-ng to enforce the [not rocket science](https://graydon2.dreamwidth.org/1597.html) rule.
 
-You can run `cargo xtask install-pre-commit-hook` to install git-hook to run rustfmt on commit.
-
 # Launching rust-analyzer
 
 Debugging the language server can be tricky.
diff --git a/docs/dev/architecture.md b/docs/dev/architecture.md
index ead12616e..fb991133a 100644
--- a/docs/dev/architecture.md
+++ b/docs/dev/architecture.md
@@ -46,7 +46,7 @@ This is *the* entry point, but it front-loads a lot of complexity, so its fine t
 
 `crates/rust-analyzer/src/handlers.rs` implements all LSP requests and is a great place to start if you are already familiar with LSP.
 
-`Analysis` and `AnalysisHost` types define the main API.
+`Analysis` and `AnalysisHost` types define the main API for consumers of IDE services.
 
 ## Code Map
 
@@ -97,13 +97,13 @@ See [RFC](https://github.com/rust-lang/rfcs/pull/2256) and [./syntax.md](./synta
 
 - [rowan](https://github.com/rust-analyzer/rowan) library is used for constructing syntax trees.
 - `ast` provides a type safe API on top of the raw `rowan` tree.
-- `ungrammar` description of the grammar, which is used to generate `syntax_kinds` and `ast` modules, using `cargo xtask codegen` command.
+- `ungrammar` description of the grammar, which is used to generate `syntax_kinds` and `ast` modules, using `cargo test -p xtask` command.
 
 Tests for ra_syntax are mostly data-driven.
 `test_data/parser` contains subdirectories with a bunch of `.rs` (test vectors) and `.txt` files with corresponding syntax trees.
 During testing, we check `.rs` against `.txt`.
 If the `.txt` file is missing, it is created (this is how you update tests).
-Additionally, running `cargo xtask codegen` will walk the grammar module and collect all `// test test_name` comments into files inside `test_data/parser/inline` directory.
+Additionally, running the xtask test suite with `cargo test -p xtask` will walk the grammar module and collect all `// test test_name` comments into files inside `test_data/parser/inline` directory.
 
 To update test data, run with `UPDATE_EXPECT` variable:
 
@@ -111,7 +111,7 @@ To update test data, run with `UPDATE_EXPECT` variable:
 env UPDATE_EXPECT=1 cargo qt
 ```
 
-After adding a new inline test you need to run `cargo xtest codegen` and also update the test data as described above.
+After adding a new inline test you need to run `cargo test -p xtask` and also update the test data as described above.
 
 Note  [`api_walkthrough`](https://github.com/rust-analyzer/rust-analyzer/blob/2fb6af89eb794f775de60b82afe56b6f986c2a40/crates/ra_syntax/src/lib.rs#L190-L348)
 in particular: it shows off various methods of working with syntax tree.
@@ -308,9 +308,8 @@ This sections talks about the things which are everywhere and nowhere in particu
 ### Code generation
 
 Some of the components of this repository are generated through automatic processes.
-`cargo xtask codegen` runs all generation tasks.
+Generated code is updated automatically on `cargo test`.
 Generated code is generally committed to the git repository.
-There are tests to check that the generated code is fresh.
 
 In particular, we generate:
 
diff --git a/docs/dev/guide.md b/docs/dev/guide.md
index b5a5d7c93..c1a55c56c 100644
--- a/docs/dev/guide.md
+++ b/docs/dev/guide.md
@@ -65,11 +65,11 @@ Next, let's talk about what the inputs to the `Analysis` are, precisely.
 
 Rust Analyzer never does any I/O itself, all inputs get passed explicitly via
 the `AnalysisHost::apply_change` method, which accepts a single argument, a
-`AnalysisChange`. [`AnalysisChange`] is a builder for a single change
+`Change`. [`Change`] is a builder for a single change
 "transaction", so it suffices to study its methods to understand all of the
 input data.
 
-[`AnalysisChange`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ide_api/src/lib.rs#L119-L167
+[`Change`]: https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/base_db/src/change.rs#L14-L89
 
 The `(add|change|remove)_file` methods control the set of the input files, where
 each file has an integer id (`FileId`, picked by the client), text (`String`)
@@ -158,7 +158,7 @@ it should be possible to dynamically reconfigure it later without restart.
 [main_loop.rs#L62-L70](https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_lsp_server/src/main_loop.rs#L62-L70)
 
 The [`ProjectModel`] we get after this step is very Cargo and sysroot specific,
-it needs to be lowered to get the input in the form of `AnalysisChange`. This
+it needs to be lowered to get the input in the form of `Change`. This
 happens in [`ServerWorldState::new`] method. Specifically
 
 * Create a `SourceRoot` for each Cargo package and sysroot.
@@ -175,7 +175,7 @@ of the main loop, just like any other change. Here's where we handle:
 * [File system changes](https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_lsp_server/src/main_loop.rs#L194)
 * [Changes from the editor](https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_lsp_server/src/main_loop.rs#L377)
 
-After a single loop's turn, we group the changes into one `AnalysisChange` and
+After a single loop's turn, we group the changes into one `Change` and
 [apply] it. This always happens on the main thread and blocks the loop.
 
 [apply]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_lsp_server/src/server_world.rs#L216
@@ -256,7 +256,7 @@ database.
 [`RootDatabase`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ide_api/src/db.rs#L88-L134
 
 Salsa input queries are defined in [`FilesDatabase`] (which is a part of
-`RootDatabase`). They closely mirror the familiar `AnalysisChange` structure:
+`RootDatabase`). They closely mirror the familiar `Change` structure:
 indeed, what `apply_change` does is it sets the values of input queries.
 
 [`FilesDatabase`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/base_db/src/input.rs#L150-L174
diff --git a/docs/dev/lsp-extensions.md b/docs/dev/lsp-extensions.md
index 6c34c4021..694fafcd5 100644
--- a/docs/dev/lsp-extensions.md
+++ b/docs/dev/lsp-extensions.md
@@ -39,7 +39,7 @@ If a language client does not know about `rust-analyzer`'s configuration options
 
 **Issue:** https://github.com/microsoft/language-server-protocol/issues/724
 
-**Client Capability:** `{ "snippetTextEdit": boolean }`
+**Experimental Client Capability:** `{ "snippetTextEdit": boolean }`
 
 If this capability is set, `WorkspaceEdit`s returned from `codeAction` requests might contain `SnippetTextEdit`s instead of usual `TextEdit`s:
 
@@ -72,7 +72,7 @@ At the moment, rust-analyzer guarantees that only a single edit will have `Inser
 
 **Issue:** https://github.com/microsoft/language-server-protocol/issues/994
 
-**Client Capability:** `{ "codeActionGroup": boolean }`
+**Experimental Client Capability:** `{ "codeActionGroup": boolean }`
 
 If this capability is set, `CodeAction` returned from the server contain an additional field, `group`:
 
@@ -119,7 +119,7 @@ Invoking code action at this position will yield two code actions for importing
 
 **Issue:** https://github.com/microsoft/language-server-protocol/issues/1002
 
-**Server Capability:** `{ "parentModule": boolean }`
+**Experimental Server Capability:** `{ "parentModule": boolean }`
 
 This request is sent from client to server to handle "Goto Parent Module" editor action.
 
@@ -153,7 +153,7 @@ mod foo;
 
 **Issue:** https://github.com/microsoft/language-server-protocol/issues/992
 
-**Server Capability:** `{ "joinLines": boolean }`
+**Experimental Server Capability:** `{ "joinLines": boolean }`
 
 This request is sent from client to server to handle "Join Lines" editor action.
 
@@ -200,7 +200,7 @@ fn main() {
 
 **Issue:** https://github.com/microsoft/language-server-protocol/issues/1001
 
-**Server Capability:** `{ "onEnter": boolean }`
+**Experimental Server Capability:** `{ "onEnter": boolean }`
 
 This request is sent from client to server to handle <kbd>Enter</kbd> keypress.
 
@@ -251,7 +251,7 @@ As proper cursor positioning is raison-d'etat for `onEnter`, it uses `SnippetTex
 
 ## Structural Search Replace (SSR)
 
-**Server Capability:** `{ "ssr": boolean }`
+**Experimental Server Capability:** `{ "ssr": boolean }`
 
 This request is sent from client to server to handle structural search replace -- automated syntax tree based transformation of the source.
 
@@ -293,7 +293,7 @@ SSR with query `foo($a, $b) ==>> ($a).foo($b)` will transform, eg `foo(y + 5, z)
 
 **Issue:** https://github.com/microsoft/language-server-protocol/issues/999
 
-**Server Capability:** `{ "matchingBrace": boolean }`
+**Experimental Server Capability:** `{ "matchingBrace": boolean }`
 
 This request is sent from client to server to handle "Matching Brace" editor action.
 
@@ -338,7 +338,7 @@ Moreover, it would be cool if editors didn't need to implement even basic langua
 
 **Issue:** https://github.com/microsoft/language-server-protocol/issues/944
 
-**Server Capability:** `{ "runnables": { "kinds": string[] } }`
+**Experimental Server Capability:** `{ "runnables": { "kinds": string[] } }`
 
 This request is sent from client to server to get the list of things that can be run (tests, binaries, `cargo check -p`).
 
@@ -421,7 +421,7 @@ Reloads project information (that is, re-executes `cargo metadata`).
 
 ## Status Notification
 
-**Client Capability:** `{ "statusNotification": boolean }`
+**Experimental Client Capability:** `{ "statusNotification": boolean }`
 
 **Method:** `rust-analyzer/status`
 
@@ -519,7 +519,7 @@ interface InlayHint {
 
 ## Hover Actions
 
-**Client Capability:** `{ "hoverActions": boolean }`
+**Experimental Client Capability:** `{ "hoverActions": boolean }`
 
 If this capability is set, `Hover` request returned from the server might contain an additional field, `actions`:
 
diff --git a/docs/dev/style.md b/docs/dev/style.md
index dd71e3932..46bd8b9b2 100644
--- a/docs/dev/style.md
+++ b/docs/dev/style.md
@@ -145,7 +145,7 @@ Formatting ensures that you can use your editor's "number of selected characters
 ## Marked Tests
 
 Use
-[`mark::hit! / mark::check!`](https://github.com/rust-analyzer/rust-analyzer/blob/71fe719dd5247ed8615641d9303d7ca1aa201c2f/crates/test_utils/src/mark.rs)
+[`cov_mark::hit! / cov_mark::check!`](https://github.com/matklad/cov-mark)
 when testing specific conditions.
 Do not place several marks into a single test or condition.
 Do not reuse marks between several tests.
@@ -769,14 +769,20 @@ fn foo() -> Option<Bar> {
 
 ## Comparisons
 
-Use `<`/`<=`, avoid `>`/`>=`.
+When doing multiple comparisons use `<`/`<=`, avoid `>`/`>=`.
 
 ```rust
 // GOOD
 assert!(lo <= x && x <= hi);
+assert!(r1 < l2 || r2 < l1);
+assert!(x < y);
+assert!(x > 0);
 
 // BAD
 assert!(x >= lo && x <= hi>);
+assert!(r1 < l2 || l1 > r2);
+assert!(y > x);
+assert!(0 > x);
 ```
 
 **Rationale:** Less-then comparisons are more intuitive, they correspond spatially to [real line](https://en.wikipedia.org/wiki/Real_line).