Try out Rust IDE support in Visual Studio Code

announcements
1

IDE support for Rust is an oft-requested feature and a key goal of this years roadmap. For the past year we've been working on an editor-agnostic IDE backend called the Rust Language Server (RLS). The currently recommended way to use the RLS is in Visual Studio Code and an extension to do so is now in the VSCode marketplace. Both the RLS and our extension are 'preview' quality. We'd love for you to try them out and share your experience, especially if you find bugs. However, you should expect that the experience will not be perfect (yet).

To try this out you'll need VSCode and Rustup installed on your system. You can install the extension in VSCode by running ext install rust from the command palette (ctrl+P). Open a folder containing a Rust project (i.e., the folder containing Cargo.toml), then open a Rust file; the extension will startup automatically. On first run, the extension will install the RLS and a nightly toolchain if neccessary. It will then index your project, which can take a while. For more info on installation see the extension in the marketplace.

The RLS can highlight errors (and sometimes apply suggestions for fixing them), jump to definitions, show you the types of expressions, offer code completion, and more. For a more complete guide (with pictures!), see my recent blog post - what the RLS can do.

The current releases of the RLS and VSCode extension are preview releases. We think they work pretty well, but they're not 1.0 quality - it only works with nightly Rust, and only works on straightforward projects (it can't cope with Cargo workspaces, for example). There are also bugs, of course. Because we rely on the compiler, indexing can be a bit slow, so the RLS works best with small to medium sized crates.

We hope the RLS will be available on all channels with Rust version 21, i.e., the RLS preview will work with stable Rust from October 13th. We estimate that the RLS and VSCode extension will be ready for a 1.0 announcement at the end of the year (and will work with stable Rust 2 cycles, apx 12 weeks, later).

So, if you want to use Rust with an IDE, give it a go! Let us know how it goes in #rust-dev-tools, by commenting here, or filing an issue.

27 Likes
2

Stupid question - how does this relate to VSCode-rust, which is the de-facto extension for rust development right now (AFAIK)?

13 Likes
3

I suppose in this github issue comment there is answer to your question:

1 Like
4

How bad workspace support? Is reparse every crate in workspace after switch from crate to another, or just crash if there is workspace Cargo.toml?

When I seriously began to use rust I have no projects without workspaces.

2 Likes
5

I understand why there are (for now) two separate plugins, but even after reading the GitHub discussion, I don't understand what the interaction between the two plugins is. I already have VSCode-rust installed; if I install the RLS plugin, will I get conflicting syntax-checking, etc?

1 Like
6

Are you able to give us an idea of what "small to medium" looks like in terms of line count or something?

7

The two VSCode plugins confused me as well and I need to remove one to use the other for smooth experience.

The main issue with the plugin is the inability to jump to definition for files in the stdlib, otherwise everything seems fine for 'preview' quality.

By the way, I would like to know if anyone has had luck with RLS and Vim.

8

Using RLS with rust.workspace_mode option enabled you should at least not get a crash when analyzing a workspace project and get diagnostics for every crates. Please try and see if it works - if it doesn't, then it's probably a regression - feel free to file any issues over at https://github.com/rust-lang-nursery/rls!

2 Likes
9

The diagnostics themselves have a feedback latency roughly equivalent to the time needed for cargo check, with indexing taking an additional, small portion of it.
My best bet would be to run cargo check on your project and assume that from finishing the editing to being able to see diagnostics and use the indexed data will take no longer than ~1.5x of the time cargo check runs (indexing part is just my guess, @nrc can surely give a better estimate).

10

This is very dependent on how fast your machine is and tolerant of latency you are. It also depends a bit on the nature of your crate - some are slower to compile than others. I'd recommend just trying it out and seeing what you think. But it definitely won't work for Servo or rustc or something huge like that. For me a crate with 10-20 non-trivial files is about the largest I'm happy with (dependent crates don't matter too much), but like I say, that might be very different for you.

11

The experimental workspace mode is worth trying for sure. If you don't use that, you need to point the RLS at a specific crate (you can have multiple crates open in multiple windows, and that should work fine, but is not well-tested).

1 Like
12

