Reconsider the "toolchain options are ignored for a custom toolchain" error #4248
Comments
|
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. |
This validation was introduced in e1306b3 However, it breaks a number of scenarios that previously worked without issue such as rust-lang#4248. As requested by rustup maintainers in that thread, I'm taking out the extra validation added in that commit, leaving the rest of the code as-is. I was not able to figure out a way to write an automated test for this scenario since the rustup CLI needs the custom toolchain to actually exist and unit testing looked infeasible due to use of the `Cfg` type. Manual testing confirms this fixes rust-lang#4248.
|
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 🙂 |
This validation was introduced in e1306b3 However, it breaks a number of scenarios that previously worked without issue such as rust-lang#4248. As requested by rustup maintainers in that thread, I'm taking out the extra validation added in that commit, leaving the rest of the code as-is. I was not able to figure out a way to write an automated test for this scenario since the rustup CLI needs the custom toolchain to actually exist and unit testing looked infeasible due to use of the `Cfg` type. Manual testing confirms this fixes rust-lang#4248.
So do I understand correctly that you have tooling that uses |
This validation was introduced in e1306b3 However, it breaks a number of scenarios that previously worked without issue such as rust-lang#4248. As requested by rustup maintainers in that thread, I'm taking out the extra validation added in that commit, leaving the rest of the code as-is. Testing confirms this fixes rust-lang#4248.
This validation was introduced in e1306b3 However, it breaks a number of scenarios that previously worked without issue such as rust-lang#4248. As requested by rustup maintainers in that thread, I'm taking out the extra validation added in that commit, leaving the rest of the code as-is. Testing confirms this fixes rust-lang#4248.
This validation was introduced in e1306b3 However, it breaks a number of scenarios that previously worked without issue such as rust-lang#4248. As requested by rustup maintainers in that thread, I'm taking out the extra validation added in that commit, leaving the rest of the code as-is. Testing confirms this fixes rust-lang#4248.
This validation was introduced in e1306b3 However, it breaks a number of scenarios that previously worked without issue such as rust-lang#4248. As requested by rustup maintainers in that thread, I'm taking out the extra validation added in that commit, leaving the rest of the code as-is. Testing confirms this fixes rust-lang#4248.
This validation was introduced in e1306b3 However, it breaks a number of scenarios that previously worked without issue such as #4248. As requested by rustup maintainers in that thread, I'm taking out the extra validation added in that commit, leaving the rest of the code as-is. Testing confirms this fixes #4248.
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.
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 |
|
Is it possible for this fix to be included in the upcoming |
@wesleywiser Yes, it definitely will. |
|
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 🏅 |
Btw, you might want to look at the history of #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. |
Problem you are trying to solve
The rustup 1.28 release introduced new validation for custom toolchains listed in
rust-toolchain.tomlfiles. 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 haverust-toolchain.tomlfiles that look like: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: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:
~/.rustup/settings.tomlor an environment variable).Thanks for your consideration and efforts to improve rustup!
Notes
No response
The text was updated successfully, but these errors were encountered: