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?

[wesleywiser]

So do I understand correctly that you have tooling that uses toolchain.targets key for something?

Yes, we use it for the same purpose that rustup does: listing the targets needed by the project which should be installed by our tooling.

Is part of your plan to shift that away to using a more custom key?

We've discussed that but given that the meaning is the same, we'd like to keep symmetry with rustup. We're currently exploring ways to make it so that rustup (and the cargo, rustc, etc redirectors) don't need to be run inside projects that use our internal build.

[wesleywiser]

Is it possible for this fix to be included in the upcoming .2 release? I'm not familiar with your release process so just asking in case it needs another decision or backport 🙂

[rami3l]

Is it possible for this fix to be included in the upcoming .2 release? I'm not familiar with your release process so just asking in case it needs another decision or backport 🙂

@wesleywiser Yes, it definitely will.

[wesleywiser]

Awesome, thank you (and @djc as well) so much for the really fast responses and iterations on this issue! I can tell you that it's greatly appreciated by many people in Microsoft 🏅

[ChrisDenton]

We're currently exploring ways to make it so that rustup (and the cargo, rustc, etc redirectors) don't need to be run inside projects that use our internal build.

Btw, you might want to look at the history of https://github.com/rust-lang/rustup/issues/3035 in case it's relevant; apparently there's a fair amount of stuff that expects the proxies. Though that may be less of an issue for your specific builds.

[jobafr]

I upgraded my rust compiler this week (rustup update) and now I get this error message whenever I try to compile a project for ESP microcontrollers. Rust-analyzer in vscodium is also broken now.

The project has this rust-toolchain.toml file in it:

[toolchain]
channel = "esp"
components = ["rustfmt", "rustc-dev"]
targets = ["xtensa-esp32-none-elf"]

I don't know how to fix this.

[rami3l]

@jobafr Would you mind trying out one of our recent CI builds, such as this one (artifacts at the very bottom, requires GitHub login to download)?

[rbtcollins]

So do I understand correctly that you have tooling that uses toolchain.targets key for something?

Yes, we use it for the same purpose that rustup does: listing the targets needed by the project which should be installed by our tooling.

Is part of your plan to shift that away to using a more custom key?

We've discussed that but given that the meaning is the same, we'd like to keep symmetry with rustup. We're currently exploring ways to make it so that rustup (and the cargo, rustc, etc redirectors) don't need to be run inside projects that use our internal build.

The challenge is that now people will be confused when those options do not take effect for custom toolchains. Sure they do at MS specifically, but in the general case, rustup cannot implement its contract there.

I would love it if MS could migrate to a different key, and rustup could then signal clearly when something useless (for rustup) is present.

[jobafr]

@jobafr Would you mind trying out one of our recent CI builds, such as this one (artifacts at the very bottom, requires GitHub login to download)?

@rami3l Yes, that one does not have the error. I also tried downgrading to rustup 1.25.2 (built from source) before I saw your reply, this also restores the previous behavior.