This patch is generated by a python script that uses regular expressions to
search for string concatenation patterns of the kind
```
std::string str = <ARG0>;
str += <ARG1>;
str += <ARG2>;
...
```
and replaces them with a single `cmStrCat` call
```
std::string str = cmStrCat(<ARG0>, <ARG1>, <ARG2>, ...);
```
If any `<ARGX>` is itself a concatenated string of the kind
```
a + b + c + ...;
```
then `<ARGX>` is split into multiple arguments for the `cmStrCat` call.
If there's a sequence of literals in the `<ARGX>`, then all literals in the
sequence are concatenated and merged into a single literal argument for
the `cmStrCat` call.
Single character strings are converted to single char arguments for
the `cmStrCat` call.
`std::to_string(...)` wrappings are removed from `cmStrCat` arguments,
because it supports numeric types as well as string types.
`arg.substr(x)` arguments to `cmStrCat` are replaced with
`cm::string_view(arg).substr(x)`
This replaces invocations of
- `cmSystemTools::IsInternallyOn` with `cmIsInternallyOn`
- `cmSystemTools::IsNOTFOUND` with `cmIsNOTFOUND`
- `cmSystemTools::IsOn` with `cmIsOn`
- `cmSystemTools::IsOff` with `cmIsOff`
The mapping for this flag was added by commit 43aa632f57 (VS: Populate
`-Qspectre-` flag table entry for v142, 2019-01-24, v3.14.0-rc1~74^2~7).
However, it did not do anything because the special logic added by
commit bb60ed6e72 (VS: Add flag table entry for -Qspectre, 2018-10-08,
v3.13.0-rc1~4^2) to move the `SpectreMitigation` element from
`ClCompile` to the top level only handled the presence of the setting
and not its value. Extend the special logic to carry the value too.
Fixes: #19535
The `AssemblerListingLocation` setting in VS project files is meant for
intermediate files created during the build much like object files.
When the VS 7 generator was first under development, commit 49aebe6c99
(new arch, 2002-09-04) placed both object files and the ASM list
location in the same directory. Later commit f9aef0e422 (Generator now
creates a separate intermediate files directory for each target,
2005-07-27) moved the object files to a per-target directory but the
ASM list location was not moved with them. Move it now.
Fixes: #19480
In commit 3a53005f7d (Build object library targets in VS, 2012-03-12,
v2.8.8~29^2~13) we updated the condition for unicode but accidentally
left out the SBCS case support for object libraries.
Fixes: #19469
An old workaround for `std::allocator_traits<>::value_type` lints from
IWYU on `std::vector<>` usage breaks IWYU's handling of `<memory>`.
Convert the workaround to use the same approach we already use for a
workaround of `std::__decay_and_strip<>::::__type` lints. Then update
the `<memory>` inclusions to follow the now-correct IWYU lints.
Checks added in commit 81b4d10d8f (CUDA: More exhaustive checks to
determine when to do device linking, 2019-05-09, v3.15.0-rc1~82^2)
assumed that CUDA properties would be set only if CUDA is enabled.
We cannot do a device link step if we do not have the CUDA language
enabled. This was discovered as some projects unconditionally set CUDA
properties such as `CUDA_RESOLVE_DEVICE_SYMBOLS` even when the CUDA
language has not been enabled.
Fixes: #19432
Apply the refactoring from commit 707283981f (VS: Use AddLanguageFlags
to de-duplicate CMAKE_<LANG>_FLAGS* lookup, 2019-04-01,
v3.15.0-rc1~300^2) to the CUDA, ASM_MASM, and ASM_NASM languages too.
In particular, CUDA needs the MSVC runtime library selection logic
in the `AddLanguageFlags` method that is used by other generators.
Avoid listing the same input more than once in custom commands generated
in `.vcxproj` and `.csproj` files. In the case of a `.vcxproj` file
additionally avoid listing the source to which the command is attached
since it is already implicitly a dependency.
This is a nice cleanup and also works around a VS 2019 16.1 regression
in MSBuild dependency checking. Starting with that version, MSBuild now
re-builds custom commands when the list of dependencies has changed.
However, its check is confused by duplicate dependencies.
De-duplicating them avoids this problem.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #19303
81b4d10d8f CUDA: More exhaustive checks to determine when to do device linking
3205c7c950 cmNinjaLinkLineDeviceComputer now lives in the correct source file
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3320
Previously CMake used fairly naive logic to determine when to do
device linking which caused unnecessary device linking to occur
frequently. We now use a more exhaustive algorithm to determine
when we have a need for device linking.
Fixes: #19238
Encode `\n` as ` ` to avoid generating a literal newline inside an
XML attribute. This is more readable and also fixes custom commands in
`.csproj` files with VS 2019 RC.
Fixes: #19001
Rather than taking a number of out parameters for the various names,
create a structure that is reused for both `GetLibraryNames` and
`GetExecutableNames`. Replace uses according to the new interface.
`CUDA_RESOLVE_DEVICE_SYMBOLS` can be used with shared, module, and
executable target types. This relaxation is to allow for better
interoperability with linkers that automatically do CUDA device symbol
resolution and have no way to disable it.
WinRT components need to be referenced in a similar way that managed
code libraries are referenced. Validate that the library reference is a
WinRT component and reference it through the project.
Add test coverage for `VS_WINRT_COMPONENT`. While at it, fix the IOT
reference failing on Win10 SDK 17763 which doesn't include it anymore.
Fixes: #18846
