7 files changed, 117 insertions, 52 deletions

diff --git a/docs/dev/architecture.md b/docs/dev/architecture.md
index 0343b6c81..cee916c09 100644
--- a/docs/dev/architecture.md
+++ b/docs/dev/architecture.md
@@ -46,7 +46,7 @@ can be quickly updated for small modifications.
 
 Some of the components of this repository are generated through automatic
 processes. `cargo xtask codegen` runs all generation tasks. Generated code is
-commited to the git repository.
+committed to the git repository.
 
 In particular, `cargo xtask codegen` generates:
 
@@ -56,7 +56,7 @@ In particular, `cargo xtask codegen` generates:
 2. [`ast/generated`](https://github.com/rust-analyzer/rust-analyzer/blob/a0be39296d2925972cacd9fbf8b5fb258fad6947/crates/ra_syntax/src/ast/generated.rs)
   -- AST data structure.
 
-.3 [`doc_tests/generated`](https://github.com/rust-analyzer/rust-analyzer/blob/a0be39296d2925972cacd9fbf8b5fb258fad6947/crates/ra_assists/src/doc_tests/generated.rs),
+3. [`doc_tests/generated`](https://github.com/rust-analyzer/rust-analyzer/blob/a0be39296d2925972cacd9fbf8b5fb258fad6947/crates/ra_assists/src/doc_tests/generated.rs),
   [`test_data/parser/inline`](https://github.com/rust-analyzer/rust-analyzer/tree/a0be39296d2925972cacd9fbf8b5fb258fad6947/crates/ra_syntax/test_data/parser/inline)
   -- tests for assists and the parser.
 
@@ -114,7 +114,7 @@ is responsible for guessing a HIR for a particular source position.
 Underneath, HIR works on top of salsa, using a `HirDatabase` trait.
 
 `ra_hir_xxx` crates have a strong ECS flavor, in that they work with raw ids and
-directly query the databse.
+directly query the database.
 
 The top-level `ra_hir` façade crate wraps ids into a more OO-flavored API.
 
diff --git a/docs/dev/debugging.md b/docs/dev/debugging.md
index bece6a572..1aa392935 100644
--- a/docs/dev/debugging.md
+++ b/docs/dev/debugging.md
@@ -26,7 +26,7 @@ where **only** the `rust-analyzer` extension being debugged is enabled.
 - `Run Extension (Dev Server)` - runs extension with the locally built LSP server (`target/debug/rust-analyzer`).
 
 TypeScript debugging is configured to watch your source edits and recompile.
-To apply changes to an already running debug process press <kbd>Ctrl+Shift+P</kbd> and run the following command in your `[Extension Development Host]`
+To apply changes to an already running debug process, press <kbd>Ctrl+Shift+P</kbd> and run the following command in your `[Extension Development Host]`
 
 ```
 > Developer: Reload Window
@@ -76,11 +76,11 @@ Make sure you open a rust file in the `[Extension Development Host]` and try aga
 
 Make sure you have run `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope`.
 
-By default this should reset back to 1 everytime you log in.
+By default this should reset back to 1 every time you log in.
 
 ### Breakpoints are never being hit
 
-Check your version of `lldb` if it's version 6 and lower use the `classic` adapter type.
+Check your version of `lldb`. If it's version 6 and lower, use the `classic` adapter type.
 It's `lldb.adapterType` in settings file.
 
-If you're running `lldb` version 7 change the lldb adapter type to `bundled` or `native`.
+If you're running `lldb` version 7, change the lldb adapter type to `bundled` or `native`.
diff --git a/docs/dev/guide.md b/docs/dev/guide.md
index abbe4c154..c3252f1f6 100644
--- a/docs/dev/guide.md
+++ b/docs/dev/guide.md
@@ -26,7 +26,7 @@ properties hold:
 
 ## IDE API
 
-To see the bigger picture of how the IDE features works, let's take a look at the [`AnalysisHost`] and
+To see the bigger picture of how the IDE features work, let's take a look at the [`AnalysisHost`] and
 [`Analysis`] pair of types. `AnalysisHost` has three methods:
 
 * `default()` for creating an empty analysis instance
@@ -131,7 +131,7 @@ mapping between `SourceRoot` IDs (which are assigned by the client) and actual
 analyzer.
 
 Note that `mod`, `#[path]` and `include!()` can only reference files from the
-same source root. It is of course is possible to explicitly add extra files to
+same source root. It is of course possible to explicitly add extra files to
 the source root, even `/dev/random`.
 
 ## Language Server Protocol
@@ -192,7 +192,7 @@ task will be canceled as soon as the main loop calls `apply_change` on the
 [`schedule`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_lsp_server/src/main_loop.rs#L426-L455
 [The task]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_lsp_server/src/main_loop/handlers.rs#L205-L223
 
-This concludes the overview of the analyzer's programing *interface*. Next, lets
+This concludes the overview of the analyzer's programing *interface*. Next, let's
 dig into the implementation!
 
 ## Salsa
@@ -480,7 +480,7 @@ throughout the analyzer:
 ## Source Map pattern
 
 Due to an obscure edge case in completion, IDE needs to know the syntax node of
-an use statement which imported the given completion candidate. We can't just
+a use statement which imported the given completion candidate. We can't just
 store the syntax node as a part of name resolution: this will break
 incrementality, due to the fact that syntax changes after every file
 modification.
diff --git a/docs/dev/syntax.md b/docs/dev/syntax.md
index 4dd1de659..c2864bbbc 100644
--- a/docs/dev/syntax.md
+++ b/docs/dev/syntax.md
@@ -35,7 +35,7 @@ The syntax tree consists of three layers:
 * AST
 
 Of these, only GreenNodes store the actual data, the other two layers are (non-trivial) views into green tree.
-Red-green terminology comes from Roslyn ([link](https://docs.microsoft.com/en-ie/archive/blogs/ericlippert/persistence-facades-and-roslyns-red-green-trees)) and gives the name to the `rowan` library. Green and syntax nodes are defined in rowan, ast is defined in rust-analyzer.
+Red-green terminology comes from Roslyn ([link](https://ericlippert.com/2012/06/08/red-green-trees/)) and gives the name to the `rowan` library. Green and syntax nodes are defined in rowan, ast is defined in rust-analyzer.
 
 Syntax trees are a semi-transient data structure.
 In general, frontend does not keep syntax trees for all files in memory.
@@ -64,7 +64,7 @@ struct Token {
 }
 ```
 
-All the difference bettwen the above sketch and the real implementation are strictly due to optimizations.
+All the difference between the above sketch and the real implementation are strictly due to optimizations.
 
 Points of note:
 * The tree is untyped. Each node has a "type tag", `SyntaxKind`.
@@ -72,7 +72,7 @@ Points of note:
 * Trivia and non-trivia tokens are not distinguished on the type level.
 * Each token carries its full text.
 * The original text can be recovered by concatenating the texts of all tokens in order.
-* Accessing a child of particular type (for example, parameter list of a function) generarly involves linerary traversing the children, looking for a specific `kind`.
+* Accessing a child of particular type (for example, parameter list of a function) generally involves linerary traversing the children, looking for a specific `kind`.
 * Modifying the tree is roughly `O(depth)`.
   We don't make special efforts to guarantree that the depth is not liner, but, in practice, syntax trees are branchy and shallow.
 * If mandatory (grammar wise) node is missing from the input, it's just missing from the tree.
@@ -123,7 +123,7 @@ To more compactly store the children, we box *both* interior nodes and tokens, a
 `Either<Arc<Node>, Arc<Token>>` as a single pointer with a tag in the last bit.
 
 To avoid allocating EVERY SINGLE TOKEN on the heap, syntax trees use interning.
-Because the tree is fully imutable, it's valid to structuraly share subtrees.
+Because the tree is fully immutable, it's valid to structurally share subtrees.
 For example, in `1 + 1`, there will be a *single* token for `1` with ref count 2; the same goes for the ` ` whitespace token.
 Interior nodes are shared as well (for example in `(1 + 1) * (1 + 1)`).
 
@@ -134,8 +134,8 @@ Currently, the interner is created per-file, but it will be easy to use a per-th
 
 We use a `TextSize`, a newtyped `u32`, to store the length of the text.
 
-We currently use `SmolStr`, an small object optimized string to store text.
-This was mostly relevant *before* we implmented tree interning, to avoid allocating common keywords and identifiers. We should switch to storing text data alongside the interned tokens.
+We currently use `SmolStr`, a small object optimized string to store text.
+This was mostly relevant *before* we implemented tree interning, to avoid allocating common keywords and identifiers. We should switch to storing text data alongside the interned tokens.
 
 #### Alternative designs
 
@@ -162,12 +162,12 @@ Explicit trivia nodes, like in `rowan`, are used by IntelliJ.
 
 ##### Accessing Children
 
-As noted before, accesing a specific child in the node requires a linear traversal of the children (though we can skip tokens, beacuse the tag is encoded in the pointer itself).
+As noted before, accessing a specific child in the node requires a linear traversal of the children (though we can skip tokens, because the tag is encoded in the pointer itself).
 It is possible to recover O(1) access with another representation.
 We explicitly store optional and missing (required by the grammar, but not present) nodes.
 That is, we use `Option<Node>` for children.
 We also remove trivia tokens from the tree.
-This way, each child kind genrerally occupies a fixed position in a parent, and we can use index access to fetch it.
+This way, each child kind generally occupies a fixed position in a parent, and we can use index access to fetch it.
 The cost is that we now need to allocate space for all not-present optional nodes.
 So, `fn foo() {}` will have slots for visibility, unsafeness, attributes, abi and return type.
 
@@ -193,7 +193,7 @@ Modeling this with immutable trees is possible, but annoying.
 ### Syntax Nodes
 
 A function green tree is not super-convenient to use.
-The biggest problem is acessing parents (there are no parent pointers!).
+The biggest problem is accessing parents (there are no parent pointers!).
 But there are also "identify" issues.
 Let's say you want to write a code which builds a list of expressions in a file: `fn collect_exrepssions(file: GreenNode) -> HashSet<GreenNode>`.
 For the input like
@@ -207,7 +207,7 @@ fn main() {
 }
 ```
 
-both copies of the `x + 2` expression are representing by equal (and, with interning in mind, actualy the same) green nodes.
+both copies of the `x + 2` expression are representing by equal (and, with interning in mind, actually the same) green nodes.
 Green trees just can't differentiate between the two.
 
 `SyntaxNode` adds parent pointers and identify semantics to green nodes.
@@ -285,9 +285,9 @@ They also point to the parent (and, consequently, to the root) with an owning `R
 In other words, one needs *one* arc bump when initiating a traversal.
 
 To get rid of allocations, `rowan` takes advantage of `SyntaxNode: !Sync` and uses a thread-local free list of `SyntaxNode`s.
-In a typical traversal, you only directly hold a few `SyntaxNode`s at a time (and their ancesstors indirectly), so a free list proportional to the depth of the tree removes all allocations in a typical case.
+In a typical traversal, you only directly hold a few `SyntaxNode`s at a time (and their ancestors indirectly), so a free list proportional to the depth of the tree removes all allocations in a typical case.
 
-So, while traversal is not exactly incrementing a pointer, it's still prety cheep: tls + rc bump!
+So, while traversal is not exactly incrementing a pointer, it's still pretty cheap: TLS + rc bump!
 
 Traversal also yields (cheap) owned nodes, which improves ergonomics quite a bit.
 
@@ -308,15 +308,15 @@ struct SyntaxData {
 }
 ```
 
-This allows using true pointer equality for comparision of identities of `SyntaxNodes`.
-rust-analyzer used to have this design as well, but since we've switch to cursors.
-The main problem with memoizing the red nodes is that it more than doubles the memory requirenments for fully realized syntax trees.
+This allows using true pointer equality for comparison of identities of `SyntaxNodes`.
+rust-analyzer used to have this design as well, but we've since switched to cursors.
+The main problem with memoizing the red nodes is that it more than doubles the memory requirements for fully realized syntax trees.
 In contrast, cursors generally retain only a path to the root.
 C# combats increased memory usage by using weak references.
 
 ### AST
 
-`GreenTree`s are untyped and homogeneous, because it makes accomodating error nodes, arbitrary whitespace and comments natural, and because it makes possible to write generic tree traversals.
+`GreenTree`s are untyped and homogeneous, because it makes accommodating error nodes, arbitrary whitespace and comments natural, and because it makes possible to write generic tree traversals.
 However, when working with a specific node, like a function definition, one would want a strongly typed API.
 
 This is what is provided by the AST layer. AST nodes are transparent wrappers over untyped syntax nodes:
@@ -397,7 +397,7 @@ impl HasVisbility for FnDef {
 Points of note:
 
 * Like `SyntaxNode`s, AST nodes are cheap to clone pointer-sized owned values.
-* All "fields" are optional, to accomodate incomplete and/or erroneous source code.
+* All "fields" are optional, to accommodate incomplete and/or erroneous source code.
 * It's always possible to go from an ast node to an untyped `SyntaxNode`.
 * It's possible to go in the opposite direction with a checked cast.
 * `enum`s allow modeling of arbitrary intersecting subsets of AST types.
@@ -437,13 +437,13 @@ impl GreenNodeBuilder {
 }
 ```
 
-The parser, ultimatelly, needs to invoke the `GreenNodeBuilder`.
+The parser, ultimately, needs to invoke the `GreenNodeBuilder`.
 There are two principal sources of inputs for the parser:
   * source text, which contains trivia tokens (whitespace and comments)
   * token trees from macros, which lack trivia
 
-Additionaly, input tokens do not correspond 1-to-1 with output tokens.
-For example, two consequtive `>` tokens might be glued, by the parser, into a single `>>`.
+Additionally, input tokens do not correspond 1-to-1 with output tokens.
+For example, two consecutive `>` tokens might be glued, by the parser, into a single `>>`.
 
 For these reasons, the parser crate defines a callback interfaces for both input tokens and output trees.
 The explicit glue layer then bridges various gaps.
@@ -491,7 +491,7 @@ Syntax errors are not stored directly in the tree.
 The primary motivation for this is that syntax tree is not necessary produced by the parser, it may also be assembled manually from pieces (which happens all the time in refactorings).
 Instead, parser reports errors to an error sink, which stores them in a `Vec`.
 If possible, errors are not reported during parsing and are postponed for a separate validation step.
-For example, parser accepts visibility modifiers on trait methods, but then a separate tree traversal flags all such visibilites as erroneous.
+For example, parser accepts visibility modifiers on trait methods, but then a separate tree traversal flags all such visibilities as erroneous.
 
 ### Macros
 
@@ -501,7 +501,7 @@ Specifically, `TreeSink` constructs the tree in lockstep with draining the origi
 In the process, it records which tokens of the tree correspond to which tokens of the input, by using text ranges to identify syntax tokens.
 The end result is that parsing an expanded code yields a syntax tree and a mapping of text-ranges of the tree to original tokens.
 
-To deal with precedence in cases like `$expr * 1`, we use special invisible parenthesis, which are explicitelly handled by the parser
+To deal with precedence in cases like `$expr * 1`, we use special invisible parenthesis, which are explicitly handled by the parser
 
 ### Whitespace & Comments
 
diff --git a/docs/user/assists.md b/docs/user/assists.md
index 6c6943622..ee515949e 100644
--- a/docs/user/assists.md
+++ b/docs/user/assists.md
@@ -175,7 +175,9 @@ trait Trait<T> {
 }
 
 impl Trait<u32> for () {
-    fn foo(&self) -> u32 { todo!() }
+    fn foo(&self) -> u32 {
+        todo!()
+    }
 
 }
 ```
@@ -695,3 +697,21 @@ use std::┃collections::HashMap;
 // AFTER
 use std::{collections::HashMap};
 ```
+
+## `unwrap_block`
+
+This assist removes if...else, for, while and loop control statements to just keep the body.
+
+```rust
+// BEFORE
+fn foo() {
+    if true {┃
+        println!("foo");
+    }
+}
+
+// AFTER
+fn foo() {
+    println!("foo");
+}
+```
diff --git a/docs/user/features.md b/docs/user/features.md
index 56d2969fd..b9a365fc1 100644
--- a/docs/user/features.md
+++ b/docs/user/features.md
@@ -140,8 +140,8 @@ space or `;` depending on the return type of the function.
 When completing a function call, `()` are automatically inserted. If a function
 takes arguments, the cursor is positioned inside the parenthesis.
 
-There are postifx completions, which can be triggerd by typing something like
-`foo().if`. The word after `.` determines postifx completion. Possible variants are:
+There are postfix completions, which can be triggered by typing something like
+`foo().if`. The word after `.` determines postfix completion. Possible variants are:
 
 - `expr.if` -> `if expr {}`
 - `expr.match` -> `match expr {}`
diff --git a/docs/user/readme.adoc b/docs/user/readme.adoc
index ce5704836..69f5b13d6 100644
--- a/docs/user/readme.adoc
+++ b/docs/user/readme.adoc
@@ -23,7 +23,7 @@ https://github.com/rust-analyzer/rust-analyzer/blob/master/docs/user/readme.adoc
 
 == Installation
 
-In theory, one should be able to just install the server binary and have it automatically work with any editor.
+In theory, one should be able to just install the <<rust-analyzer-language-server-binary,`rust-analyzer` binary>> and have it automatically work with any editor.
 We are not there yet, so some editor specific setup is required.
 
 Additionally, rust-analyzer needs the sources of the standard library.
@@ -57,7 +57,11 @@ To disable this notification put the following to `settings.json`
 ----
 ====
 
-The server binary is stored in `~/.config/Code/User/globalStorage/matklad.rust-analyzer` (Linux) or in `~/.Library/Application Support/Code/User/globalStorage/matklad.rust-analyzer` (macOS) or in `%APPDATA%\Code\User\globalStorage` (Windows).
+The server binary is stored in:
+
+* Linux: `~/.config/Code/User/globalStorage/matklad.rust-analyzer`
+* macOS: `~/Library/Application Support/Code/User/globalStorage/matklad.rust-analyzer`
+* Windows: `%APPDATA%\Code\User\globalStorage`
 
 Note that we only support the latest version of VS Code.
 
@@ -108,15 +112,26 @@ Here are some useful self-diagnostic commands:
 * To log all LSP requests, add `"rust-analyzer.trace.server": "verbose"` to the settings and look for `Server Trace` in the panel.
 * To enable client-side logging, add `"rust-analyzer.trace.extension": true` to the settings and open the `Console` tab of VS Code developer tools.
 
-=== Language Server Binary
+=== rust-analyzer Language Server Binary
 
 Other editors generally require the `rust-analyzer` binary to be in `$PATH`.
-You can download the pre-built binary from the https://github.com/rust-analyzer/rust-analyzer/releases[releases] page. Typically, you then need to rename the binary for your platform, e.g. `rust-analyzer-mac` if you're on Mac OS, to `rust-analzyer` and make it executable in addition to moving it into a directory in your `$PATH`.
+You can download the pre-built binary from the https://github.com/rust-analyzer/rust-analyzer/releases[releases] page. Typically, you then need to rename the binary for your platform, e.g. `rust-analyzer-mac` if you're on Mac OS, to `rust-analyzer` and make it executable in addition to moving it into a directory in your `$PATH`.
+
+On Linux to install the `rust-analyzer` binary into `~/.local/bin`, this commands could be used
+
+[source,bash]
+----
+$ curl -L https://github.com/rust-analyzer/rust-analyzer/releases/latest/download/rust-analyzer-linux -o ~/.local/bin/rust-analyzer
+$ chmod +x ~/.local/bin/rust-analyzer
+----
+
+Ensure `~/.local/bin` is listed in the `$PATH` variable.
 
 Alternatively, you can install it from source using the following command:
 
 [source,bash]
 ----
+$ git clone https://github.com/rust-analyzer/rust-analyzer.git && cd rust-analyzer
 $ cargo xtask install --server
 ----
 
@@ -139,28 +154,34 @@ $ yay -S rust-analyzer-bin
 
 === Emacs
 
-Emacs support is maintained https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-rust.el[upstream].
+Prerequisites: You have installed the <<rust-analyzer-language-server-binary,`rust-analyzer` binary>>.
+
+Emacs support is maintained as part of the https://github.com/emacs-lsp/lsp-mode[Emacs-LSP] package in https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-rust.el[lsp-rust.el].
 
-1. Install the most recent version of `emacs-lsp` package by following the instructions https://github.com/emacs-lsp/lsp-mode[here].
+1. Install the most recent version of `emacs-lsp` package by following the https://github.com/emacs-lsp/lsp-mode[Emacs-LSP instructions].
 2. Set `lsp-rust-server` to `'rust-analyzer`.
 3. Run `lsp` in a Rust buffer.
 4. (Optionally) bind commands like `lsp-rust-analyzer-join-lines`, `lsp-extend-selection` and `lsp-rust-analyzer-expand-macro` to keys.
 
-=== Vim
+=== Vim/NeoVim
 
-The are several LSP client implementations for vim:
+Prerequisites: You have installed the <<rust-analyzer-language-server-binary,`rust-analyzer` binary>>. Not needed if the extension can install/update it on its own, coc-rust-analyzer is one example.
+
+The are several LSP client implementations for vim or neovim:
 
 ==== coc-rust-analyzer
 
 1. Install coc.nvim by following the instructions at
    https://github.com/neoclide/coc.nvim[coc.nvim]
-   (nodejs required)
+   (Node.js required)
 2. Run `:CocInstall coc-rust-analyzer` to install
    https://github.com/fannheyward/coc-rust-analyzer[coc-rust-analyzer],
    this extension implements _most_ of the features supported in the VSCode extension:
+   * automatically install and upgrade stable/nightly releases
    * same configurations as VSCode extension, `rust-analyzer.serverPath`, `rust-analyzer.cargo.features` etc.
    * same commands too, `rust-analyzer.analyzerStatus`, `rust-analyzer.ssr` etc.
-   * highlighting and inlay_hints are not implemented yet
+   * inlay hints for method chaining support, _Neovim Only_
+   * semantic highlighting is not implemented yet
 
 ==== LanguageClient-neovim
 
@@ -180,11 +201,11 @@ let g:LanguageClient_serverCommands = {
 ==== YouCompleteMe
 
 1. Install YouCompleteMe by following the instructions
-  https://ycm-core.github.io/YouCompleteMe/#rust-semantic-completion[here]
+  https://github.com/ycm-core/lsp-examples#rust-rust-analyzer[here]
 
 2. Configure by adding this to your vim/neovim config file (replacing the existing Rust-specific line if it exists):
 +
-[source,vim]   
+[source,vim]
 ----
 let g:ycm_language_server =
 \ [
@@ -197,6 +218,21 @@ let g:ycm_language_server =
 \ ]
 ----
 
+==== ALE
+
+To add the LSP server to https://github.com/dense-analysis/ale[ale]:
+
+[source,vim]
+----
+call ale#linter#Define('rust', {
+\   'name': 'rust-analyzer',
+\   'lsp': 'stdio',
+\   'executable': 'rust-analyzer',
+\   'command': '%e',
+\   'project_root': '.',
+\})
+----
+
 ==== nvim-lsp
 
 NeoVim 0.5 (not yet released) has built-in language server support.
@@ -205,7 +241,7 @@ Once `neovim/nvim-lsp` is installed, use `+lua require'nvim_lsp'.rust_analyzer.s
 
 === Sublime Text 3
 
-Prerequisites: You have installed the <<language-server-binary,`rust-analyzer` binary>>.
+Prerequisites: You have installed the <<rust-analyzer-language-server-binary,`rust-analyzer` binary>>.
 
 You also need the `LSP` package. To install it:
 
@@ -214,11 +250,20 @@ You also need the `LSP` package. To install it:
    * Type `Install Package Control`, press enter
 2. In the command palette, run `Package control: Install package`, and in the list that pops up, type `LSP` and press enter.
 
-Finally, with your Rust project open, in the command palette, run `LSP: Enable Language Server In Project` or `LSP: Enable Language Server Globally`, then select `rust-analyzer` in the list that pops up to enable the rust-analyzer LSP. The latter means that rust-analzyer is enabled by default in Rust projects.
+Finally, with your Rust project open, in the command palette, run `LSP: Enable Language Server In Project` or `LSP: Enable Language Server Globally`, then select `rust-analyzer` in the list that pops up to enable the rust-analyzer LSP. The latter means that rust-analyzer is enabled by default in Rust projects.
+
+If it worked, you should see "rust-analyzer, Line X, Column Y" on the left side of the bottom bar, and after waiting a bit, functionality like tooltips on hovering over variables should become available.
+
+If you get an error saying `No such file or directory: 'rust-analyzer'`, see the <<rust-analyzer-language-server-binary,`rust-analyzer` binary>> section on installing the language server binary.
+
+=== Gnome Builder
+
+Prerequisites: You have installed the <<rust-analyzer-language-server-binary,`rust-analyzer` binary>>.
 
-If it worked, you should see "rust-analzyer, Line X, Column Y" on the left side of the bottom bar, and after waiting a bit, functionality like tooltips on hovering over variables should become available.
+Gnome Builder currently has support for RLS, and there's no way to configure the language server executable. A future version might support `rust-analyzer` out of the box.
 
-If you get an error saying `No such file or directory: 'rust-analyzer'`, see the <<language-server-binary,section on installing the language server binary>>.
+1. Rename, symlink or copy the `rust-analyzer` binary to `rls` and place it somewhere Builder can find (in `PATH`, or under `~/.cargo/bin`).
+2. Enable the Rust Builder plugin.
 
 == Usage