Should probably return a dedicated "uh oh, that Visual Studio
installation is broken" error rather than just None, but for now, it
matches the behavior of the compiler find functions.
After I recently uninstalled some older MSVC versions using Visual Studio
Uninstaller (https://github.com/Microsoft/VisualStudioUninstaller),
HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7\15.0 also was
deleted in the process, even though Visual Studio 2017 *itself* wasn't,
and still worked fine.
Steps to reproduce:
1. Install Visual Studio 2017 Community with the *Desktop development
with C++* workload on a fresh Windows system. (I tested with version
15.7.6.)
2. Confirm that the registry key points to the installation directory.
3. Run the Visual Studio Uninstaller on that same system.
4. The registry key is now gone, but Visual Studio 2017 IDE still works
and can compile code.
5. The following Rust code then runs without panicking:
```rust
extern crate cc;
use cc::windows_registry::find_tool;
fn main() {
// Change this if your test system is 32-bit
let target = "x86_64-pc-windows-msvc";
assert_eq!(find_tool(target, "devenv.exe").is_none(), true);
assert_eq!(find_tool(target, "link.exe").is_some(), true);
// msbuild.exe will fall back on find_old_msbuild(), which will
// find a ersion under a different registry key.
}
```
Which means that `link.exe` can still be found just fine through
SetupConfiguration. This may be a bug in Visual Studio Uninstaller, but
it also matches what Microsoft says about the reliability of these
registry keys, and that SetupConfiguration should be preferred. (See
https://developercommunity.visualstudio.com/comments/215399/view.html).
This teaches gcc-rs to find tools installed by MSVC 2017. It's not
obvious to what extent the new COM interfaces are expected to be
used. This patch only uses it to find the product installation
directory, then infers everything else. A lot of COM scaffolding to do
very little. The toolchains seem to have a different directory
structure in this release to better support cross-compilation.
It looks to me like all the lib/include logic is pretty much the same
as it always has been.
This is tested to fix the rustup installation logic, and to fix
rustc in basic use cases on x86_64.
cc alexcrichton/gcc-rs#143
cc rust-lang-nursery/rustup.rs#1003
cc rust-lang/rust#38584
cc alexcrichton/curl-rust#161
Visual Studio 2015, recently releases, includes the Universal CRT, a different
flavor than was provided before. The binaries and header files for this library
are included in new locations not previously known about by gcc-rs, and this
commit adds support for the necessary probing to find these (for now).