4f95e6b284 ci: test BMI exporting and installation with GCC in CI
c49d5f137b RunCMake/CXXModules: add a "deep-chain" test
297e0f4dce cmCxxModuleMapper: support MSVC module map format
b3c2880cb2 cmCxxModuleMapper: track transitive modules for MSVC
a43713d615 CTestCustom: ignore `cm::optional` uninitialized memory false positive
b90de0b492 RunCMake/CXXModules: support MSVC extensions
a84c186a7d cmScanDepFormat: support the MSVC 17.3 toolchain temporarily
d7f5064ff7 cmScanDepFormat: support P1689R5
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7481
Original code had path generators built at run-time using a linked list
of dynamically allocated nodes each of which was responsible to generate
a path segment.
However, the combination of used generators is totally well known at
compile time.
When building `cmake-gui` with system-installed `zlib` and `QtCore`,
the latter has a different copy of zlib that conflicts and produces
warnings on Solaris. Suppress them from report to CDash to clean
up nightly builds.
Provide our own minimal `config.h` since the upstream one is much
larger to support other parts of its distribution. Compile with
warnings disabled since this is third-party code.
Some compilers do not like the nested `{{{}}}` member initialization
syntax, so use just `{}`. GCC 4.8 warns about the latter, so add a
suppression.
Fixes: #20097
The last KDevelop3 release was many years ago, in 2008 I think.
I haven't seen or read about anybody using KDevelop 3 since a
long time, so I think it can safely be removed from CMake.
KDevelop 4 (first released in 2010) has its own proper CMake
support now, independent from this generator.
Alex
The `WarningMessagesDialog.cxx` source file name is displayed by
MSVC in the compiler output, and the CTest launcher matches the
name as a warning line starting in "Warning". Suppress this
false positive with a custom exception.
Revise the manual procedure in the `*Lexer.in.l` files. Some of our
post-processing steps are no longer necessary with the current set of
supported compilers. Some steps changed with newer versions of flex.
Then regenerate all lexers with flex version 2.6.1.
Clang scan-build warns in some expansions of RB_GENERATE_STATIC
that it has a "Dereference of null pointer". It also warns that
"The left operand of '==' is a garbage value" strangely. Simply
suppress these since this is third-party code anyway.
The Clang scanbuild tool warns:
Utilities/cmliblzma/liblzma/simple/x86.c:106:23: warning:
The result of the '<<' expression is undefined
src = dest ^ ((1u << (32 - i * 8)) - 1);
~~~^~~~~~~~~~~~~~~
AFAIK overflow of a left shift on an unsigned type is well-defined.
We first suppressed this in commit v3.1.0-rc1~647^2 (CTestCustom:
Suppress warnings about rand() and srand() on OpenBSD, 2014-04-12).
Add another variant of the warning wording.
Our `cmake.version.manifest` file uses a "compatibility" element for
Windows 10 support. Older MS tools warn about it being unknown, so
suppress the warning.
On Solaris the system `/usr/include/floatingpoint.h` header contains
typedef float single;
so the GNU compiler warns that uses of the name `single` shadow it.
Just suppress the warning because our uses of this name would become
less readable with a different name.
The HP compiler on HP-UX 11.11 warns:
Warning (anachronism) 823: ".../test_INT_format.h", line 194 # Redundant
preprocessing concatenation operation results in two valid preprocessing
tokens. Depending on this implementation defined behavior will result in
non-portable code.
TEST_C(INT32_C, -0x55000000, i32, int32_t, uint32_t)
^^^^^^
Warning (anachronism) 823: ".../test_INT_format.h", line 196 # Redundant
preprocessing concatenation operation results in two valid preprocessing
tokens. Depending on this implementation defined behavior will result in
non-portable code.
TEST_C(INT64_C, -0x5500000000000000, i64, int64_t, uint64_t)
^^^^^^
There is likely a subtle problem with the way one of the system-provided type
macros is defined but the test passes despite the warning. Simply suppress it.
