Recommended toolchain install command line isn't exactly right

[cbiffle]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

In the behavior introduced in the latest release, the error message if you don't have the toolchain installed is not actually correct if your rust-toolchain.toml file formerly triggered the installation of more than just a toolchain. This is common in cross-compile situations with the targets key.

rustup 1.28 tells me:

[cbiffle@gwydion soundlaser-rs]$ cargo build
error: toolchain '1.85.0-x86_64-unknown-linux-gnu' is not installed
help: run `rustup toolchain install 1.85.0-x86_64-unknown-linux-gnu` to install it

...but that's not actually correct, because that does not install the targets listed in the toml. cargo build fails.

On the other hand, rustup toolchain install with no arguments does the right thing.

Steps

1. Update rustup to 1.28.
2. Check out, say, https://github.com/cbiffle/soundlaser-rs
3. Make sure you don't have 1.85.0 installed.
4. Run cargo build.
5. Now, run the exact command from the error that displays.
6. Now, try cargo build again.

Possible Solution(s)

In the event that the command is failing in a directory with a (valid) rust-toolchain.toml, perhaps the error message should suggest the no-argument version of rustup toolchain install.

Notes

No response

Rustup version

rustup 1.28.0 (6e19fbec7 2025-03-02)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.85.0 (4d91de4e4 2025-02-17)`

Installed toolchains

Many.

OS version

Linux gwydion 6.9.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 26 May 2024 01:30:29 +0000 x86_64 GNU/Linux

[rami3l]

@cbiffle Thanks for filing this issue! Actually this point has been considered in my original implementation and should have been shipped as a part of v1.28.0, however it will sometimes trigger infinite recursion so I pulled it back. I'll definitely give it another look.