Repository for the Rust Language Server (aka RLS)


Build Status

Rust Language Server (RLS)

The RLS provides a server that runs in the background, providing IDEs, editors, and other tools with information about Rust programs. It supports functionality such as 'goto definition', symbol search, reformatting, and code completion, and enables renaming and refactorings.

A high-level overview of the architecture can be found here.

The RLS gets its source data from the compiler and from Racer. Where possible it uses data from the compiler which is precise and complete. Where it is not possible, (for example for code completion and where building is too slow), it uses Racer.

Since the Rust compiler does not yet support end-to-end incremental compilation, we can't offer a perfect experience. However, by optimising our use of the compiler and falling back to Racer, we can offer a pretty good experience for small to medium sized crates. As the RLS and compiler evolve, we'll offer a better experience for larger and larger crates.

The RLS is designed to be frontend-independent. We hope it will be widely adopted by different editors and IDEs. To seed development, we provide a reference implementation of an RLS frontend for Visual Studio Code.


Step 1: Install rustup

You can install rustup on many platforms. This will help us quickly install the RLS and its dependencies.

If you already have rustup installed, update to ensure you have the latest rustup and compiler:

rustup update

If you're going to use the VSCode extension, you can skip step 2.

Step 2: Install the RLS

Once you have rustup installed, run the following commands:

rustup component add rls rust-analysis rust-src

error: component 'rls' is unavailable for download (nightly)

The development of rustc's internals is quite fast paced. Downstream projects that rely on nightly internals, particularly clippy, can break fairly often because of this.

When such breakages occur the nightly release will be missing rls. This is a trade-off compared with the other option of just not publishing the night's release, but does avoid blocking the rust nightly releases for people that don't need clippy/rls.

To mitigate the issues we have:

  • rustup will warn if the update is missing any components you currently have. This means you can no longer accidentally update to a no-rls release. Once rls is available again it'll update.
  • rls, clippy are available on the stable channel. Meaning most developers installing for the first time should use stable.
  • However, if you need latest nightly rls you can use to find and install a dated nightly release ie rustup install nightly-2018-12-06.

Also see #641.


The RLS is built to work with many IDEs and editors, we mostly use VSCode to test the RLS. The easiest way is to use the published extension.

You'll know it's working when you see this in the status bar at the bottom, with a spinning indicator:

RLS: working ◐

Once you see:


Then you have the full set of capabilities available to you. You can goto def, find all refs, rename, goto type, etc. Completions are also available using the heuristics that Racer provides. As you type, your code will be checked and error squiggles will be reported when errors occur. You can hover these squiggles to see the text of the error.


The RLS can be configured on a per-project basis; using the Visual Studio Code extension this will be done via the workspace settings file settings.json.

Other editors will have their own way of sending the workspace/DidChangeConfiguration method.

Entries in this file will affect how the RLS operates and how it builds your project.

Currently we accept the following options:

  • unstable_features (bool, defaults to false) enables unstable features. Currently no option requires this flag.
  • sysroot (String, defaults to "") if the given string is not empty, use the given path as the sysroot for all rustc invocations instead of trying to detect the sysroot automatically
  • target (String, defaults to "") if the given string is not empty, use the given target triple for all rustc invocations
  • wait_to_build (u64) overrides build debounce duration (ms). This is otherwise automatically inferred by the latest build duration.
  • all_targets (bool, defaults to true) checks the project as if you were running cargo check --all-targets. I.e., check all targets and integration tests too
  • crate_blacklist ([String], defaults to this list) allows to specify which crates should be skipped by the RLS. By default skips libraries that are of considerable size but which the user often may not be directly interested in, thus reducing the build latency.
  • build_on_save (bool, defaults to false) toggles whether the RLS should perform continuous analysis or only after a file is saved
  • features ([String], defaults to empty) list of Cargo features to enable
  • all_features (bool, defaults to false) enables all Cargo features
  • no_default_features (bool, defaults to false) disables default Cargo features
  • racer_completion (bool, defaults to true) enables code completion using racer (which is, at the moment, our only code completion backend). Also enables hover tooltips & go-to-definition to fall back to racer when save-analysis data is unavailable.
  • clippy_preference (String, defaults to "opt-in") controls eagerness of clippy diagnostics when available. Valid values are (case-insensitive):
    • "off" Disable clippy lints.
    • "on" Display the same diagnostics as command-line clippy invoked with no arguments (clippy::all unless overridden).
    • "opt-in" Only display the lints explicitly enabled in the code. Start by adding #![warn(clippy::all)] to the root of each crate you want linted.

