VS Code and Other Editors

Purpose and Scope

This page helps developers choose and set up an editor integration for rust-analyzer, the Rust language server used for completions, diagnostics, code navigation, assists, and related editor features. The rust-analyzer book treats Visual Studio Code as the most supported integration, while also documenting editor-neutral use through the Language Server Protocol. The practical decision is therefore not whether rust-analyzer is tied to one editor, but which client should start the server, manage updates, expose configuration, and surface rust-analyzer-specific commands in a way that matches the user’s workflow.

Sources: src/tools/rust-analyzer/docs/book/src/vs_code.md, src/tools/rust-analyzer/docs/book/src/other_editors.md

The recommended starting point for most users is the VS Code extension because it is maintained in tree with rust-analyzer and receives the clearest installation, update, nightly, manual VSIX, and source-build instructions. Users of Emacs, Vim, or Neovim should think of rust-analyzer as a separate server binary paired with an editor LSP client. That distinction matters for troubleshooting: in VS Code the extension commonly owns server download and placement, while other editors may require the binary to already exist on the user’s path or in a configured location.

Relevant Source Files

• src/tools/rust-analyzer/docs/book/src/vs_code.md — Documents the VS Code extension as the best-supported editor path, including marketplace installation, conflicts with the older Rust extension, server binary locations, update behavior, nightly releases, manual VSIX installation, source builds, and Flatpak-specific considerations.
• src/tools/rust-analyzer/docs/book/src/other_editors.md — Documents the editor-agnostic Language Server Protocol model and concrete setup guidance for Emacs and Vim/Neovim clients, including Eglot, LSP Mode, coc-rust-analyzer, configuration examples, and client capability differences.

Core Primitives

The main primitive is the rust-analyzer language server binary. It is the process that understands Rust projects and speaks the Language Server Protocol to an editor client. In VS Code, the Rust Analyzer extension normally manages this binary and may ask permission to download the matching server version when necessary. In other editors, the documentation assumes the binary has already been installed, and the editor’s LSP client is responsible for finding and launching it. Keeping this server-client split clear makes installation choices easier to reason about.

Sources: src/tools/rust-analyzer/docs/book/src/vs_code.md, src/tools/rust-analyzer/docs/book/src/other_editors.md

The second primitive is the editor integration itself. For VS Code, that integration is the rust-analyzer extension published in the marketplace and maintained alongside rust-analyzer. For Emacs, the integration is an LSP client such as Eglot or LSP Mode. For Vim and Neovim, the visible documentation starts with coc-rust-analyzer and describes how it implements most features supported by the VS Code extension. These integrations vary in how much they support rust-analyzer protocol extensions, automatic binary management, inlay hints, commands, and visual UI features.

The third primitive is configuration. The VS Code path uses settings such as rust-analyzer.server.path when a user installs an extension without a bundled server or wants to point at a custom binary. Emacs examples show initialization options that set the check command to clippy. The Vim/Neovim coc-rust-analyzer section says it uses the same configurations as the VS Code extension, including server path and cargo feature settings. Configuration therefore belongs at the boundary between the editor client and the server it starts.

VS Code Setup Workflow

Install the VS Code extension from the marketplace when you want the supported default experience. The book explicitly warns that the rust-analyzer extension can conflict with the older official Rust plugin, which is no longer maintained and should be uninstalled. This warning is important because duplicate Rust language integrations can race to provide diagnostics, completions, and project analysis for the same buffers. After installation, VS Code users should let the extension manage ordinary updates and server matching unless they have a specific reason to use a source build or manual VSIX.

Sources: src/tools/rust-analyzer/docs/book/src/vs_code.md

The extension stores the server binary under the editor extension installation area, with distinct locations for local Linux or macOS VS Code, Remote or WSL VS Code, and Windows. NixOS is called out as an exception because the extension copies the server into Code global storage. The documentation also states that only the two most recent versions of VS Code are supported. When diagnosing an unexpected installation problem, check both the VS Code version and whether the editor environment is local, remote, NixOS, or another packaging model before changing rust-analyzer settings.

Updates are normally automatic, and the extension can request permission to download a matching language server binary. Users who want to test the newest code can enable pre-release versions on the VS Code extension page, because nightly releases are shipped for VS Code. Manual installation is available by downloading a platform-specific VSIX from the releases page and installing it through the Extensions: Install from VSIX command or the command line. Unsupported platforms can use the no-server VSIX and provide a server binary separately.

code --install-extension /path/to/rust-analyzer.vsix

{ "rust-analyzer.server.path": "~/.local/bin/rust-analyzer-linux" }

Building from source is a developer-oriented path rather than the ordinary user path. The documented command installs both the server and the Code plugin through xtask, and it requires Cargo, nodejs matching a supported VS Code version, and npm. The book also notes that xtask installation does not work for VS Code Remote, so remote users need the manual VSIX path instead. If the user is not using Code, they can install only the LSP server and ensure the intended binary appears in path before the rustup proxy named rust-analyzer.

