Support finding Visual Studio instances using vswhere.exe

[Alovchin91]

This PR adds another option in attempting to find an installed Visual Studio version by using vswhere.exe.

vswhere.exe has a known location (%ProgramFiles(x86)%\Microsoft Visual Studio\Installer) and is a 32-bit application which means it can be used on Windows ARM64 to locate Visual Studio (see rust-lang/rust#83043).

vswhere.exe is used as a last resort to find VS2015+ if everything else has failed. vswhere.exe itself is launched with parameters to search for only the latest available version that has component Microsoft.VisualStudio.Component.VC.Tools.<ARCH> installed.

[alexcrichton]

Thanks! This seems reasonable enough to me to go ahead and land. AFAIK this is one of the last remaining blocks running rustc on aarch64 Windows itself, right?

It looks like CI says the msrv needs bumping, but that's fine to do, you'll just need to edit the CI configuration

[Alovchin91]

Sorry for the late reply, I missed the notification 😬

I've changed the usage of Self to the explicit type name. This way I guess it should compile on older Rust versions, and it's also consistent with what I've used in into_iter for VsInstances 🙂

This is not really a block for running rustc on Windows ARM64, since one can always run it inside the Developer Command Prompt that has all the environment variables properly setup, but it improves some of the aspects drastically. Also, there are some crates that might not work properly without this change. As an example - rust-analyzer cannot find MSVC and thus needs some special configuration to run properly.

[Alovchin91]

Hmm, rustup (Install Rust stage) failed with memory allocation of 16777216 bytes failed 🤔 Should I try upgrading MSRV after all?

[alexcrichton]

I think it may be related to a recent rustup bug? Mind adding a rustup self update to CI to precede this until Github Actions picks up the new version by default?

[Alovchin91]

Let's see if that helps :)

[Alovchin91]

OMG. Another try? 🙃

[alexcrichton]

Thanks again!

[Alovchin91]

Thank you! 🙂

[thadguidry]

@alexcrichton How do I know if this is in the latest crate that rustup-init.exe pulls down? I'd like to test for my custom Visual Studio 2019 Community installation on E:\ drive for Windows 10 64bit.

@Alovchin91 We may eventually need to do this to actually find the path where vswhere.exe itself lives before we try to begin using it to ask for VS path locations (MS might soon allow installing Shared components, tools, SDKs into custom locations, there's an issue on their side for that enhancement):

1. Read KEY
   Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\Setup
2. Read Data using Name
   Name=SharedInstallationPath
3. This tells us the Shared Path C:\Program Files (x86)\Microsoft Visual Studio\Installer\Shared
4. Look 1 level up by removing the ending \Shared and then look in path
5. This path will have vswhere.exe inside such as
   C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe
6. Run vswhere.exe
7. Use output and parse installationPath to get custom location

Screenshot of custom Install locations:

[ChrisDenton]

According to the vswhere wiki:

Starting with Visual Studio 15.2 (26418.1 Preview) vswhere.exe is installed in %ProgramFiles(x86)%\Microsoft Visual Studio\Installer (use %ProgramFiles% in a 32-bit program prior to Windows 10). This is a fixed location that will be maintained.

So apparently this location is guaranteed for vswhere even if other components are installed elsewhere.

[Alovchin91]

That's the current thinking indeed. I intentionally KISSed and did not introduce unnecessary complexity since Microsoft promises to maintain the said path in the foreseeable future. If it ever changes, we might indeed want to reconsider. But for now vswhere.exe is the last resort and to be honest, I really hope that Microsoft fixes the COM component on ARM64. At least it's my impression from talking to them on Twitter that they could fix it (though I guess nobody knows when that would happen 🙈).

[alexcrichton]

This was published in 1.0.68, so if your Cargo.lock contains 1.0.68 then it's using this.