'--default-toolchain none' later forces i686 download+install on Windows

[faern]

Problem
When installing rustup with --default-toolchain none and later install a toolchain I get i686-pc-windows-msvc even if I specify --default-host x86_64-pc-windows-msvc when installing rustup and --target x86_64-pc-windows-msvc when installing the toolchain.

The problem does not exist if I specify --default-toolchain stable directly to the rustup install. But I want the backtracking feature of -c rustfmt for nightly to be able to get the latest nightly with a working rustfmt, so I guess that's not an option.

Steps

$ ./rustup-init.exe -y --default-toolchain none --profile minimal --default-host x86_64-pc-windows-msvc
info: profile set to 'minimal'
info: skipping toolchain installation

$ rustup toolchain install stable --no-self-update -c rustfmt --target x86_64-pc-windows-msvc
info: syncing channel updates for 'stable-i686-pc-windows-msvc'   <--- ???
info: latest update on 2019-09-26, rust version 1.38.0 (625451e37 2019-09-23)
info: downloading component 'cargo'
info: downloading component 'rust-std'   <--- ???
info: downloading component 'rust-std' for 'x86_64-pc-windows-msvc'
info: downloading component 'rustc'
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: installing component 'rust-std'    <--- ???
info: installing component 'rust-std' for 'x86_64-pc-windows-msvc'
info: installing component 'rustc'
info: installing component 'rustfmt'

As you can see above it installs the toolchain for both i686 and x86_64. This takes more time than it should (matters on a CI where it's done repeatedly) and it also comes with the problem of i686 being the default. So I need to add --target x86_64-pc-windows-msvc to all cargo build/cargo test invocations that comes later in the CI script as well.

Notes

Output of rustup --version: rustup 1.20.2

[kinnison]

Wow, that is fascinating. Definitely something broken there.

If you run rustup show is the default host definitely set to x86_64 ?

It's definitely downloading the wrong toolchain if it is. And that'd explain things a bit more.

The more info you can give me, the better chance I'll have of reproducing and thence fixing this, so.

1. Which rustup-init.exe did you end up with? i686 or x86_64 ?
2. After the installation of rustup what does rustup show give you?
3. if you specify rustup toolchain install stable-x86_64-pc-windows-gnu does it seem to do the right thing?
4. You're giving me the example with stable but you say you want nightly backtracking -- does nightly behave properly?

[faern]

Sorry for not including the output of rustup show the first time. I ran this on a different computer from where I had github access. Yes, rustup-init.exe sets the wrong default host indeed:

$ ./rustup-init.exe -y --default-host x86_64-pc-windows-msvc --default-toolchain none --profile minimal
<Output removed>

$ rustup show
Default host: i686-pc-windows-msvc
rustup home:  C:\Users\<username>\.rustup

no active toolchain

1. Hmm. The one I got from curl -sSf -o rustup-init.exe https://win.rustup.rs/. But yeah, seems to be a 32 bit binary now when I look into it. When downloading with a browser I get the 64 bit version and the default host is x86_64-pc-windows-msvc after install. However, it's still not listening to the arguments. --default-host i686-pc-windows-msvc also installs rustup with default host x86_64-pc-windows-msvc when using the 64 bit rustup-init.exe. So in all cases the default host becomes whatever the rustup-init.exe binary is built for it seems. Is there any URL I can use that does not auto-detect my platform, but where I can decide? Such as https://win.rustup.rs/x86_64 or something?
2. Pasted above.
3. YES! With a default host of i686 the command rustup toolchain install stable-x86_64-pc-windows-gnu seems to correctly download for x86_64 and not both toolchains either. At least that's my early results.
4. No. Everything behaves the same. The default host is wrong before I even get to rustup toolchain install as outlined above.

The main problem seems to be that rustup-init.exe does not honor --default-host.

[kinnison]

Okay, I'll now be able to take a look and work out what's going on with rustup-init.exe thank you for diagnosing that.

[kinnison]

rustup-init.exe won't override an existing installation's default toolchain on installation. To change that now would be quite a breaking change, but I will introduce a warning to that effect. If you install from scratch with a toolchain set then rustup sets the host, but it is skipping it on none case. I'll add support to set it on that pathway too.

[kinnison]

Actually thinking about it there're three cases here -- none and fresh install with a toolchain which both set the host (with my change), so perhaps I ought to make it so that not fresh install also updates the default host. Yeah, it's that big a breaking change on second thoughts, and really people could be reasonably expected for it to behave that way.