Split from #4944 (comment).
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.
I can see two downsides of doing so:
- If the user changes
default_host_tuple after setting default_toolchain to a generic name such as stable, the default toolchain would still be in the original host triple since it has been resolved beforehand.
- 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.
Maybe rustup can start storing the unresolved name (or if it is breaking too many things, under a new subcommand/option) for default_toolchain instead? The idea is that one can always store the fully qualified toolchain name to go back to the old behavior.
Split from #4944 (comment).
For now,
rustup default <toolchain>resolves the full toolchain name from<toolchain>, which could be a function ofdefault_host_tuple, and then stores that insettings.toml.I can see two downsides of doing so:
default_host_tupleafter settingdefault_toolchainto a generic name such asstable, the default toolchain would still be in the original host triple since it has been resolved beforehand.stabletoolchain specific to the default host tuple of that platform.Maybe rustup can start storing the unresolved name (or if it is breaking too many things, under a new subcommand/option) for
default_toolchaininstead? The idea is that one can always store the fully qualified toolchain name to go back to the old behavior.