Repository for the Rust Language Server (aka RLS)

Last update: Dec 30, 2022

Related tags

Overview

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.

Setup

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 https://rust-lang.github.io/rustup-components-history/ to find and install a dated nightly release ie rustup install nightly-2018-12-06.

Also see #641.

Running

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:

RLS

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.

Configuration

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. Options are nested in the rust object, so your LSP client might send {"settings":{"rust":{"unstable_features":true}}} as parameters.

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.

Troubleshooting

For tips on debugging and troubleshooting, see debugging.md.

Contributing

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

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

Comments

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 (https://github.com/rust-lang-nursery/rls/commit/e24fc84bfc4b3360a3d65d9adeab0f701140094d, 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/simplifyvw.rs

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/simplifyvw.rs"',
    '    }',
    '  }, ',
    '  "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": [
                "/users/sth/dev/rls/target/release/",
                "/Users/sth/.rustup/toolchains/nightly-x86_64-apple-darwin/lib"
            ],
            "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)

clients

opened by urschrei 47

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.
P-high

opened by rnleach 43
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?

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 main.rs.

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

opened by NickeZ 37

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/mod.rs\",\"range\":{\"start\":{\"line\":0,\"character\":1},\"end\":{\"line\":0,\"character\":1}}}]}"

Formatted:

{
  "jsonrpc": "2.0",
  "id": 40,
  "result": [
    {
      "uri": "file:///Users/username/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/net/mod.rs",
      "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/stdio.rs\",\"range\":{\"start\":{\"line\":204,\"character\":7},\"end\":{\"line\":204,\"character\":12}}}]}"

Formatted:

{
  "jsonrpc": "2.0",
  "id": 76,
  "result": [
    {
      "uri": "file:///Users/username/project/src/libstd/io/stdio.rs",
      "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. 🙂

P-high

opened by lhecker 36

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/render.rs"},"uri":"***/src/render.rs","position":{"line":92,"character":52}}} org.eclipse.corrosion.rls to LSP4E:{"jsonrpc":"2.0","id":1006,"result":[]}

UPDATE:

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
"could not find `Cargo.toml` in `/` or any parent directory"
Replicated in https://github.com/eclipse/corrosion:

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: {"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_0","title":"Indexing"}} [t=1554109173638] LSP4E to org.eclipse.corrosion.rls: {"jsonrpc":"2.0","id":"2","method":"textDocument/codeLens","params":{"textDocument":{"uri":"file:[...]/.cargo/[...]"}} } [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 33
Atom support
Tracking issue for Atom support.

Existing work: https://github.com/aergonaut/languageserver-rust and https://github.com/mehcode/atom-ide-rust

Checklist (from clients.md):

[x] Implement extensions to the protocol

[ ] Client-side configuration.

[ ] send the workspace/didChangeConfiguration notification when configuration changes.

[ ] Support all config options, see config.rs

[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

clients
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

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/github.com-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs"},"uri":"file:///home/nico/.cargo/registry/src/github.com-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs","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/github.com-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs"},"uri":"file:///home/nico/.cargo/registry/src/github.com-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs","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
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/server.rs"), Some("Could not open file: /d%3A/Documents/rustls/src/server.rs"))', ../src/libcore\result.rs

Looks like the path is URL encoded, maybe that's causing issues?
opened by hban 26
Archive repository

rls has been superseded by rust-analyzer (as marked in README.md), and last commit is from august 2022.

Please archive this (rls) repository to make it obvious at first sight that it is now unmaintained.

opened by dargor 0
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 version:

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

nvim-lspconfig https://github.com/neovim/nvim-lspconfig.git

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

Build is working again but the test_tooltip_std is failing (https://github.com/rust-lang/rls/actions/runs/1702875684). Some tooltips are missing from the actual output (❌):

✅: Test { file: "test_tooltip_std.rs", line: 8, col: 15 }
❌: Test { file: "test_tooltip_std.rs", line: 8, col: 27 }
✅: Test { file: "test_tooltip_std.rs", line: 9, col: 7 }
❌: Test { file: "test_tooltip_std.rs", line: 9, col: 12 }
✅: Test { file: "test_tooltip_std.rs", line: 10, col: 12 }
✅: Test { file: "test_tooltip_std.rs", line: 10, col: 20 }
❌: Test { file: "test_tooltip_std.rs", line: 11, col: 25 }
❌: Test { file: "test_tooltip_std.rs", line: 12, col: 33 }
✅: Test { file: "test_tooltip_std.rs", line: 13, col: 11 }
✅: Test { file: "test_tooltip_std.rs", line: 13, col: 18 }
✅: Test { file: "test_tooltip_std.rs", line: 14, col: 24 }
❌: Test { file: "test_tooltip_std.rs", line: 15, col: 17 }
❌: Test { file: "test_tooltip_std.rs", 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
The README says to pin to a specific version found at https://rust-lang.github.io/rustup-components-history/ – 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: https://github.com/rust-lang/rls/actions?query=workflow%3ACI+branch%3Amaster) 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