Blog post: Using Rust with Visual Studio Code


I thought I’d share my experiences of using Rust in Visual Studio Code, you can find the original post on my blog:

Which extension?

First off if you can, you should be using the Rust Language Server (RLS) extension. Yes it’s beta, but the user experience has been the best I’ve had, outside of in-house language support by giants like Microsoft and JetBrains! The extension will even install dependencies for you if you have rustup installed!

If you didn’t want to use RLS, then the alternative is to install various Rust related tools (racers, rustfmt and rustsym) manually. The only Rust extension that support non-RLS is Kalita Alexey’s.

Whilst we’re on the subject of Kalita’s extension, this was a fork of the RustyCode extension which was no longer being actively maintained.

The biggest draw this extension at the time was that it was available on the Visual Studio Marketplace, where as the RLS team extension had to be manually installed via git.

I think one of reasons why Kalita released his fork into the Visual Studio Marketplace, was that the first Rust extension

It will be interesting two see how the two active extensions progress.

If you want a proper whistle stop tour of RLS I recommend you pop over to @nrc blog as he’s done a thorough job of it in this post.


I’m ashamed to admit that I still find setting up debugging Rust a bit of a black art if you’re not using gdb. However thanks to the LLDB Debugger extension it’s become a little bit easier.

The only bit that caught me out was the launch.json boiler plate code (see below for a sample), specifically what would be the correct value for program key. This is the path to your debug binary.

    "version": "0.2.0",
    "configurations": [
            "type": "lldb",
            "request": "launch",
            "name": "Debug",
            "program": "${workspaceRoot}/<your program>",
            "args": [],
            "cwd": "${workspaceRoot}"

So if the binary you wish to debug is called foo, your value for the program key would look like this:

    "program": "${workspaceRoot}/target/debug/foo"

note: I’ve omitted the rest of the json keys that don’t change for the sake of brevity.

If you wanted to keep things generic and only compile a binary that matches the cargo folder name, you could use ${workspaceRootFolderName} variable substitution.

    "program": "${workspaceRoot}/target/debug/${workspaceRootFolderName}",

If you’re interested in what other variables substitutions are available the Visual Studio Code Debugger guide has a handy list.

One last option to enable is sourceLanguages with the value of "rust", this option enables visualisation of built-in types and standard library types i.e. you can peek into the contents of a Vec etc.

Here’s a complete example of the launch.json for reference.

    "version": "0.2.0",
    "configurations": [

            "type": "lldb",
            "request": "launch",
            "name": "Debug",
            "program": "${workspaceRoot}/target/debug/${workspaceRootFolderName}",
            "args": [],
            "cwd": "${workspaceRoot}",
            "sourceLanguages": ["rust"]

What’s your favourite parts of the new Rust extension? Did I miss anything notable with the LLDB extension? Please share!

Setting up a generic launch.json for Rust in VSCode [SOLVED]

Your history of kalita’s extension is a bit off. It was originally a fork of RustyCode, not of the RLS extension, and it has been around in the vscode marketplace since before RLS was even announced, IIRC.


Whoops! Cheers for that, will be updating the blog post.


What would be the value of program key in case of library projects?


If you want to run a binary in a debugger, you need a binary. You can’t run a library by itself.


Good work, be weary that the Rust Core team are hoping for us to use rust-lldb instead of the native lldb on your systempath.

this is a simple change in vscode-lldb, just set lldb.executable to rust-lldb

I woudln’t worry about this right away, but worth keeping in mind.
Some projects can debug with rust-lldb but not with normal lldb


Have you gotten the integrated format-on-save to work with the RLS extension? It’s never worked for me.


@masonk This works for me


If you have some test cases for your library, cargo test will print the path to the test executable before running it (e.g. Running target/debug/deps/crlf-517b5e102bb946b4). You can use that executable to debug your test cases.


I’m using the rust-lang right now… and well, it is beta, it should become much faster. Also I’m wondering if the coding support works all the way?!
What is your experience?
Most of the time I don’t get any advices on useable functions and so on. If you compare this to Java IDEs or also TypeScript support in vscode, rust-lang is just one step ahead of a bare text editor.


The vscode-lldb plugin has cargo support now.


Hello. Apologies for the necro,but I attempted to use the launch.json config you posted and got the error shown in the screenshot.


Please verify the the file is actually there. Did you already run cargo build?

If that looks okay, try adding .exe extension at the end (though it should have been detected automatically by extension, but, you know, bugs…).


Hello. Thanks for your response.

I ran cargo build,then got this.


Which LLDB version are you using and which target are you building for (-gnu or -msvc)?


I’m running the newest windows version of LLDB. I don’t know what target I’m building for. How can I check that?


Execute rustup show. The last two lines shows which version you use and the target you build for:

active toolchain

beta-x86_64-pc-windows-msvc (default)
rustc 1.31.0-beta.22 (d2e3b5332 2018-12-01)

In my case, i run MSVC, as seen by beta-x86_64-pc-windows-msvc. Had I run gnu, it would have stated beta-x86_64-pc-windows-gnu.


I’m running MSVC.


Yes, please run rustup show, preferably in the directory where your project resides. What’s the output of lldb --version? Does your program start normally if you run it from VSCode terminal?


I’m running


For LLDB, I’m running version 6.0.0

When I compiled and ran the program via the normal windows command line,it runs.