Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`, now with "east const" enforcement.
Use `clang-format` version 18.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Issue: #26123
The check added by commit 40af103402 (cmCMakePath: do not use
std::filesystem::path with RH gcc-toolset-10, 2023-12-02, v3.28.0~5^2)
fails unnecessarily in some cases due to not inheriting
`std::string_view` publicly.
Inheritance into a class is private by default, and this std class has
public members that would be access restricted when used to create
public objects in the current scope.
On some versions of GCC, depending on standards options, this causes
either template instantiation errors, or "inaccessible base" or "not
declared" errors.
Fix by setting the inheritance to public. This does not affect the
intention of the previous fix because the check still fails when using
gcc-toolset-10's standard library with clang.
Issue: #25458, #25453
Filter out `-Wunused-command-line-argument` warnings from Clang (that
can be caused by user-specified flags) so that they do not break our
checks for C++ feature availability.
This extends commit 71b65abca2 (C++ feature checks: Filter out warnings
caused by user flags, 2017-09-19, v3.10.0-rc1~90^2).
* Add `lexically_normal` test for all platforms.
* On Windows, MinGW does not currently handle `lexically_normal()`
correctly on UNC path, but MSVC and IntelLLVM do--add a comment
on this to avoid future confusion.
* Add test with `\\?\` notation and `weakly_canonical` that also triggers
the MinGW bug, but is fine with MSVC and oneAPI, for a more robust and
comprehensive test.
40af103402 cmCMakePath: do not use std::filesystem::path with RH gcc-toolset-10
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9026
Extend commit 78bbd58545 (Source: Link libatomic when needed on Linux
32-bit ARM, 2023-07-27, v3.27.2~10^2) to check for libatomic on more
architectures.
Fixes: #25204
78bbd58545 Source: Link libatomic when needed on Linux 32-bit ARM
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8663
ee9805ccd1 cm/filesystem: Fix crash with pre-C++11 std::string GNU ABI in C++17
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7813
The `remove_filename` and `replace_extension` methods compute an offset
between the whole path in a `std::string` and a part of a path in a
`std::string_view`. This is done by subtracting their `.data()`
pointers. However, C++17 adds a non-const `.data()` through which
modification of the string is allowed. This means the copy-on-write
implementation used by the pre-C++11 std::string GNU ABI must reallocate
if the string has been copied. Our subtraction then computes an offset
between two different allocations, which is undefined behavior.
The workaround in commit b3ca4f9ad1 (cm/filesystem: Work around crash
when compiled for CYGWIN/MSYS runtime, 2021-04-22, v3.21.0-rc1~271^2~2)
avoided the problem by calling the non-const `.data()` to reallocate
before constructing the `string_view`. Instead, explicitly call the
const `.data()` method on the string, which does not reallocate.
Fixes: #22090, #23328
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
In commit eb583b0a66 (cmake_path command: path management, 2020-07-23,
v3.19.0-rc1~216^2~1) we added a `try_run`. In cross-compilation mode,
C++ features tests must avoid running tests if there is no emulator
defined.
Without this, CMake fails to build on Cray systems with a
craype-hugepages modulefile loaded on the front-end due to libhugetlbfs
warnings breaking the CXX Feature tests. Filter out the warnings so the
bootstrap can proceed to successfully install CMake on Cray Linux
systems.
Fixes: #20645
Require the word "warning" to appear at the start of a line, after
whitespace, or after a `:`. This is the same that CTest launchers use
to match warnings. It avoids matching "warning" inside file paths.
Fixes: #19019
Make sure `std::cbegin`, `std::cend`, and `std::size` work in C++17 or
C++14 mode before choosing the corresponding standard level for
compiling CMake itself. This helps in cases that the compiler is using
a standard library too old to support the full standard level chosen.
Make sure `std::cbegin`, `std::cend`, and `std::size` work in C++17 or
C++14 mode before choosing the corresponding standard level for
compiling CMake itself. This helps in cases that the compiler is using
a standard library too old to support the full standard level chosen.
