Rustup 1.20 selects nightlies that include the required tools

The newest compiler is not a complete development environment when the formatter or another required tool is missing from its distribution. Nightly Rust makes that distinction visible because optional components are not guaranteed to accompany every build. Rustup 1.20 changes the update search to find the newest nightly that actually includes the components a user needs.

The October 15 announcement describes backward search alongside installation profiles and better documentation lookup. The release changelog records the implementation work, including component and target selection during installation.

I find explicit tool requirements more useful than a vague promise to stay current. A formatter or analysis tool can be part of the expected environment even when it is not required to compile a file. An update policy should account for that requirement instead of silently leaving the user with a different collection of tools.

A nightly update searches for a compatible collection

The release announcement explains the previous problem. When the newest nightly lacked a component already installed in a user's toolchain, rustup prevented the upgrade. That preserved the component requirement but left the user to locate another usable nightly manually.

Starting with 1.20, rustup update walks backward from the newest nightly to find the most recent release containing all needed components. The candidate is a complete set under those constraints, rather than a compiler date considered independently of its accompanying tools.

If no newer nightly contains the required collection, the user still needs to wait or remove some requirements. Backtracking cannot produce a component that was never built. Its benefit is finding an available intermediate release that satisfies the existing selection without making the user search each date.

This also means the installed date can lag behind the latest advertised nightly for a good reason. The toolchain manager is satisfying component constraints, not necessarily failing to notice a newer compiler. Understanding that policy makes the update result easier to explain.

Installation accepts requirements up front

The release adds --component and --target to rustup toolchain install, with short forms -c and -t. These options let the requested components and targets participate in installation selection. The announcement says this path also searches past nightlies when the current one lacks the requested components.

For example, installing a nightly with an explicit formatter requirement can use this command.

rustup toolchain install nightly --component rustfmt

The command describes the intended environment at selection time. It differs from first installing whatever nightly is newest and only then discovering that a required component cannot be added. The manager can consider the requirement while choosing the toolchain.

The announcement contrasts nightly availability with stable releases on tier-one platforms, where most components are guaranteed. That qualification should remain attached to the statement. It does not establish the same guarantee for every tool on every target supported by rustup.

Profiles define the initial component set

Rustup's previous default installation included the compiler, Cargo, the standard library and local documentation. The announcement identifies unnecessary documentation installation on build servers and the cost of many files on Windows as reasons to offer smaller selections.

The new minimal profile contains rustc, rust-std and Cargo. Choosing default includes those tools and local documentation, adding rustfmt and Clippy. The complete profile contains all available components, including tools such as Miri and language-server support.

A user selects a profile with rustup set profile, for example rustup set profile minimal. The announcement explicitly limits its effect to newly installed toolchains. Changing the profile does not retroactively remove components from a toolchain already installed under another selection.

That boundary avoids a misleading expectation about cleanup. A profile is an installation policy, while adding or removing an individual component remains a separate operation. The choice can make future installations smaller without rewriting every existing environment immediately.

I prefer this distinction because installation defaults and current machine state answer different questions. A profile explains what the next installation should contain. Inspecting installed components explains what is present now, including deliberate additions made after installation.

Local documentation has an explicit prerequisite

Rustup 1.20 also lets rustup doc open documentation for a named item. The announcement gives rustup doc std::iter::Iterator as an example. Lookup supports traits, structures, enums, macros and modules in std, alloc and core.

This remains local documentation. The command needs the rust-docs component in the selected toolchain and does not require an internet connection to open it. A minimal profile omits that component, so selecting the smaller profile changes which documentation workflow is immediately available.

That is a concrete tradeoff rather than an inconsistency. A build server can avoid documentation it does not use, while a developer who wants local item lookup can install the component. The tool's behavior follows the selected installation contents.

Taken together, the changes make toolchain selection more precise. Profiles define the initial collection, explicit installation flags add requirements, and nightly backtracking finds an available release satisfying those requirements. The result can be older than the newest compiler while still being the newest usable toolchain for the requested environment.