error: toolchain 'stable-x86_64-pc-windows-msvc' is not installable with rustup 1.27.0 on wine

[llde]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

trying a fresh install of rustup and downloading the default stable seems to suceeed, but then error with:
error: toolchain 'stable-x86_64-pc-windows-msvc' is not installable

after the verbose message that follow tmp directory deletions:
verbose: toolchain 'stable-x86_64-pc-windows-msvc' installed

VS2019 and the C++ build tools are isntalled on this prefix.
Using latest Wine from git

While this seems to be a specific wine deficiency (similar to the issue removing tmp directories in the 1.26.0. version), I'd like to know what rustup flow is and what cause the error.
If it's the case that this failing step is working correctyl but expect something that a previous step failed to produce, maybe a warning/error on the previous step may be worth to add

Steps

Correct prefix setted in the WINE_PREFIX envvar

1. Have a prefix with C++ build tools installed and no .crago and .rustup folders in the user directory
2. wine rustup-init.exe
3. Install the default toolchain

Possible Solution(s)

No response

Notes

No response

Rustup version

1.27.0

Installed toolchains

None

OS version

ArchLinux x64, Wine/Wine Staging 9.8

[llde]

Isse seems that the line
default_toolchain = "stable-x86_64-pc-windows-msvc"

isn't written in the settings.toml

[rami3l]

@llde I'm trying to revamp the logging system in #3803. I do hope this will make things easier for you in the near future :]

[llde]

BTW I investigated the bug and discovered is related to an issue in the wine-staging ntdll-Junction_Points patchset that implement REPARSE POINTS

Bug and a patch to make rustup 1.27.0 (and that also fix an issue with the previous 1.26.0) were made here https://bugs.winehq.org/show_bug.cgi?id=56647

Still, better detection of where an error occurs is welcome

[rami3l]

@llde Wow that's impressive! Thanks a lot for the investigation!

Anyway, I'm closing this issue as upstreamed now.