Rust core devs mull adoption of alternative compiler front-end for improved IDE support

'I move that we merge this RFC,' says Moz's Nico Matsakis

4 Reg comments Got Tips?

An alternative compiler front-end called rust-analyzer has been proposed for official adoption to improve IDE support for Rust developers, and has won backing from the programming language's core team.

A recent Rust survey showed that improved tooling is high on the list of wants, and rust-analyzer could be part of the solution by providing fast code navigation, syntax highlighting, instant run of a function in the code editor, code completion hints, and "light bulb" suggestions that write code for you.

The main author of rust-analyzer is Aleksey Kladov, who worked on the IntelliJ plugin for Rust at JetBrains and now works on Rust solutions at Ferrous Systems. In the rust-analyzer announcement, Kladov said that the project "is directly inspired by the experience of developing IntelliJ Rust". He has submitted an RFC proposing that rust-analyzer is officially adopted as the official LSP (Language Server Protocol) implementation for Visual Studio Code, in place of the existing Rust Language Server (RLS).

The RFC proposes a transition period which begins with feedback on rust-analyzer, then as a second stage deprecates RLS, and finally stops supporting RLS.

rust-analzer is designed for IDE support but will also influence the evolution of the rustc compiler

rust-analzer, pictured, is designed for IDE support but will also influence the evolution of the rustc compiler ... Click to enlarge

Smart features in an code editor or IDE do a lot of work under the covers. The best way to check whether code is syntactically correct is to try compiling it. On the other hand, most compilers are not optimized for driving smart features in IDEs. For C#, Kladov noted, Microsoft rewrote the compiler as the Roslyn project partly to get rich IDE support. Recent languages including Kotlin and TypeScript were "implemented with IDEs in mind from the start", he said, while the compilers for Dart and Swift were reworked again with this need in mind.

The Rust compiler, rustc, has a monolithic codebase and is optimised for batch compilation rather than IDE interaction, Kladov said. "For example, the compiler currently interns all of its types and frees them all at once at the end of compilation. This is highly efficient but not necessarily appropriate for a long-lived process, as over time it can lead to very high memory usage." The existing RLS works by compiling code and saving analysis data, which it then parses "to do things like display errors, handle jump-to-definition" and so on. This is slow and not suitable for features like code completion, which require low latency.

In Rust we trust? Yes, but we want better tools and wider usage, say devs


Rust-analyzer gets round this by in effect reimplementing the compiler "in a fully incremental, on-demand style". This makes it faster and able to support more features, though it is not yet complete; the project's status is alpha. Early users like it – the project has 23,000 downloads and five stars as a VS Code extension. "For me, rust-analyzer has been the superior option for some time now," said a Rust developer on GitHub.

The obvious downside is that whereas RLS simply builds on rustc, rust-analyzer is in effect a second compiler which has to be kept in sync with rustc. Kladov argued that rustc should be modularised by splitting it into libraries, which is already a stated objective, so that rust-analyzer can be just a "shallow front-end" for libraries shared with rustc. It does mean that official adoption of rust-analyzer has far-reaching implications for the language, not only in improving its tool support, but for the complier technology itself.

The RFC has good support, though there are dissenting voices, particularly with respect to timing. "My plea, again as a newcomer, is to not deprecate rls in favor of rust-analyzer until it can truly be a drop-in replacement for the former. Right now, as exciting as the development of a new LSP server is, it's not there yet," said developer Seth Bromberger.

Niko Matsakis, a member of the core Rust team at Mozilla, supports the RFC and has proposed to merge it. He did say that the exact timing of the transition is still to be worked out, and that "before rust-analyzer is adopted as our official client, it should fully conform to the LSP protocol, and I will add a note to that effect." Currently there are some shortcomings in this area. That said, Matsakis argued that feature parity with RLS is not essential as it could "slow progress towards our ultimate goals".

It has also won support from Igor Matuszewski, who said: "I'm in favour of merging this as the RLS maintainer."

This RFC, therefore, looks likely to be approved. ®


Biting the hand that feeds IT © 1998–2020