Set the MinTypeNameLength option to an impossibly high value in order
to limit the diagnostics to iterators. Leave new expressions and cast
expressions for later.
This is better than doing CopyFileIfDifferent() followed by RemoveFile() in
two ways:
- it is more efficient, as it avoids disk I/O for the data, even if the
files here are usually small
- it is atomic, so an abort during the copy will not leave a destination file
with partial data behind
Previously the CMake didn't compute the required set of libraries
needed to properly device link a static library when
CUDA_RESOLVE_DEVICE_SYMBOLS was enabled.
7786a05c70 Unity build: Add XCode support
1353802af3 Unity build: Add unit tests
8dfeb5d278 Unity build: Add support for Visual Studio generator
7114c141e2 Unity build: Add support for Ninja and Makefile generators
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Stanislav Ershov <digital.stream.of.mind@gmail.com>
Acked-by: Evgeniy Dushistov <dushistov@mail.ru>
Acked-by: Viktor Kirilov <vik.kirilov@gmail.com>
Merge-request: !3611
It works as expected in Visual Studio.
Visual Studio 2017 will (partially) benefit from the build in
support for unity builds. The custom unity sources are used, because
the build in support doesn't allow batching of certain number of
files. It can do only batching by directory.
Swift has supported `CMAKE_Swift_LANGUAGE_VERSION` and
`Swift_LANGUAGE_VERSION` but didn't apply that to Ninja generated
targets. Consider the property when calculating the flags.
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`
Enables the clang-tidy test performance-inefficient-string-concatenation
and replaces all inefficient string concatenations with `cmStrCat`.
Closes: #19555
This changes `cmMakefile::AddDefinition` to take a `cm::string_view` as value
argument instead of a `const char *`.
Benefits are:
- `std::string` can be passed to `cmMakefile::AddDefinition` directly without
the `c_str()` plus string length recomputation fallback.
- Lengths of literals passed to `cmMakefile::AddDefinition` can be computed at
compile time.
In various sources uses of `cmMakefile::AddDefinition` are adapted to avoid
`std::string::c_str` calls and the `std::string` is passed directly.
Uses of `cmMakefile::AddDefinition`, where a `nullptr` `const char*` might
be passed to `cmMakefile::AddDefinition` are extended with `nullptr` checks.
Handle static libraries similar to shared libraries. Do not pass along
the shared library flags raw as that will pass flags for the linker to
the driver which is incorrect.
On AIX, symbols in executables must be exported in order to be visible
to modules (plugins) they load via `dlopen`. Prior to policy `CMP0065`,
CMake linked all executables with flags to export symbols, but the NEW
behavior for that policy is to do so only for executables that have the
`ENABLE_EXPORTS` target property set. In both cases, CMake has always
used the AIX linker option `-bexpall` option to export symbols from
executables.
This has worked fairly well with the XL compiler, but with the GNU
compiler it works only for C ABI symbols. The reason is that `-bexpall`
does not export symbols starting in `_` but the GNU C++ ABI mangles all
symbols with a leading `_`. Therefore we have only supported C ABI
plugins with the GNU compiler on AIX. Some projects have tried to work
around this by replacing `-bexpall` with `-bexpfull`, but the latter
often exports symbols that we do not want exported.
Avoid using `-bexpall` for executables by instead using by our own
internal `ExportImportList` script to compute symbol export lists from
the object files to be linked into an executable. Pass the explicitly
computed export list to the AIX linker's `-bE:...` option. We already
do this for shared object exports.
Issue: #19163
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.
