Rustup 1.17 makes toolchain state easier to inspect

A toolchain manager's most useful answer is often which tools it is actually about to run. Rustup presents a stable set of command names while selecting among installed toolchains behind them. Rustup 1.17 improves several ways to inspect that state, including listing installed components and opening more of the selected toolchain's documentation directly.

The March 5 changelog records these changes alongside installation fixes and Rust 2018 work. The edition entry requires care when interpreting the release. Its implementation patch migrates rustup's own packages to the 2018 edition. It does not describe a new edition selection mechanism for every project managed by rustup.

I like Rust's attention to explicit semantics, and the surrounding tools need the same clarity. Selecting a toolchain, knowing its components and reading its documentation are distinct operations. A manager that exposes those distinctions helps explain why a command behaves differently across project directories.

Command names are proxies for selected tools

The versioned rustup README describes rustup as a toolchain multiplexer. The rustc and cargo commands it places in Cargo's binary directory are proxies. They delegate to the real tools in the selected toolchain.

This means the command's path is only part of the explanation. A single proxy can run a stable compiler or a nightly compiler depending on toolchain selection. Changing the selection need not change the proxy's filename. Inspecting that selected state is therefore more informative than assuming a familiar executable name identifies a particular compiler build.

Rustup 1.17 makes rustup default without arguments print the default toolchain. It also aligns the output of that command and rustup show active-toolchain with the rest of the tool's output. Default and active state remain different concepts, because selection can be affected by the project context described in the README.

The release adds rustup component list --installed to report installed components. This narrows a component query to what is present, which matters when a developer expects a supporting tool to accompany the compiler. Availability in a channel and installation in a local toolchain should not be treated as interchangeable facts.

Documentation follows the toolchain context

The documentation-command patch expands the documents accessible through rustup doc. Its implementation selects an explicit or directory-selected toolchain and then chooses the requested document's index path.

The newly supported flags include the edition guide, Cargo's book, the compiler and rustdoc documentation, and the Nomicon. The same mapping also contains documentation for core, alloc and other library components. Adding a flag does not independently stabilize the APIs described by a document. It provides a route to the documentation installed with the chosen toolchain.

For example, the command interface can open the edition guide or print the path to the Nomicon without opening it.

rustup doc --edition-guide
rustup doc --nomicon --path
rustup component list --installed
rustup show active-toolchain

The --path behavior is useful when the local documentation needs to be inspected through a separate viewer. More generally, these commands keep the selected toolchain visible in the documentation workflow. A current web page and an older compiler do not necessarily describe the same available operations.

The edition change belongs to rustup's implementation

The Rust 2018 patch states that it ran cargo fix --edition across rustup's packages, then added edition = "2018" to their manifests. Its code changes include explicit crate:: paths for internal imports. These are source migration steps for the manager itself.

That differs from fixing a user's project's edition automatically. The event's short summary can suggest that broader behavior, but the source supports the narrower claim. An article about this release should distinguish improvements in rustup's implementation from new controls offered to its users.

This distinction also helps explain why the changelog contains code-formatting and idiom changes alongside user-visible flags. A changelog records development work at several levels. Reading the linked patch is necessary before translating each entry into a promise about a user's workflow.

I prefer that narrower account because toolchain behavior is already layered. Rustup selects the tools, Cargo reads project metadata and the compiler implements language rules. A migration in the manager's own source does not collapse those responsibilities into one edition switch.

Installation and proxy fixes preserve ordinary inputs

Other entries fix a panic when a component is missing and improve errors around failed component installation. The changelog also records cleaner handling of a malformed default host and a better error for a missing binary. These are useful failure-path changes without implying that every installation failure shares one cause.

Proxy handling now allows non-UTF-8 arguments. Since the proxy sits between the shell and the real tool, preserving arguments is part of its job. The release also adds a clippy-driver proxy, extending the set of tool invocations rustup can dispatch.

The March release is therefore about more than installing a new compiler. It improves the manager's account of selected and installed state, expands access to local documentation and corrects several boundaries around installation and dispatch. The versioned source makes clear which changes affect those external behaviors and which modernize rustup's own code.