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 server 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 https://raw.githubusercontent.com/rust-lang/rls/master/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.

Issues

Collection of the latest Issues

MingweiSamuel

MingweiSamuel

1

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 (❌):

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

AndiDog

AndiDog

5

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

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.

molehauling

molehauling

0

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.

Machu101

Machu101

0

/home/matthewquijano/.cargo/registry/src/github.com-1ecc6299db9ec823/ff-0.10.0/src/lib.rs:21:5 | 21 | use rand_core::RngCore; | ^^^^^^^^^ | = help: please recompile that crate using this compiler (rustc 1.51.0 (2fd73fabe 2021-03-23)) = note: the following crate versions were found: crate rand_core compiled by rustc 1.56.1 (59eed8a2a 2021-11-01):

Can anyone help me with this? Trying to run a test on a smart contract and this error keeps popping up. Now I read in another thread with a similar problem that it had something to do with Rust being installed twice. I have Rust installed in my windows Usr folder, as well as my \wsl$\Ubuntu-18.04, since I am using Linux virtual machine to run rust within vscode. Any help would be greatly appreciated.

njaard

njaard

0

I have a build.rs which takes a long time and doesn't actually affect rls's behavior.

Is there a gate I could wrap my code in build.rs's main() to disable rls?

hungpham3112

hungpham3112

0

Sometimes when I edit Rust file it reports a red message( It really good ) but after correct, it takes a while to index or detect so that really annoying and uncomfortable.

Can it be index fast like clangd?

I use coc-rls to support for coc.nvim. I thought it is an issue with coc-rls but they answered me that the slow performance is caused by rust-lang-server. The answer is here.

bandicam 2021-09-03 11-25-25-179

DavidGoodenough

DavidGoodenough

0

Trying to use the Espressiv build of the rust toolkits (which includes the Xtensa architecture and a tailored RISC-V for their ESP32 range) rls refuses to install complaining that "error: toolchain 'esp' does not support components: esp is a custom toolchain".

In rustup issue 1570 there is discussion that the rls installer is using the wrong technique to determine whether the components that RLS needs are installed. Could the installer be changed to use the techniques outlines in 1570?

Now I do not know if the Espressiv build does include the right components, but the error message does not tell me what (if anything) is missing, only that it can not find out what is there.

eesekaj

eesekaj

1

Hello. For some reason when I started to introduce the code from the pull requests which contains a lot of "extern C, and FFI and raw pointers" into my project, the RLS started crashing on both VSCodium on Debian and on OSX. I made some research and found out that there is some "intolerance" when there is type mismatch for extern C or C-structs or something similar, because at some point, somehow I was able to fix it, but later it started crashing again. Now, when I am starting VSCodium, RLS starts normally and as soon as I am trying to modify something in the code, it crashes.

The project which causing RLS to crash is https://gitlab.com/relkom/logdaemon and the exact file which started causing problems is ./src/portable/timer.rs.

The code in the repo is a read only mirror for other devs which do not have access to private repo, so sometimes the code may not compile from master branch, so please use this snapshot https://gitlab.com/relkom/logdaemon/-/tree/310d7397665c8f8e3adc45b6cdc83220d03d9b00/

Info: VSCodium plugins: Rust 0.7.8 CodeLLDB 1.6.0 rls 1.41.0 (3bd7215 2021-02-09) rustc 1.51.0 (2fd73fabe 2021-03-23)

cjwcommuny

cjwcommuny

1

I encountered this error when implement a rust extension:

The error comes from here.

The error occurs because the path of modified file is /Volumes/Macintosh HD/Users/XXX/Downloads/hello_cargo/src/main.rs but the the src_dir (see here) is something like /XXX/Downloads/hello_cargo/src/, so they don't have the same prefix. But actually, /Volumes/Macintosh HD is just a symlink to /.

