Features, Diagnostics, and Assists

Purpose and Scope

This page orients users and tool integrators to the rust-analyzer surfaces that appear inside an editor: interactive features, diagnostics, and assists. In rust-analyzer terminology, diagnostics are warnings or errors shown for source code, while assists are code actions that perform small local refactorings at the current cursor position or selection. Editor features include visual customization, keybinding contexts, runnable configuration, and the generated catalog of language-server capabilities. Together these pages explain what a developer sees while writing Rust and which settings influence that experience. Sources: src/tools/rust-analyzer/docs/book/src/editor_features.md, src/tools/rust-analyzer/docs/book/src/diagnostics.md, src/tools/rust-analyzer/docs/book/src/assists.md, src/tools/rust-analyzer/docs/book/src/features.md

The rust-analyzer book separates these topics because they answer different user questions. A user who wants better visual feedback starts with editor feature settings, such as inlay hint colors or semantic token styles. A user who wants stricter checking starts with diagnostics and the check command. A user who wants faster edits looks at assists and invokes them from the editor light bulb or shortcut. The shared idea is that rust-analyzer is not only a background parser; it is an interactive layer that adapts Rust project knowledge into editor actions, decorations, and feedback loops.

Relevant Source Files

• src/tools/rust-analyzer/docs/book/src/editor_features.md - Documents VS Code-facing customization examples, including inlay hint styling, semantic token styling, Rust-project-only keybinding context, and runnable environment variables.
• src/tools/rust-analyzer/docs/book/src/diagnostics.md - Explains that most warnings and errors are supplied through check integration, names the rust-analyzer diagnostic settings, and shows how to switch checking to Clippy.
• src/tools/rust-analyzer/docs/book/src/assists.md - Defines assists as context-sensitive code actions and explains the cursor marker convention used by generated assist examples.
• src/tools/rust-analyzer/docs/book/src/features.md - Provides the top-level features page that includes the generated feature catalog for the rust-analyzer book.

Core Primitives

The first primitive is the editor feature itself: a user-visible capability exposed through the language server and surfaced by an editor. The documentation snippet gives concrete examples for VS Code, including inlay hint appearance, semantic token styling, and keybindings that are active only in Rust projects. These examples matter because many rust-analyzer features are not invoked as separate commands by the user. They are rendered as hints, colors, decorations, context-aware commands, or run buttons, so the practical configuration point is often the editor settings file rather than a Rust source file.

The second primitive is the diagnostic. The diagnostics page states that most errors and warnings shown by rust-analyzer come from integration with the normal project checking workflow, while a growing set is implemented by rust-analyzer analysis itself. This distinction helps explain why a diagnostic may feel like compiler output in one case and an editor-native warning in another. The same page also notes that some rust-analyzer diagnostics do not yet respect source attributes that allow or deny lints, so users should control them through rust-analyzer settings when necessary.

The third primitive is the assist, also described as a code action. Assists are deliberately local: they appear in a particular syntactic and semantic context, are commonly opened through a shortcut or light bulb, and operate around the cursor or selected text. The assist documentation uses a special marker character to show where the cursor is placed in examples. That convention signals how important context is. The same source code can offer different assists depending on whether the cursor is on a binding, expression, module item, type, or selected range.

Editor Feature Configuration

The editor features page provides several practical VS Code customization patterns. For inlay hints, the documented settings adjust font family, font size, foreground color, background color, and hint-kind-specific colors. Inlay hints are useful because they add type or parameter information without changing the source file, but they can become visually noisy if they look too similar to normal code. The configuration examples show that rust-analyzer relies on standard editor theme mechanisms, so teams can tune readability while keeping the underlying Rust code untouched.

Semantic styling is another important feature area. The documentation shows that mutable bindings are underlined by default and that the underline can be removed through semantic token customization. It also calls out unsafe operations, naming rules for unsafe operators, functions, and methods. This is a useful workflow detail: unsafe code is syntactically valid Rust, but many teams want it to stand out during review and editing. By configuring semantic token rules, a project can make risky operations visually distinct even before diagnostics or review comments are involved.

The editor features page also introduces a special keybinding context for Rust projects. In VS Code, the context can be used in a keybinding rule so that a command such as opening Rust documentation only becomes active when the workspace is recognized as a Rust project. This avoids global shortcut conflicts and makes rust-analyzer commands feel native to the project. It also hints at the broader model: rust-analyzer provides project-aware editor state, and the editor can use that state to decide when a command, binding, or action should apply.

