MSVC `cl` versions prior to 19.27 had no `-std:c*` flags for C
standards. List the `c_std_{17,23}` features anyway. This allows
projects to at least attempt compilation with these compilers since they
do not have any modes.
The custom "no modes" `cmake_record_c_compile_features` implementation
should only be used in `cl` versions prior to 19.27 because they had no
`-std:c*` flags for C standards. For 19.27 we need a different custom
implementation to account for partial C11 support. For 19.28 and above
we can use the default implementation through the `*__HAS_FULL_SUPPORT`
settings.
We already use this pattern in the MSVC C++ compile feature table.
This change was originally made by commit 74b1c9fc8e (Explicitly specify
language flag when source LANGUAGE property is set, 2020-06-01,
v3.19.0-rc1~722^2), but it was reverted by commit 30aa715fac (Revert
"specify language flag when source LANGUAGE property is set",
2020-11-19) to restore compatibility with pre-3.19 behavior.
Implement the change again, but add policy CMP0119 to make this change
while preserving compatibility with existing projects.
Note that the `Compiler/{Clang,Intel,MSVC}-CXX` modules do not need to
specify `-TP` for their MSVC-like variants because we already use the
flag in `CMAKE_CXX_COMPILE_OBJECT`. Similarly for `Compiler/XL-CXX`
and `Platform/Windows-Embarcadero`.
Note also that this does not seem possible to implement for XL C.
Even with `-qsourcetype=c`, `xlc` complains about an unknown suffix:
`1501-218 (W) file /.../AltExtC.zzz contains an incorrect file suffix`.
It returns non-zero even with `-qsuppress=1501-218`.
Co-Author: Robert Maynard <robert.maynard@kitware.com>
Fixes: #14516, #20716
`clang-tidy` does not infer driver mode if it is not provided with a
JSON compilation database. This is exactly the way cmake launches it.
Hence clang-tidy will only use the default driver mode. Add an explicit
driver mode argument to avoid this.
In commit 8e4899fd6c (CompileFeatures: Record which C features the MSVC
compiler supports, 2019-04-12) our `cmake_record_c_compile_features`
macro was accidentally left not setting the `_result` variable, which
had previously been set by `_record_compiler_features`. The variable is
expected by the call site in `cmake_determine_compile_features` and used
to switch between "failed" and "done" reports. Set it now.
Also record `c_variadic_macros` only for cl 14 (VS 2005) and higher
because it is not supported before that version.
Use the infrastructure added by commit f92ccbc306
(CompileFeatures: memoize C compilers with full language level support)
to avoid using a `try_compile` to check for C 90/99/11 feature support when the running compiler is known to have a fixed set of feature support.
The MSVC C compiler has no notion of C language standards or flags.
Tell CMake to assume that all language standards are available.
Record available C language features depending on the version of
the compiler.
Fixes: #17858