Reconsider the "toolchain options are ignored for a custom toolchain" error

[wesleywiser]

Problem you are trying to solve

The rustup 1.28 release introduced new validation for custom toolchains listed in rust-toolchain.toml files. At Microsoft, we use an internal build of the Rust compiler that is distributed as a custom toolchain (not managed by rustup but linked to from ~/.rustup/toolchains) so it's common for our developers to have rust-toolchain.toml files that look like:

[toolchain]
channel = "ms-1.84.1"
targets = [
    "aarch64-pc-windows-msvc",
    "x86_64-pc-windows-msvc",
]

We have tooling that handles installing the Rust build and appropriate targets. For our developers, this is nice as it aligns very closely to working with the standard Rust toolchain build, which we want to support as much as possible.

With the update to rustup 1.28 however, any invocation of rustc, cargo, etc is met with:

> cargo --version
error: toolchain options are ignored for a custom toolchain (ms-1.84.1)

even when the appropriate custom toolchain is already configured and ready to be used.

Solution you'd like

Ideally, it would be great if this error could only be shown in the case where required components or targets are missing from the custom toolchain!

I understand that is probably difficult to determine ahead of time so some other solutions might be:

1. Revert the additional validation for custom toolchain options.
   • If this is acceptable, I would be happy to prepare a PR with this change.
2. Allow the user to ignore this error entirely somehow (preferably via a configuration flag in ~/.rustup/settings.toml or an environment variable).
3. Downgrade the error to a warning or informational message.
   • This is not highly preferred because it will still appear frequently to our developers while not being useful/actionable.

Thanks for your consideration and efforts to improve rustup!

Notes

No response

[djc]

Thanks for the feedback, and sorry for the hiccups we caused for using Rust at MS!

Solution 1 sounds like a reasonable option to me from this list, would be good to review a PR in that direction.

[wesleywiser]

Thanks so much for the quick response @djc! Occasional hiccups are expected and we're taking this opportunity to improve reliability on our side as well 🙂

[djc]

Thanks so much for the quick response @djc! Occasional hiccups are expected and we're taking this opportunity to improve reliability on our side as well 🙂

So do I understand correctly that you have tooling that uses toolchain.targets key for something? Is part of your plan to shift that away to using a more custom key?