toolchain: install matching rust-analyzer

[irvingouj@Devolutions (irvingoujAtDevolution)]

Keep rust-analyzer aligned with each repository toolchain

The current rust-analyzer extension bundles a server that requires Rust 1.94 or newer. This minimum was raised from 1.78 to 1.94, and the released code sets it to 1.94 at MINIMUM_SUPPORTED_TOOLCHAIN_VERSION.

These repositories intentionally pin older toolchains:

Repository	Rust toolchain
Gateway	1.90.0
picky-rs	1.88.0

Opening either repository now triggers an incompatible-toolchain warning. This adds the official rust-analyzer component next to rustfmt and clippy:

components = ["rustfmt", "clippy", "rust-analyzer"]

The VS Code extension has an explicit toolchain-server selection path. It calls rustup which rust-analyzer only when rust-analyzer is declared in the repository toolchain file. Otherwise, it falls back to its newer bundled server.

Why not install rust-analyzer locally?

Installing it is not enough. I already had the Rust 1.90 component installed for Gateway, but the extension did not select it because the repository did not declare it. The alternative is a machine-specific rust-analyzer.server.path, which every developer and editor would need to maintain separately.

Why not downgrade the extension?

The extension version is global, but these Rust versions are repository-specific. Downgrading it for these repositories would also downgrade it for newer Rust workspaces. The extension also updates automatically, so this workaround requires disabling updates or repeatedly downgrading it.

Why not upgrade the Rust toolchains?

That changes the compiler used by each repository and is much broader than fixing editor compatibility. Using the matching analyzer component preserves the existing compiler pins.

Why should an editor tool be declared by the repository?

These toolchain files already declare the repository's development tools through rustfmt and clippy. rust-analyzer is also an official Rust component. Declaring it keeps the compiler/analyzer pairing in the same place instead of duplicating it in local editor settings.

What is the tradeoff?

Rustup installs one additional development component in environments that honor the toolchain file. In return, contributors get a compatible analyzer automatically, without global extension downgrades or per-machine server configuration.

---

LLM Wrote, Irving Audited.

[Benoît Cortier (CBenoit)]

Just to make sure I understand the motivation: is this specifically about how the VS Code extension selects the server? With Helix, I can run rustup component add rust-analyzer from the repository and the rustup proxy automatically selects the component matching the pinned toolchain.

Could you clarify why VS Code’s bundled analyzer is unsuitable here? I’m trying to determine whether this is a repository-level requirement or a workaround for VS Code’s server-selection behavior, since declaring the component also installs it in CI.

[irvingouj@Devolutions (irvingoujAtDevolution)]

Benoît Cortier (@CBenoit) It's specific to VS Code, yeah — the extension doesn't pick up the toolchain's rust-analyzer unless the toolchain file declares it. Upside is it also covers the rest of the team: zero setup for whoever opens the repo.

It's also what the rust-analyzer maintainer points to: rust-lang/rust-analyzer#21261 (comment)

If you don't think it's worth the CI overhead, happy to close this.

[Benoît Cortier (CBenoit)]

Thanks, that clarifies the motivation.

I think we can get the best of both worlds by keeping rust-analyzer in rust-toolchain.toml, but making CI install its toolchain explicitly with only the components required by each job: rustfmt for formatting, clippy for lints, and no extra components for tests/builds. Setting RUSTUP_TOOLCHAIN=1.88.0 in CI would make it ignore the repository toolchain declaration.

This avoids repeatedly installing editor tooling on ephemeral runners while preserving the zero-configuration development experience. It would also stop test jobs from installing rustfmt and clippy, so the CI setup becomes leaner overall. The only drawback is duplicating the toolchain version in the workflow, unless we read it from rust-toolchain.toml.