feat(config)!: use unqualified names for default_toolchain

[rami3l]

Stacked on #4950 and #4991, closes #4945.

Problem Description

The original problem as seen in both #3651 and #4945 is the following:

For now, rustup default <toolchain> resolves the full toolchain name from <toolchain>, which could be a function of default_host_tuple, and then stores that in settings.toml.
#4945

... this is notably problematic because the value of default_toolchain is inappropriately coupled with the value of the default host at the wrong moment: not the moment of running any rustup command, but the last execution of rustup default (whether manually by running that very command, or implicitly upon rustup-init):

This has made the config file hostile to cross-platform dotfile management, since one may want to use the stable toolchain specific to the default host tuple of that platform.
#4945 (comment)

i have a stable-x86_64-pc-windows-gnu toolchain as my default [..] i want it to be -msvc instead so i can use windbg (i don't have gdb installed). i ran rustup set default-host x86_64-pc-windows-msvc, which succeeded, but did not install any toolchains or change the default:
#3651 (comment)

Proposed Solution

This PR makes rustup use unqualified names such as stable instead of fully qualified names such as stable-aarch64-apple-darwin for the default_toolchain field in the settings.toml file.

Impact

Compatibility

This change is breaking exactly because the determination of the default toolchain will change to reflect the change of the default host tuple.

However, the user can always get the old behavior by specifying the fully qualified name when running rustup default (such as rustup default stable-aarch64-apple-darwin), in the rare case that they would like to decouple the default toolchain from the default host tuple.

For users with an existing settings.toml, manually running rustup default stable or similar commands should be necessary for them to get the new behavior.

Performance

As discussed in #4945 (comment), since the default host tuple is resolved at the beginning of rustup's execution, this change has introduced no extra I/O operations, and thus the performance impact is negligible.

Validation

Validated through both local testing, a specific test case that reflects @jyn514's original use case as described in #3651, as well as another specific test case that explicitly asserts backwards compatibility with existing settings.toml format with a fully qualified default_toolchain name.

[rami3l]

@djc Would you mind giving this PR another look please? 🙇

[djc]

Stacked on #4950 and #4991, closes #4945.

The breakage should be minimal anyway because the default host tuple almost never changes.

I think the PR description should explain (a) what you're trying to achieve here and (b) how you're trying to achieve it, and probably (c) the effects on backwards compatibility, instead of just relying on issue/PR references.

[rami3l]

I think the PR description should explain (a) what you're trying to achieve here and (b) how you're trying to achieve it, and probably (c) the effects on backwards compatibility, instead of just relying on issue/PR references.

@djc Thank you so much for this suggestion! I have completely rewritten the PR description to include the 3 points mentioned above. Please don't hesitate to tell me if you happen to have any more concerns, as I will try my best to address them.

[djc]

This change is breaking exactly because the determination of the default toolchain will change to reflect the change of the default host tuple.

However, the user can always get the old behavior by specifying the fully qualified name when running rustup default (such as rustup default stable-aarch64-apple-darwin), in the rare case that they would like to decouple the default toolchain from the default host tuple.

For users with an existing settings.toml, manually running rustup default stable or similar commands should be necessary for them to get the new behavior.

In the code, it was not clear to me how/where old configurations with fully qualified names where still kept supported. I think it would be good to add some comments that make it obvious where/how that happens and that it must not regress.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rami3l]

In the code, it was not clear to me how/where old configurations with fully qualified names where still kept supported. I think it would be good to add some comments that make it obvious where/how that happens and that it must not regress.

@djc Sure! I have just added one regression test specifically for the case you've mentioned, asserting that settings.toml can contain a fully qualified toolchain name which can be generated by rustup default followed by that name, both before and after this breaking change.

In addition, I've added two more assertions against the exact shape of settings.toml in the originally introduced test case.