and the following unstable options:

  • build_lib (bool, defaults to false) checks the project as if you passed the --lib argument to cargo. Mutually exclusive with, and preferred over, build_bin.
  • build_bin (String, defaults to "") checks the project as if you passed -- bin <build_bin> argument to cargo. Mutually exclusive with build_lib.
  • cfg_test (bool, defaults to false) checks the project as if you were running cargo test rather than cargo build. I.e., compiles (but does not run) test code.
  • full_docs (bool, defaults to false) instructs rustc to populate the save-analysis data with full source documentation. When set to false, only the first paragraph is recorded. This option currently has little to no effect on hover tooltips. The save-analysis docs are only used if source extraction fails. This option has no effect on the standard library.
  • show_hover_context (bool, defaults to true) show additional context in hover tooltips when available. This is often the local variable declaration. When set to false the content is only available when holding the ctrl key in some editors.


For tips on debugging and troubleshooting, see


You can look in the in this repo to learn more about contributing to this project.

If you want to implement RLS support in an editor, see

  • Adding support for Sublime Text 3

    Adding support for Sublime Text 3

    Sourcegraph have a beta version of an lsp client, here. I've set it up and configured it, and I've got rls (, on Nightly 6f10e2f63) running too. Predictably, it's not working yet, but it looks like:

    • sublime-lsp is sending data to rls
    • it's getting responses

    What are some next steps to figure out where the current incompatibilities are?

    Sample request: Action: hovering over .to_vec(), in a file at /Users/sth/dev/rust-geo/src/algorithm/

    This sends (visible from the sublime-lsp debug log in the console):

        'Content-Length: 259',
        '  "method": "textDocument/hover", ',
        '  "params": {',
        '    "position": {',
        '      "character": 23, ',
        '      "line": 53',
        '    }, ',
        '    "textDocument": {',
        '      "uri": "file:///Users/sth/dev/rust-geo/src/algorithm/"',
        '    }',
        '  }, ',
        '  "jsonrpc": "2.0", ',
        '  "id": 27',

    And receives the response:

        'result': {
            'range': None,
            'contents': []
        'jsonrpc': '2.0',
        'id': 27

    I've configured the User settings for Sublime-lsp as follows:

        "clients": [
                "binary": "rls",
                "file_exts": ["rs"],
                "path_additions": [
                "env": {
                    "DYLD_LIBRARY_PATH": "/Users/sth/.rustup/toolchains/nightly-x86_64-apple-darwin/lib",
                    "RLS_ROOT": "/users/sth/dev/rls/target/release/rls"

    (I've also set up DYLD_LIBRARY_PATH and RLS_ROOT in my .bashrc)

    opened by urschrei 47
  • RLS crashes in VSCode

    RLS crashes in VSCode

    It just crashes on any project in Ubuntu 16.04. Chatted about it in #rust-tools with @jonathandturner and it seems it has something to do with latest rustup release.

    opened by rnleach 43
  • toolchain 'nightly-x86_64-unknown-linux-gnu' does not contain component 'rls-preview' for target 'x86_64-unknown-linux-gnu'

    toolchain 'nightly-x86_64-unknown-linux-gnu' does not contain component 'rls-preview' for target 'x86_64-unknown-linux-gnu'

    After updating to 1.23.0-nightly (d9f124965 2017-10-27) I am receiving the error below when attempting to install RLS on Linux (nightly-x86_64-unknown-linux-gnu) and Windows (nightly-x86_64-pc-windows-msvc).

    $ rustup component add rls-preview --toolchain nightly
    error: toolchain 'nightly-x86_64-unknown-linux-gnu' does not contain component 'rls-preview' for target 'x86_64-unknown-linux-gnu'

    Running 'rls' triggers this error:

    $ rls
    error: toolchain 'nightly-x86_64-unknown-linux-gnu' does not have the binary `rls`

    A similar problem was reported last month under Issue 502, when the component was renamed from 'rls' to 'rls-preview'.

    For me neither running 'rustup self update' nor uninstalling & reinstalling rustup resolved the issue.

    opened by wfchandler 40
  • Is rls supposed to work on a project with both a binary and a library?

    Is rls supposed to work on a project with both a binary and a library?

    When I use RLS with alacritty I get this error "E0463 can't find crate for alacritty can't find crate".

    Is this supposed to work?

    If I add build_lib: true to an rls.toml file I don't get any warnings at all in

    I'm on latest master of rls and LanguageClient-neovim

    opened by NickeZ 37
  • goto def into std libs should work properly

    goto def into std libs should work properly

    The file paths returned by rls-analysis are relative to the current working directory, while racer returns absolute paths.

    Take this simple code snippet for instance, assuming it'd be located at /Users/username/project:

    use std::io;
    fn main() {
        let _ = io::stdin();

    If you try to go to the definition of io (the one inside the main function) it works, because rls falls back to racer here, which returns the full absolute path to the Rust source file:

    INFO:rls::actions: goto_def - falling back to Racer
    DEBUG:rls::server: response: "Content-Length: 232\r\n\r\n{\"jsonrpc\":\"2.0\",\"id\":40,\"result\":[{\"uri\":\"file:///Users/username/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/net/\",\"range\":{\"start\":{\"line\":0,\"character\":1},\"end\":{\"line\":0,\"character\":1}}}]}"


      "jsonrpc": "2.0",
      "id": 40,
      "result": [
          "uri": "file:///Users/username/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/net/",
          "range": {
            "start": {
              "line": 0,
              "character": 1
            "end": {
              "line": 0,
              "character": 1

    If however you try to go to the definition of stdin it won't work:

    DEBUG:rls::server: response: "Content-Length: 187\r\n\r\n{\"jsonrpc\":\"2.0\",\"id\":76,\"result\":[{\"uri\":\"file:///Users/username/project/src/libstd/io/\",\"range\":{\"start\":{\"line\":204,\"character\":7},\"end\":{\"line\":204,\"character\":12}}}]}"


      "jsonrpc": "2.0",
      "id": 76,
      "result": [
          "uri": "file:///Users/username/project/src/libstd/io/",
          "range": {
            "start": {
              "line": 204,
              "character": 7
            "end": {
              "line": 204,
              "character": 12

    See how the path is now relative to my project root, where VSCode as well as rls were spawned in?

    I tried understanding and possibly fixing rls-analysis (where the bug should be at I believe), however I was unable to find the cause in a reasonable time frame. It'd be nice if someone could fix this issue or help me fix it myself. 🙂

    opened by lhecker 36
  • RLS always fails `textDocument/definition`, ctrl-hover and ctrl-click no longer working

    RLS always fails `textDocument/definition`, ctrl-hover and ctrl-click no longer working

    rls-preview 0.130.5 (1c755ef 2018-10-20) rustc nightly-2018-10-28

    Ctrl-click and ctrl-hover no longer work, at all. "result" is always []

    LSP4E to org.eclipse.corrosion.rls:{"jsonrpc":"2.0","id":"1006","method":"textDocument/definition","params":{"textDocument":{"uri":"***/src/"},"uri":"***/src/","position":{"line":92,"character":52}}}
    org.eclipse.corrosion.rls to LSP4E:{"jsonrpc":"2.0","id":1006,"result":[]}


    • Toolchain nightly-2018-09-20 is unaffected
    • Toolchain nightly-2018-10-17 is unaffected
    • Toolchain nightly-2018-10-20 is affected
    • Toolchain nightly-2018-10-28 is affected
    • Toolchain nightly-2018-11-14 is affected
    • Toolchain nightly-2018-11-20 is in some cases affected
    bug P-high 
    opened by norru 35
  • Atom support

    Atom support

    Tracking issue for Atom support.

    Existing work: and

    Checklist (from

    • [x] Implement extensions to the protocol
    • [ ] Client-side configuration.
    • [ ] send the workspace/didChangeConfiguration notification when configuration changes.
    • [ ] Support all config options, see
    • [x] Check for and install the RLS
    • [x] check the RLS is installed, and if not, install it and the rust-analysis and rust-src components
    • [ ] be aware that the RLS component is changing name - currently rls, will become rls-preview.
    • [ ] you should provide a way to update the RLS component
    • [ ] Client-side features
    • [ ] e.g., code snippets, build tasks, syntax highlighting
    • [ ] Testing
    • [x] Ensure integration with existing Rust features, e.g., syntax highlighting
    • [ ] 'Marketing'
    • [ ] documentation - users need to know how to install and use the extension
    • [ ] keep us informed about status so we can advertise it appropriately
    • [ ] update the RLS website
    • [x] submit the extension to the editor package manager or marketplace
    opened by nrc 31
  • "RLS analysis: working ◐" never stops

    I have been trying to get the RLS working on mdBook for some time now. It just never gets past "RLS analysis: working ◐".

    I tried running vscode with the following command, as suggested:

    RUST_LOG=rls_analysis=info code

    But it never outputs anything. I also tried with and without setting "rust.build_lib": true because I have a project containing both. But unfortunately that didn't work. I can reproduce this on both my mac and my linux pc.

    The thing is, though, that the vscode-rust extension with RLS enabled can cope with my project without any trouble. Giving me auto-completion, linting as I type, etc. So to me, it seems like the RLS can work with the project, but somehow the official Rust extension does something different that makes it fail or hang.


    Can I do something else to try and debug this? Does anyone have a clue as to why this could happen?

    opened by azerupi 30
  • "could not find `Cargo.toml` in `/` or any parent directory"

    Replicated in

    • open any project
    • 'Ctrl+Click` to navigate to a library source file (contained in .cargo)
    • browse

    Additional information:

    • I have manually added Cargo.toml to .cargo, doesn't fix this
    • after this error message the Eclipse IDE freezes (@mickaelistria), probably because it waits for a response from RLS
    • pkill rls restores the IDE to an unstable state which constantly re-triggers an RLS build
    • it is possible to save the edits and restart the IDE
    • on IDE restart, build is constantly re-triggered until all editor tabs are closed
    [t=1554109173638] org.eclipse.corrosion.rls to LSP4E:
    [t=1554109173638] LSP4E to org.eclipse.corrosion.rls:
    [t=1554109173638] org.eclipse.corrosion.rls to LSP4E:
    {"jsonrpc":"2.0","method":"window/showMessage","params":{"message":"could not find `Cargo.toml` in `/` or any parent directory","type":1}}
    [t=1554109173638] LSP4E to org.eclipse.corrosion.rls:
    Content-Length: 3864
    opened by norru 29
  • RLS

    RLS "textDocument/definition" always returns `[]` if invoked on `.cargo` cache entries

    I have imported the whole of .cargo as a project in Eclipse Corrosion - textDocument/hover seems to work for the entries but textDocument/definition doesn't (so Ctrl+click for quick navigation doesn't work)

    LSP4E to org.eclipse.corrosion.rls:{"jsonrpc":"2.0","id":"229","method":"textDocument/definition","params":{"textDocument":{"uri":"file:///home/nico/.cargo/registry/src/"},"uri":"file:///home/nico/.cargo/registry/src/","position":{"line":286,"character":17}}}
    org.eclipse.corrosion.rls to LSP4E:{"jsonrpc":"2.0","id":229,"result":[]}
    LSP4E to org.eclipse.corrosion.rls:Content-Length: 327
    LSP4E to org.eclipse.corrosion.rls:{"jsonrpc":"2.0","id":"230","method":"textDocument/hover","params":{"textDocument":{"uri":"file:///home/nico/.cargo/registry/src/"},"uri":"file:///home/nico/.cargo/registry/src/","position":{"line":286,"character":17}}}
    org.eclipse.corrosion.rls to LSP4E:{"jsonrpc":"2.0","id":230,"result":{"contents":[{"language":"rust","value":"appenders: Vec<Appender>"}]}}
    opened by norru 27
  • Cannot open file on Windows

    Cannot open file on Windows

    I'm testing VS Code extension on Windows - I cannot get anything to work at the moment, but the following keeps getting printed on the stderr:

    thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value:
    Io(Some("/d%3A/Documents/rustls/src/"), Some("Could not open file: /d%3A/Documents/rustls/src/"))',

    Looks like the path is URL encoded, maybe that's causing issues?

    opened by hban 26
  • feat: update lsp_types to the latest version

    feat: update lsp_types to the latest version

    • feat: update lsp_types to the latest version:
      • This required adding some optional fields
      • Updating the progress reporter
      • Using u32 in some places instead of u64
      • Passing the correct type as the request/response
      • Changing the enum field cases to upper case

    After debugging the code for some time, I cannot find the reason why the 9 remaining tests are failing. Any help would be appreciated.

    using this in the find_impls test seems to fix the issue, but modifying the tests like this looks random to me.

                    work_done_progress_params: WorkDoneProgressParams {
                        work_done_token: Some(NumberOrString::String("progress_1".to_owned())),

    cc: @Xanewok

    opened by aminya 1
  • rls triggers a registerCapability handler despite dynamicRegistration set to false

    rls triggers a registerCapability handler despite dynamicRegistration set to false

    rls version:

    $ rls --version
    rls 1.41.0 (bf88026 2021-09-07)


    I am getting this warning in lsp.log

    [WARN][2022-02-16 15:10:07] ...lsp/handlers.lua:107 "The language server rls triggers a registerCapability handler despite dynamicRegistration set to false. Report upstream, this warning is harmless"
    [WARN][2022-02-16 15:10:07] .../lua/vim/lsp.lua:711 "server_request: no handler found for"  "client/unregisterCapability" 

    After this, list references for symbols is not working.

    opened by vimalk78 0
  • test_tooltip_std test failing

    test_tooltip_std test failing

    Build is working again but the test_tooltip_std is failing ( Some tooltips are missing from the actual output (❌):

    ✅: Test { file: "", line: 8, col: 15 }
    ❌: Test { file: "", line: 8, col: 27 }
    ✅: Test { file: "", line: 9, col: 7 }
    ❌: Test { file: "", line: 9, col: 12 }
    ✅: Test { file: "", line: 10, col: 12 }
    ✅: Test { file: "", line: 10, col: 20 }
    ❌: Test { file: "", line: 11, col: 25 }
    ❌: Test { file: "", line: 12, col: 33 }
    ✅: Test { file: "", line: 13, col: 11 }
    ✅: Test { file: "", line: 13, col: 18 }
    ✅: Test { file: "", line: 14, col: 24 }
    ❌: Test { file: "", line: 15, col: 17 }
    ❌: Test { file: "", line: 15, col: 25 }

    I took a look at it but I'm not familiar enough with the code to know what might cause this. I'm also not really sure why the triggered CI succeeds (scheduled CI fails)---my local build is always failing these tests. The scheduled CI is also failing test_tooltip_std_racer but that seems to pass for me locally.

    Locally, the rest of the tests are all passing so this is the last thing to fix right now

    opened by MingweiSamuel 1
  • Component rls unavailable for download - README hints do not suffice

    Component rls unavailable for download - README hints do not suffice

    The README says to pin to a specific version found at – however, that site only shows the last 7 days. It currently (at time of writing: 2022-01-10) does not even list "rls" anywhere, likely because no recent RLS builds are available for the nightly toolchain. Thus, I had to trick around like this

    for n in $(seq 10 30); do if rustup toolchain add nightly-2021-11-${n} -c rls; then break; fi; done

    in order to find that the latest available toolchain with RLS was 2021-11-09 at the time.

    Other, more obvious solutions such as finding the latest successful CI build (linked from the button in the README: did not work for me, likely because their date does not necessarily relate directly to the (nightly) toolchain release date.

    Having to pin a version isn't super bad, but then users should be given better hints how to solve it. Modern Rust projects often require nightly builds, so having RLS is essential for developer experience.

    opened by AndiDog 5
  • Confusing placement of macro matching error

    Confusing placement of macro matching error

    Macros display an error when used incorrectly, when it should just be the usage alone.

    Note: Rust scares me like it's a very friendly dog to a toddler, and I'm generally new to this so I don't know all the crab lingo.

    opened by g307m 0
The Rust Programming Language
The Rust Programming Language
The Curly programming language (now in Rust!)

Curly Curly is a functional programming language that focuses on iterators. Some of its main implementation features include sum types, iterators, lis

Curly Language 30 May 3, 2022
A language-agnostic "shebang interpreter" that enables you to write scripts in compiled languages.

Scriptisto It is tool to enable writing one file scripts in languages that require compilation, dependencies fetching or preprocessing. It works as a

Igor Petruk 222 Sep 12, 2022
A fun and simple language with NO classes whatsoever!

This language aims to be simple, minimal, and compact. There will not be any classes whatsoever, and importing other files should be painless.

Europa Lang 22 Aug 23, 2022
Detects usage of unsafe Rust in a Rust crate and its dependencies.

cargo-geiger ☢️ A program that lists statistics related to the usage of unsafe Rust code in a Rust crate and all its dependencies. This cargo plugin w

Rust Secure Code Working Group 1k Sep 30, 2022
Powerful database anonymizer with flexible rules. Written in Rust.

[Data]nymizer Powerful database anonymizer with flexible rules. Written in Rust. Datanymizer is created & supported by Evrone. What else we develop wi

[Data]nymizer 366 Sep 18, 2022
⚡️Lightning-fast linter for .env files. Written in Rust 🦀

⚡️ Lightning-fast linter for .env files. Written in Rust ?? Dotenv-linter can check / fix / compare .env files for problems that may cause the applica

null 1.4k Sep 21, 2022
Rust Code Completion utility

Racer - code completion for Rust RACER = Rust Auto-Complete-er. A utility intended to provide Rust code completion for editors and IDEs. Maybe one day

null 3.4k Sep 27, 2022
Format Rust code

rustfmt Quick start On the Stable toolchain On the Nightly toolchain Installing from source Usage Running cargo fmt Running rustfmt directly Verifying

The Rust Programming Language 4.6k Sep 25, 2022
The Rust toolchain installer

rustup: the Rust toolchain installer Master CI Build Status Windows macOS Linux Etc rustup installs The Rust Programming Language from the official re

The Rust Programming Language 4.9k Sep 25, 2022
🦀 The ultimate search extension for Rust

Rust Search Extension 简体中文 The ultimate search extension for Rust Search docs, crates, builtin attributes, official books, and error codes, etc in you

Huhu 883 Sep 19, 2022
a freeform Rust build system

tinyrick: a freeform Rust build system .---. ^ o{__ω__ o{ ^0^ -Let me out! ~~ ( // *|* \xx\) xx`|' = =

Andrew 47 Sep 11, 2022
Some WIP payload in Rust running on M1.

m1saka Some WIP payload in Rust running on M1. Project informations The aim of this payload is to provide exploration capabilities while providing a s

Mary 10 Mar 7, 2021
A library to compile USDT probes into a Rust library

sonde sonde is a library to compile USDT probes into a Rust library, and to generate a friendly Rust idiomatic API around it. Userland Statically Defi

Wasmer 38 Aug 30, 2022
⚙️ Workshop Publishing Utility for Garry's Mod, written in Rust & Svelte and powered by Tauri

⚙️ gmpublisher Currently in Beta development. A powerful and feature-packed Workshop publisher for Garry's Mod is finally here! Click for downloads Ar

William 426 Sep 23, 2022
compile rust code into memes

cargo-memex Besides their size, rust binaries have a significant disadvantage: rust binaries are not memes yet. cargo-memex is a cargo subcommand that

Matthias Seitz 242 Sep 4, 2022
A neofetch alike program that shows hardware and distro information written in rust.

nyafetch A neofetch alike program that shows hardware and distro information written in rust. installing install $ make install # by default, install

null 15 Jul 21, 2022
Automated license checking for rust. cargo lichking is a Cargo subcommand that checks licensing information for dependencies.

cargo-lichking Automated license checking for rust. cargo lichking is a Cargo subcommand that checks licensing information for dependencies. Liches ar

Nemo157 117 Aug 28, 2022
Create target folder as a RAMdisk for faster Rust compilation.

cargo-ramdisk This crate is only supported for unix like systems! cargo-ramdisk creates a ramdisk at the target folder of your project for ridiculousl

PauMAVA 19 Aug 30, 2022
cargo extension that can generate BitBake recipes utilizing the classes from meta-rust

cargo-bitbake cargo bitbake is a Cargo subcommand that generates a BitBake recipe that uses meta-rust to build a Cargo based project for Yocto Install

null 58 Sep 17, 2022