Starting with some historical context: when we started working on the RLS we needed to pick an editor as a client to test things were working and to demonstrate the RLS's capabilities. We picked VSCode because it was developed by Microsoft together with the LSP and because it was the only major IDE without a plugin (at the time, RustyCode was not maintained). We created our own extension (demo'ed at Rustconf last year) as a reference extension. We were not comfortable releasing that extension in the marketplace because we felt that the RLS was not ready, even for a preview release (obvs, we do now!). A bit later, KalitaAlexey forked the old RustyCode extension and added RLS support and released it in the marketplace.

The two extensions have quite different architectural approaches - the RLS extension uses only the RLS (note though that the RLS uses Rustfmt and Racer internally for some functionality). We believe this is the optimal way to organise an extension. The other extension uses Racer and RustSym in the extension itself. This may have been a good approach when the RLS was slower and less reliable, but we think that it now causes more problems that it solves. Ultimately, we don't think we can rely on the RustyCode extension to provide the user experience we want to deliver.

1 Like
13

Just tried this VSCode plugin with my project at https://github.com/tanis2000/minigame-rust and it hangs indefinitely. Is there any way to see what RLS is doing behind the scenes?

Turning on workspace mode stops this behavior but code inspection isn't working at all. Looking at the activity monitor it looks like the extension is still running the analysis in the background without but the UI isn't showing it as it reports "RLS analysis: done"

14

When opening the project for the first time, it might take some time for RLS to build up dependencies (it doesn't reuse the ones resulting from the regular cargo runs), so maybe that's what causing it to build that long.
You can try running code with RUST_LOG="rls=trace,rls_analysis=error" (I do it to get only RLS logs, there might be a better way to do that) and with "rust-client.showStdErr": true in the VSCode Settings. By default it should detect the appropriate crate target to analyze, which in this case is the [lib] one, so you should get diagnostics and IDE features working on the lib side of things.
I tried running opening this project with the newest rustup and the 0.2.1 version and it seems to be working for me. Try running it with aforementioned debugging options enabled and please tell if it works or what kind of errors you might get (the rls output should be under Output > Rust Language Server).

15

I have recently tried this (past few days) and it didn't seem to work. I'm trying it again now, and .. it doesn't seem to work. I'm not really sure what it is supposed to do, but following the instructions prompted an install of RLS, which I ok'd. Then, .. well it's a week later and there is no feedback from the IDE.

Perhaps I'm doing it wrong, but e.g. mousing over types, my traits, stuff like that reports at best "Loading ...", but currently reports nothing at all.

I asked on #rust, but no response when I did. Perhaps I'll hit up #rust-dev-tools instead. Is there some output where it would report success or failure or "I am actually running"?

1 Like
16

I assume this probably isn't it but make sure you're opening the entire cargo project in vscode, not just single files, RLS with this plugin for me just crashes infinitely if I open a single file, but opening an entire cargo project works fine for me on windows 10 + nightly rust

1 Like
17

@Xanewok

I wonder protocol between IDE<->rls allows report of progress of indexing?

Looks like that it is the first thing that hit user to his/her face after fresh install.

18

Not really, although there is an API in progress for the next, 4.0, version of the protocol spec: Add support to report progress for a running request · Issue #70 · microsoft/language-server-protocol · GitHub. Right now we're using our custom API extension: rustDocument/diagnosticsBegin, rustDocument/diagnosticsEnd, but that's only currently used to represent working / done state.
We're discussing it how we could improve that over here: Detect the long first build and tell the user · Issue #377 · rust-lang/rls · GitHub, but the exact details aren't really ironed out.

1 Like
19

I have very small internal for my company crate written in rust. When it was in src just main.rs + some other files with code it was working OK. But when I moved most of my code from main.rs to lib.rs, leaving only arguments parsing and output formatting in main.rs i only get types tool-tip and autocompletion etc. in main.rs but not in lib.rs or any other file, but the crates compiles correctly and produced binary works correctly too. I don't know if it's vscode extension, or RLS itself because Intelij Rust plugin works rather OK, but I think it's not based on RLS

20

You need to set rust.build_lib to true in your VSCode settings. In the next release this should not be necessary.