Convert Figma logo to code with AI

rust-lang logorls

Repository for the Rust Language Server (aka RLS)

3,513
257
3,513
293
View on GitHub

Top Related Projects

racer-rust's avatar

racer

3,357

Rust Code Completion utility

autozimu's avatar

LanguageClient-neovim

3,548

Language Server Protocol (LSP) support for vim and neovim.

rust-lang's avatar

rust-clippy

11,247

A bunch of lints to catch common mistakes and improve your Rust code. Book: https://doc.rust-lang.org/clippy/

Quick Overview

The Rust Language Server (RLS) is a tool that provides language support for Rust in various integrated development environments (IDEs) and text editors. It offers features like code completion, go to definition, find all references, and more, enhancing the development experience for Rust programmers.

Pros

  • Provides rich IDE features for Rust development
  • Supports multiple editors and IDEs through the Language Server Protocol
  • Improves code navigation and understanding in large Rust projects
  • Offers real-time error checking and diagnostics

Cons

  • Performance can be slow on larger projects
  • Sometimes lags behind the latest Rust language features
  • May occasionally provide inaccurate or incomplete results
  • Requires additional setup compared to built-in language support

Getting Started

To use the RLS, you'll need to install it and configure your editor. Here's a general guide:

  1. Install Rust and Cargo:

    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

  2. Install RLS:

    rustup component add rls rust-analysis rust-src

  3. Install a compatible editor extension (e.g., "Rust" for VS Code)

  4. Open a Rust project in your editor and wait for RLS to initialize

Note: Specific steps may vary depending on your editor and operating system.

Competitor Comparisons

racer-rust logo

racer

3,357

Rust Code Completion utility

Pros of racer

  • Faster and more lightweight, suitable for quick code completion tasks
  • Can be used as a standalone command-line tool
  • Easier to integrate into various text editors and IDEs

Cons of racer

  • Less comprehensive analysis compared to RLS
  • May provide less accurate results in complex code scenarios
  • Limited to code completion and basic go-to-definition functionality

Code Comparison

racer:

use racer::Session;
let mut session = Session::new();
let completions = session.complete_fully("std::io::B", 11, "main.rs", None);

RLS:

use rls_analysis::{AnalysisHost, AnalysisLoader};
let host = AnalysisHost::new(AnalysisLoader::new());
let analysis = host.analysis();
let completions = analysis.completions(file_path, line, column, &config);

Summary

Racer is a lightweight, fast code completion tool for Rust, while RLS (Rust Language Server) is a more comprehensive language server implementation. Racer excels in quick code completion tasks and can be easily integrated into various editors. However, RLS provides more in-depth analysis and a broader range of language features, making it more suitable for full-featured IDE experiences. The choice between the two depends on the specific needs of the development environment and the desired balance between speed and feature completeness.

autozimu logo

LanguageClient-neovim

3,548

Language Server Protocol (LSP) support for vim and neovim.

Pros of LanguageClient-neovim

  • Supports multiple programming languages, not limited to Rust
  • Integrates with Neovim, providing a more seamless editor experience
  • Actively maintained with frequent updates and improvements

Cons of LanguageClient-neovim

  • Requires additional setup and configuration compared to RLS
  • May have higher resource usage due to its multi-language support
  • Less specialized for Rust-specific features and optimizations

Code Comparison

LanguageClient-neovim configuration:

let g:LanguageClient_serverCommands = {
    \ 'rust': ['rustup', 'run', 'stable', 'rls'],
    \ }

RLS usage in Rust project:

[package]
name = "my_project"
version = "0.1.0"
edition = "2018"

[dependencies]
rls-data = "0.19"

Summary

LanguageClient-neovim offers broader language support and tighter Neovim integration, making it suitable for developers working with multiple languages. However, it requires more setup and may consume more resources. RLS, being Rust-specific, provides a more streamlined experience for Rust developers with potentially better performance and specialized features. The choice between the two depends on the user's specific needs and workflow preferences.

rust-lang logo

rust-clippy

11,247

A bunch of lints to catch common mistakes and improve your Rust code. Book: https://doc.rust-lang.org/clippy/

Pros of Clippy

  • More comprehensive linting and static analysis capabilities
  • Offers a wider range of customizable lints and suggestions
  • Regularly updated with new lints and improvements

Cons of Clippy

  • Primarily focused on linting, lacking full language server capabilities
  • May produce false positives or overly aggressive suggestions in some cases

Code Comparison

RLS (Language Server Protocol implementation):

use rls_analysis::AnalysisHost;
use rls_vfs::Vfs;

struct RLS {
    analysis: AnalysisHost,
    vfs: Vfs,
}

Clippy (Lint implementation):

use rustc_lint::{LateContext, LateLintPass};

declare_lint! {
    pub EXAMPLE_LINT,
    Warn,
    "an example lint that does something"
}

Summary

RLS and Clippy serve different purposes in the Rust ecosystem. RLS is a language server implementation providing features like code completion and go-to-definition, while Clippy is a powerful linting tool offering extensive static analysis and code improvement suggestions. RLS offers broader IDE integration, whereas Clippy excels in catching potential issues and enforcing best practices. Both tools are valuable for Rust developers, often used in conjunction to enhance the coding experience and maintain code quality.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

⚠️ RLS is no longer supported

RLS has been deprecated and is no longer supported. It has been replaced with rust-analyzer. Users are encouraged to uninstall RLS and follow the instructions in the rust-analyzer manual to install it for your editor.

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 LSP client 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 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.