Should `settings.toml` allow unqualified toolchain names?

[rami3l]

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 the current approach:

• 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.

This way:

• In the first point, after changing default_host_tuple, the default toolchain will be resolved in the new host triple.
• In the second point, you will be able to use stable in your dotfiles as default_toolchain without problems.

Update: The same logic also applies to rustup override set, as discovered in #5044.

[hiSandog]

How should unresolved aliases interact with offline operation and toolchain removal? If stable is resolved on every invocation, changing default_host_tuple could make an existing installation appear to have no default until the new host toolchain is installed. It may help to specify whether resolution is purely dynamic or whether rustup should retain the last resolved toolchain as a fallback.

[rami3l]

If stable is resolved on every invocation, changing default_host_tuple could make an existing installation appear to have no default until the new host toolchain is installed.

@hiSandog I proposed exactly that with this proposal, quote:

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.

The rationale here is that changing default_host_tuple is a very rare use case, and when you do want to change it, you must have pretty good reasons of doing so already. The current behavior causes the following inconsistency:

> rustup default stable
> rustup set default-host <new-default-host>

> rustup show active-toolchain
# This shows stable-<old-default-host>

> rustup +stable show active-toolchain
# This shows stable-<new-default-host>

How should unresolved aliases interact with offline operation and toolchain removal?

May I ask what you think would be the issue here? IMHO you can always use the qualified names and thus unqualified names are only a shorthand, plus there is nothing stopping rustup from suggesting a possible qualified name when stable has changed the pointee but you want to refer to the old stable.

[djc]

Is there a noticeable performance impact in proxy invocations that need to resolve the unresolved name?

[rami3l]

Is there a noticeable performance impact in proxy invocations that need to resolve the unresolved name?

@djc Nice question! I just ran the test and the results show that the overhead should be minimal in a comparison of the two cases below:

• before (revert of 6b11c03): stores default_toolchain = "stable-x86_64-unknown-linux-gnu" (fully resolved) in settings.toml
• after (6b11c03): stores default_toolchain = "stable" (unresolved alias) in settings.toml

Using hyperfine --warmup 20 --min-runs 500, this gives:

Benchmark 1: after (unresolved "stable")
  Time (mean ± σ):      12.6 ms ±   0.6 ms    [User: 4.0 ms, System: 8.5 ms]
  Range (min … max):    11.6 ms …  16.3 ms    500 runs
 
Benchmark 2: before (resolved "stable-x86_64-unknown-linux-gnu")
  Time (mean ± σ):      12.8 ms ±   0.8 ms    [User: 4.0 ms, System: 8.7 ms]
  Range (min … max):    11.7 ms …  17.4 ms    500 runs
 
Summary
  after (unresolved "stable") ran
    1.01 ± 0.08 times faster than before (resolved "stable-x86_64-unknown-linux-gnu")

... of course I won't say that the new version is really faster, probably it's just some statistical noise.

Looking at the code this behavior is also expected: the default host tuple is resolved once in Cfg::get_default() so this should cause the exact same amount of IO.