When VS 2015 was first released, its new v140 toolset came with a
`link.xml` file that changed the `GenerateDebugInformation` boolean
(`false` and `true`) value from earlier toolsets to an enumeration
consisting of the possible values `No`, `Debug`, and `DebugFastLink`.

We first adapted to this in commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj
file value for GenerateDebugInformation, 2016-01-08), but that broke
older toolsets that still expected the boolean.  Then commit
v3.6.0-rc1~295^2~1 (VS: Fix VS 2015 .vcxproj debug setting for older
toolsets, 2016-02-24) added a hack to fix up the value based on the
toolset in use.  Several follow-up commits fixed this for more older
toolsets because our flag table was at the time based on the generator
in use rather than the toolset in use.

Since commit v3.8.0-rc1~396^2 (VS: Choose flag map based on the toolset
name, 2016-10-17) we use a flag table based on the toolset, so the fixup
hack should not be needed.  We had to keep it around only due to our
default value for GenerateDebugInformation (`false` or `No`) still being
based on the generator instead of the toolset.

A VS 2015 update was released that changed the v140 toolset `link.xml`
file back to using `false` and `true` for the `GenerateDebugInformation`
enumeration variants previously known as `No` and `Debug`.  In order to
know which pair to use, we need to parse the `link.xml` file for the
current toolset.

Switch back to using `false` and `true` unconditionally in our
`GenerateDebugInformation` flag table entries and default value.  With
that plus the toolset-based flag table, we now get incorrect values for
`GenerateDebugInformation` only when using a v140 toolset from an older
VS 2015 installation.  Detect this case by parsing `link.xml` and add
special logic to convert `false` and `true` to `No` and `Debug` to
satisfy the older toolset specification.

Inspired-by: Ian Hojnicki <nullref@live.com>
Fixes: #17020

Ian Hojnicki authored 7 years ago and Brad King committed 7 years ago

Update the help text to match that from v141's link.xml file.

Since commit v3.9.0-rc1~55^2 (Improve Doxygen support, 2017-04-10) we
accidentally leave a non-prefixed internal `result` variable set.
This may interfere with project code.  Add a prefix to avoid this.

The change in commit v3.9.0-rc4~3^2 (VS: Improve workaround for CUDA
-Xcompiler placement bug, 2017-06-21) accidentally appended to the
`AdditionalOptions` as if it were a `;`-separated list, but it is
actually a command-line string.  Append with a space instead.

While at it, fix the same problem for the `AdditionalOptions` added to
`CudaLink` by commit v3.9.0-rc3~1^2 (CUDA: When linking device code
suppress CUDA 8.0+ deprecation warnings, 2017-06-09).

Fixes: #17008

Fixes: #17011

Enable C or CXX (or nothing) as needed in each test case.
This will allow us to add test cases that do not enable CXX.

Issue: #17007

Since commit v3.9.0-rc1~160^2 (VS: Use tool-specific flag table for
COMPILE_FLAGS parsing, 2017-05-03) we now correctly use the `rc` flag
table to process the COMPILE_FLAGS flags of `.rc` source files instead
of incorrectly using the `cl` flag table as before.  However, our `rc`
flag table is not complete.  The `/nologo` flag was working before only
by accident because the `cl` flag table entry for it happened to match.
Add the proper entry to the `rc` flag table.

Fixes: #16991

In commit v3.9.0-rc3~3^2 (Android: Add support for unified headers,
2017-06-12) we accidentally constructed the unified header include
directories from the linking sysroot.  Construct them from the
compiling sysroot instead.

Fixes: #16584

In commit v3.9.0-rc1~431^2~6 (VS: Place CUDA host compiler options in
proper project file fields, 2017-03-07) we worked around a bug in the
CUDA VS integration by dropping `AdditionalCompilerOptions`.  However,
this silently drops `-Xcompiler=` options given by the user that don't
map to one of CudaCompile's dedicated settings.  Improve the workaround
to instead put the remaining `AdditionalCompilerOptions` into the
`AdditionalOptions` field behind `-Xcompiler=` ourselves.

Fix the VS generator to honor `COMPILE_OPTIONS` for CUDA.  The exclusion
added by commit v3.9.0-rc1~431^2~7 (VS: Do not pass CUDA compile options
to C compiler, 2017-03-07) was correct but we need additional logic to
pass the CUDA compile options to the CUDA compiler.  Also we should
still pass the CXX or C options to MSVC (ClCompile) when those languages
are enabled even if the link language is CUDA.

Fixes: #16755

CUDA 8.0.44 contains a bug in its VS integration that breaks
preprocessor definitions in some cases.  Recommend using at least 8.0.61
which fixes the problem.

Fixes: #16993

* upstream-expat:
  expat 2017-06-17 (c4446687)

Kitware Robot authored 7 years ago and Brad King committed 7 years ago

Code extracted from:

    https://github.com/libexpat/libexpat.git

at commit c4446687cfc6c5fd7f6371aeaf24c69402a3589e (R_2_2_1).

They were recorded by commit v3.7.0-rc1~156^2~2 (Features: Record
features for VS 15 Preview 4, 2016-09-05).

Fixes: #16974

Reported-by: Rolf Eike Beer <eike@sf-mail.de>

On Windows, libuv's one-time initialization changes the C runtime
library's  `_fmode` setting to `_O_BINARY`, thus causing files to open
as binary after that instead of the default `_O_TEXT` mode.  See
upstream libuv issue 840.  Work around the problem by performing libuv
initialization early and then restoring `_fmode`.

In particular, this currently affects server mode.  Without this fix,
the `_fmode` setting changes when the server mode initializes libuv.

Fixes: #16962