This commit adds the Armv8-M targets recently added into Rust:
* Armv8-M Baseline ("thumbv8m.base-none-eabi")
* Armv8-M Mainline ("thumbv8m.main-none-eabi")
* Armv8-M Mainline with FPU extension ("thumbv8m.main-none-eabihf")
The FPU chosen for the hardfloat variant of Armv8-M Mainline is the one
available in the Cortex-M33 processor: single precision, FPv5
architecture.
It is described in the Arm Cortex-M33 Processor Technical Reference
Manual on the page 64.
If CFLAGS/CXXFLAGS is defined in the environment, then presumably the consumer has already determined the set of warnings flags to pass to the compiler, so we shouldn't enable warnings by default in that case.
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).