Runnable environment variables are configured through the runnables extra environment setting. The simplest form applies variables to all runnables, while the more detailed form uses rules with masks, environment maps, and optional platform filters. The documentation explains that runnable names can distinguish binaries, single tests, and test modules, so regular expression masks can target only the desired command family. This is especially useful for projects that need different environment variables for slow tests, examples, platform-specific data, or integration tests without permanently changing the project manifest.

{
  "editor.inlayHints.fontFamily": "Courier New",
  "editor.inlayHints.fontSize": 11,
  "rust-analyzer.check.command": "clippy",
  "rust-analyzer.runnables.extraEnv": {
    "RUN_SLOW_TESTS": "1"
  }
}

Diagnostics Flow

Diagnostics begin with the normal Rust checking loop. The diagnostics page says that most errors and warnings provided by rust-analyzer come from cargo check integration. In practice, that means the editor can reflect the same kinds of project-level type errors, borrow checking failures, and warnings that a developer expects from command-line checking. rust-analyzer then supplements that stream with its own analysis-based diagnostics. The user-visible result is a combined editing experience: some messages are produced by the build check command, and others are computed directly by rust-analyzer while the file is open.

The page gives three settings categories for controlling rust-analyzer diagnostics: an overall enable switch, an experimental diagnostics switch, and a disabled list. These settings are important when diagnostics are noisy, premature for a project, or not aligned with a codebase policy. Because the documentation notes that some diagnostics do not yet honor source attributes that allow or deny lints, the settings layer is the safer operational control for editor behavior. A team can keep compiler lint attributes for build policy while separately deciding which editor-native diagnostics should appear during development.

Clippy integration is represented as a simple command selection. Instead of running the default check command, users can set the check command to Clippy. This is a small configuration change, but it changes the diagnostic character of the editor because Clippy contributes a broader lint perspective than plain checking. It is best treated as a workflow choice: teams that expect Clippy cleanliness can surface those warnings earlier in the editor, while teams that want a lighter editing loop may keep the default checker and run Clippy separately in continuous integration.

Assists and Code Actions

Assists are the editing counterpart to diagnostics. A diagnostic usually tells the developer that something may be wrong or worth changing, while an assist offers an intentional transformation for the code under the cursor. The assists page emphasizes that these are small local refactorings and that they are available only in a particular context. That definition sets expectations correctly. An assist is not a whole-project migration engine; it is a focused operation designed to reduce repetitive editing, improve clarity, or apply a local Rust idiom when rust-analyzer has enough context.

The documentation’s cursor marker convention is more than a formatting detail. It teaches readers how to evaluate an assist example: the same text can be valid Rust, but the assist availability depends on the exact cursor position or selection. When writing tests, documentation, or bug reports for assists, include the caret location and the intended selection range. When using assists interactively, move the cursor to the syntactic item you want to transform before opening the editor action menu. That habit makes the code-action list shorter, more relevant, and easier to reason about.

Compact Reference

Practical Workflow

A useful setup flow starts with the default rust-analyzer installation and then customizes only the surfaces that affect day-to-day editing. First, tune visual feedback: make inlay hints readable, decide whether mutable bindings should remain underlined, and consider highlighting unsafe operations. Next, decide how strict diagnostics should be. If the project treats Clippy as part of normal development, switch the check command to Clippy; otherwise, keep the default and use the diagnostic enablement settings only for noisy editor-native checks. Finally, configure runnable environment variables for tests or examples that need predictable runtime context.

For troubleshooting feature behavior, separate the question into rendering, checking, and action availability. If a hint or color looks wrong, inspect editor theme and semantic token settings. If a warning looks unexpected, identify whether it comes from the check command or rust-analyzer analysis and then adjust the relevant diagnostic setting. If an assist is missing, verify cursor position, selection, and surrounding syntax before assuming the refactoring is unavailable. These source-backed divisions match the rust-analyzer book structure and give users a practical path from symptom to configuration point.

Next Steps

After this page, read the rust-analyzer configuration page to understand how settings are generated and organized across editor integrations. Then read the installation and editor integration pages if rust-analyzer features do not appear at all in the editor. For deeper language learning, use the official Rust tutorial and example material alongside the editor: diagnostics and assists are most useful when the reader understands the ownership, type, module, and pattern concepts that rust-analyzer is explaining or transforming in real time.