Updating Rustup 1.29.3 while keeping the compiler fixed

The toolchain manager and the compiler have separate version numbers. I updated an isolated Rustup installation from 1.29.2 to 1.29.3, kept its linked compiler at 1.99.1, then compiled and ran a small program through that same toolchain.

That gives me a useful way to handle this patch: update the manager that selects the tools, then check which compiler a project actually uses.

Recorded versions from the isolated update and the compiled sample. Image by the author.

What the patch changes

The Rustup team reports two regression fixes in 1.29.3: an illegal-instruction failure on certain x86_64 CPUs without SSE4.1, and an unsupported-lock error on Solaris. Those are upstream release claims; this walkthrough does not reproduce either hardware-specific failure. [1]

If you already have Rustup, the release instructions say to stop programs using it and run:

rustup self update

The word self matters. This updates Rustup itself. It is different from asking Rustup to update installed Rust toolchains with rustup update. That broader command can also update the manager. [1]

Check both sides of the selection

I used separate CARGO_HOME and RUSTUP_HOME directories for the trial, with shell startup files left alone. Rustup documents these locations as configurable. [2] I linked an existing compiler under the custom name pinned-local; I did not download a fresh compiler or replace the usual installation.

Here is the version ledger:

Component	Before	After
Rustup	1.29.2	1.29.3
Linked Rust compiler	1.99.1	1.99.1

To check the selection in that shell, I ran:

rustup --version rustup show active-toolchain rustc --version

The active toolchain was pinned-local (default). Keep the complete version output when troubleshooting; the table above extracts the version fields so the two components are easy to compare.

Rustup's rustc and cargo commands are proxies: they pass the invocation to a selected toolchain. Updating that routing program does not, by itself, request a different compiler. [3]

There is one practical prerequisite here: the shell must be reaching those proxies. A rustc supplied by another installation can produce a perfectly valid version line while bypassing the Rustup selection you intended. Mayur Kumbhar's environment setup walkthrough makes the related point that verifying the compiler and Cargo in a fresh shell is part of installation, rather than an optional last step. [4]

Compile through the named toolchain

For a small end-to-end check, I saved this as demo.rs:

fn main() { let values = [2_u32, 3, 5]; println!("sum={}", values.iter().sum::<u32>()); }

Then I selected the linked toolchain explicitly:

rustup run pinned-local rustc demo.rs -o demo ./demo

The executable printed:

sum=10

pinned-local is the custom name from this trial, not a toolchain Rustup ships. Use a toolchain you have actually installed or linked when adapting the command.

This is a narrow update check: manager version, compiler selection, compilation and program output. It does not test all Cargo dependencies or establish that a project will build on every target. For a real project, keep its selected compiler visible alongside the manager version. “Rust updated” hides a distinction that the tools themselves already let you inspect.