git clone https://github.com/rust-lang/rust-analyzer.git && cd rust-analyzer
cargo xtask install
cargo xtask install --server

Flatpak, Remote, and Platform Edge Cases

Flatpak versions of VS Code or VSCodium need special care because the Flatpak sandbox changes access to system binaries and libraries. The book explains that some directories can be exposed, but the system path under the host is mounted differently, which can prevent access to the system C compiler, a system-wide Rust installation, or libraries needed for linking. Some compilers and libraries can instead be supplied as Flatpak SDK extensions. Users choosing this route must make those SDKs visible to the editor environment before expecting rust-analyzer checks to behave like a normal host install.

Sources: src/tools/rust-analyzer/docs/book/src/vs_code.md

The Flatpak guidance also separates SDK-based Rust from rustup-based Rust. If using SDK extensions, the Rust and LLVM extensions must be installed and enabled through the editor environment. If using Flatpak together with rustup, the documentation begins by requiring Rust and rustup from the standard rustup installer rather than distribution packages. The reason is practical: rust-analyzer often needs to invoke Cargo, rustc, build scripts, proc macros, linkers, and project-specific tools, so the editor sandbox must expose a coherent toolchain instead of only the language server executable.

Emacs Integration

Emacs support is built around LSP clients. The rust-analyzer book names Eglot and LSP Mode as the two popular choices and says both enable rust-analyzer by default in Rust buffers when it is available. Eglot is described as more minimal and lightweight, integrated with existing Emacs functionality, and built into Emacs starting with release 29. After installing it on older Emacs versions, users can start it manually or add a hook so Rust buffers ensure an Eglot session automatically.

Sources: src/tools/rust-analyzer/docs/book/src/other_editors.md

(add-hook 'rust-mode-hook 'eglot-ensure)

For Eglot users who want clippy-powered checking, the documentation shows passing initialization options that set the check command to clippy. This is a useful example because it demonstrates where rust-analyzer behavior is configured when the editor integration is not VS Code. The same section also warns that Eglot does not support rust-analyzer extensions to the language-server protocol and does not plan to do so. Users who rely on extension-specific commands or richer protocol features should evaluate whether experimental add-ons or a different client better fit their expectations.

(add-to-list 'eglot-server-programs
             '((rust-ts-mode rust-mode) .
               ("rust-analyzer" :initializationOptions (:check (:command "clippy")))))

LSP Mode is described as the original Emacs LSP client, with a larger codebase and support for more features, including LSP protocol extensions. It also integrates with packages such as LSP UI and DAP mode, giving users a path toward richer visual feedback and debugging workflows. Setup can be manual with the lsp command or automatic through a Rust-mode hook. The book directs readers to LSP Mode’s own installation manual and rust-analyzer-specific section for additional options, commands, and key bindings.

(add-hook 'rust-mode-hook 'lsp-deferred)

Vim and Neovim Integration

The visible Vim and Neovim guidance begins by naming multiple LSP client implementations and then details coc-rust-analyzer. That extension is installed through coc.nvim, requires Node.js through the coc.nvim setup path, and is added with the CocInstall command. The documentation says coc-rust-analyzer implements most features supported in the VS Code extension, including automatic installation and upgrades for stable or nightly releases, shared configuration names, shared commands, and Neovim-only inlay hints for variables and method chains.

Sources: src/tools/rust-analyzer/docs/book/src/other_editors.md

:CocInstall coc-rust-analyzer

Two operational notes are important for coc-rust-analyzer users. First, the extension can install or update the rust-analyzer binary on its own, so users should understand whether their binary is managed by coc, installed manually, or coming from another source. Second, code actions should be invoked with cursor or selected variants, because the generic and line variants are described as unlikely to be useful. This is an example of editor-client ergonomics: the server provides code actions, but the client command chosen by the user determines whether the request has the right context.

Compact Reference and Next Steps

Use VS Code when you want the first-party, best-supported path with automatic extension updates, nightly pre-release testing, marketplace installation, manual VSIX fallback, and bundled server management. Use Emacs with Eglot when you prefer a minimal built-in client and can accept limited rust-analyzer protocol-extension support. Use Emacs with LSP Mode when you want a larger feature surface and optional UI or debugging integrations. Use Vim or Neovim with coc-rust-analyzer when you want a coc.nvim-based workflow that mirrors many VS Code settings and commands.

Sources: src/tools/rust-analyzer/docs/book/src/vs_code.md, src/tools/rust-analyzer/docs/book/src/other_editors.md

Before changing editor settings, confirm which component owns the server binary, which Rust toolchain the editor can see, and whether the editor is running locally, remotely, inside Flatpak, or under a platform-specific packaging model. Then configure only the narrow boundary that is wrong: install or update the extension, set the server path, expose the Rust toolchain to the sandbox, or adjust LSP initialization options. For adjacent topics, read the rust-analyzer installation page for binary acquisition and the configuration page for the meaning of individual rust-analyzer settings.