Possible solution: canonicalize the path of the modified file first, and then compare the path with the src_dir. Maybe someone can fix it ? (I'm not familiar with the codebase, otherwise I can make a pull request)

InterestingBrainPoops

InterestingBrainPoops

0

I installed rls while im getting started with rust, and Ive installed the rand package, and it builds just fine with cargo. However its showing me the following error and not letting me use code completion: image The same errors popup when I use rustc instead of cargo build/run.

eddyb

eddyb

1

See #1714 for context, but I suspect this can be repeated on even simple crates, they just build much faster so it's harder to tell. (Just checked on another project I had handy, glOOF, and it also builds gloof cfg(test) on every change, can barely see it for a second in the status bar, but it's there - there might be a better way to confirm but I don't know how to get a proper log)

I'm not sure how this is happening, based on this (and the relevant Cargo code) I would expect it to "just" work: https://github.com/rust-lang/rls/blob/581415cf3f280e18b975812933dd74155a52f175/rls/src/build/cargo.rs#L214-L227

EDIT: "rust.build_lib": true also doesn't seem to restrict the set of targets, but I'm not sure it does nothing

eddyb

eddyb

1

I work on Rust-GPU nowadays, and specifically the rustc_codegen_spirv crate in it, but that has a bunch of downstream users in the same workspace, so right now I have to wait for RLS to rebuild all of those every time I make a change (in rustc_codegen_spirv).

Neither "rust.all_targets": false nor "rust.build_lib": true seem to do their job (see #1715), but even if they did, they wouldn't full solve the problem, which is that there's no fine-grained control over which packages should be rebuilt.

The "rust.crate_blacklist" option exists, but it doesn't do what one might naively expect, and it should be documented as specifically not skipping building, just skipping save-analysis (presumably to work around bugs in save-analysis?).

When talking to @Xanewok, he suggested a new packages setting, and I've also found #614 that might be relevant.

Gamadril

Gamadril

0

When I start a test in VSCode with "Run Test" button above the test, the executed command cargo test -- --nocapture TEST_NAME fails because my Cargo.toml is not in the root folder, but in a subfolder.

When I call cargo (command line or lldb launcher) I always provide the --manifest-path=src/Cargo.toml parameter. It should be possible to pass additional parameters for test execution as well.

domibay-hugo

domibay-hugo

1

Using the Eclipse Corrosion Plugin with rls I found that I get wrong error reports when formatting the code. How to reproduce?

  • Mark spaces at the beginning of the line and delete them.
  • Move ahead one line at the time

The Log File org.eclipse.corrosion.rls.log reports:

Although the source code file was resubmitted recently the submitted deletions lead to a corrupted Index of the File in rls accusing of an error where there isn't any.

stsquad

stsquad

2

I've been trying to get rls working with my Emacs's lsp-mode. Emacs keeps complaining that the server didn't start:

LSP :: Restarting LSP in buffer main.rs
LSP :: Connected to [rls:10458 status:starting].
LSP :: rls has exited (finished)
Server rls:10458 status:starting exited with status exit. Do you want to restart it? (y or n) y

I've been trying to get something out of it from the command line. Both rls --help and rls --cli just seem to exit straight away without any output making it hard to glean what might be wrong. The install details are as follows:

$ cargo install rls
    Updating crates.io index
  Installing rls v0.122.2
   Compiling rls v0.122.2
    Finished release [optimized] target(s) in 1.78s
  Installing /home/alex/.cargo/bin/rls
   Installed package `rls v0.122.2` (executable `rls`)

but even under strace it seems to exit super quickly:

 openat(AT_FDCWD, "/proc/self/maps", O_RDONLY|O_CLOEXEC) = 3
 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
 read(3, "55721ee4d000-55721ee51000 r--p 0"..., 1024) = 1024
 read(3, "         /usr/lib/x86_64-linux-g"..., 1024) = 1024
 read(3, " r--p 00000000 fd:00 2629296    "..., 1024) = 1024
 read(3, "  /usr/lib/x86_64-linux-gnu/libr"..., 1024) = 1024
 read(3, "f000 fd:00 2629272              "..., 1024) = 585
 close(3)                                = 0
 sched_getaffinity(19644, 32, [0, 1, 2, 3, 4, 5, 6, 7]) = 32
 rt_sigaction(SIGSEGV, {sa_handler=0x55721ee576d0, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_SIGINFO, sa_restorer=0x7feb4b333730}, NULL, 8) = 0
 rt_sigaction(SIGBUS, {sa_handler=0x55721ee576d0, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_SIGINFO, sa_restorer=0x7feb4b333730}, NULL, 8) = 0
 sigaltstack(NULL, {ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=0}) = 0
 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feb4b388000
 sigaltstack({ss_sp=0x7feb4b388000, ss_flags=0, ss_size=8192}, NULL) = 0
 sigaltstack({ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=8192}, NULL) = 0
 munmap(0x7feb4b388000, 8192)            = 0
 exit_group(0)                           = ?
 +++ exited with 0 +++

Any pointers on how to debug what is going on?

jeena

jeena

0

I had a syntax error in my code:

And when using GNOME Builder my computer started behaving really weird until I closed Builder. I checked top and it showed that rls was using one core 100% and 52% of my 16 GB RAM when Builder was running. The mouse stopped working, YouTube playback started stuttering and I couldn't basically use my computer until I closed Builder. rustc wasn't able to compile it either but instead giving me a syntax error it got killed after some time:

The syntax error is that g at the end of line 3 which was supposed to be in line 4. So while rustc at least timed out rls just kept cranking and making my computer unusable. I just wanted to report it because I guess it's a rare occurence that something like that happens but it was nicely reproducable. As soon as I fixed the syntax error the problems stopped.

Eric-Arz

Eric-Arz

1

Code completion in Visual Studio Code seems to only work reliably for code inside your own project. For traits and structs coming from extern crates it fails to see most of the available methods despite the code compiling and running fine.

For example in this code snippet using the crate sdl2 rls code completion fails to see any of the methods from the VideoSubsystem struct that is returned by sdl_context.video().unwrap(). Only after typing everything out it recognizes the methods and displays mouseover details and ctrl-click navigation to the implementation.

zaszi

zaszi

2

I have a project as follows, using Cargo workspaces:

Note how there exists a target directory for both crate1 and crate2 containing an rls subdirectory. These are created as soon as I open the project in my IDE which triggers RLS.

This is a bit counter-intuitive as the documentation for Cargo Workspaces mentions that crates in a workspace should not have their own target directory. Additionally, this inevitably results in mistakes when it comes to the default Cargo-generated.gitignore.

I wasn't able to find any clear-cut information on this. Is this a bug or does this have a solution or workaround?

Versions

Find the latest versions by id

Information - Updated Mar 24, 2022

Stars: 3.5K
Forks: 260
Issues: 295

Repositories & Extras

saltwater is a C compiler coded in the Rust language

Speed up your debugging of error messages with a log focused C compiler in Rust

saltwater is a C compiler coded in the Rust language

rust-analyzer is a modular compiler frontend for the Rust language

It also contains some tips &amp; tricks to help you be more productive when using rust-analyzer

rust-analyzer is a modular compiler frontend for the Rust language

A study note of Rust language

The Rust Programming Language

A study note of Rust language

Rust Amplify Library

Amplifying Rust language capabilities: multiple generic trait implementations,

Rust Amplify Library

Rust Language Security

execrices: RUSTSEC-2021-0001

Rust Language Security

rust_icu: low-level rust language bindings for the ICU library

See: The latest version of this file is available at

rust_icu: low-level rust language bindings for the ICU library

Hello Flappy in Mozilla's Rust language

First game I've coded in rust

Hello Flappy in Mozilla's Rust language
Facebook Instagram Twitter GitHub Dribbble
Privacy