When will the RLS be released?

by Nick Cameron

tl;dr: the RLS is currently in 'preview' status. The RLS preview is usable with stable Rust from version 1.21. We hope to have an official (1.0, non-preview) release of the RLS in early 2018.

The Rust Language Server (RLS) is the smarts behind support for Rust in Visual Studio Code, Atom, and many other editors. It is a key component of the Rust IDE story, and we expect it to be used by a large chunk of the Rust community. The RLS is still work in progress, but its stability and quality are improving and we are working towards a 1.0 release. In this blog post, I'm going to go over how the RLS is being versioned and distributed.

Since the RLS integrates closely with the compiler, it is 'inside the unstable boundary'. To support developers using the stable toolchain, therefore, the RLS needs to be a part of the Rust distribution. For most users, that means that the RLS will be installed using Rustup. The RLS will not be installed by default (since many users won't use it); editors which use the RLS should install it automatically (our Visual Studio Code extension does this, for example). If you're using a well-supported editor and Rustup, then most of the issues discussed here will be handled for you without issue.

The RLS preview

The RLS is currently in preview status, which means it is pre-1.0 in terms of stability, quality, and feature-completeness. We hope to announce a 1.0 release at the end of 2017 or early in 2018.

The naming of the RLS Rustup component reflects this status: it is currently called rls-preview. When we make our first (1.0) release it will be renamed to rls. Rustup and your editor will take care of renaming, and users of rls-preview should be moved to rls without any intervention.

Rust channels

The RLS preview can (from Rust version 1.21) be installed with the Rust nightly, beta, and stable toolchains.

Future changes to the RLS will 'ride the trains' from nightly to beta to stable Rust releases. When we are ready for the RLS to be released, the change from rls-preview to rls will also follow this model.

For nightly RLS users, there is a slight hiccup. Because the RLS is so closely linked with the compiler, it is sometimes impossible to make a change to the compiler without breaking the RLS. When this happens there might be a day or a few days where the nightly channel is missing the rls-preview component.

If you want to keep using the RLS you will need to either stick to a nightly release which includes the RLS (either by avoiding rustup update or by updating to a specific nightly which includes the RLS), or use the stable or beta channels. We realise this is sub-optimal for nightly users and we plan to mitigate this somewhat with UI improvements to rustup.

Version numbers

Since the RLS is being distributed with Rust, we want to link the version numbers to the Rust version numbers is a straightforward way. However, we also want to maintain semver compatibility.

While the RLS is in preview, it will will use a 0.x.y versioning scheme, where 'x' corresponds to the Rust version. So the first version of the RLS distributed with Rust 1.21.0 will be 0.121.0. Once we have an official release, we will use a 1.x.y scheme where '1.x' corresponds to the Rust version, so (assuming we are out of preview) the first version of the RLS distributed with Rust 1.30.0 will be 1.30.0.

In both cases 'y' is incremented with each RLS version available on beta or stable. Different versions of the RLS on the nightly channel will have the same version number, but can be identifed by the build date. (We will release multiple versions of the RLS on nightly, a small number of versions on beta, and hopefully never on stable). For example we might have version 1.30.2, which would be the third version of the RLS distributed with Rust 1.30 (stable or beta).

Other tools

We have no firm plans for other tools, but if this pattern works for the RLS, we expect to follow it for Rustfmt and perhaps other tools.

When will the RLS be ready for its 1.0 release?

We're hoping late 2017 or early 2018. Our criteria for a release are about stability for a majority of users. I.e., we are not blocking a release on any new features, but the features that exist today should work without bugs for nearly all users, nearly all of the time.

One key area for many users is support for Cargo workspaces, this is mostly implemented thanks to Xanewok (see this blog post for a summary, and look for some earlier blog posts for more details). The remaining work is ensuring that the implementation works reliably across different project layouts and then ironing out any bugs.

We also want to improve our coverage of Rust code - currently there are a few places where we lack sufficient detail in our data (unions are an obvious example). We won't be perfect here, but we plan to make some big improvements.

Exactly what will be in the 1.0 release is tracked in this milestone and this issue.

Beyond 1.0

Of course development doesn't stop with the first official release. There is plenty to work on post-1.0. There are many ways to incrementally improve the IDE experience - squash bugs, improve performance, and improve usability. There are also plenty of new features to implement - I'm particularly excited about adding more refactoring support and integrated debugging.

One of the biggest 'under the covers' changes will be working with incremental compilation. Currently, incremental compilation only covers code generation, which the RLS skips completely. Once type checking can reliably be done incrementally, we can take advantage of that in the RLS to give much quicker responses. We should then be able to use the compiler for code completion, to give a better experience, and for new features such as showing the traits which are implemented for a type.