| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a variable to indicate the latest standard known to be supported for
each language:
* `CMAKE_C_STANDARD_LATEST`
* `CMAKE_CXX_STANDARD_LATEST`
* `CMAKE_CUDA_STANDARD_LATEST`
* `CMAKE_HIP_STANDARD_LATEST`
* `CMAKE_OBJC_STANDARD_LATEST`
* `CMAKE_OBJCXX_STANDARD_LATEST`
These variables, more generally referred to as
`CMAKE_<LANG>_STANDARD_LATEST`, are assigned an integer value which
represents the minimum between the latest version of the associated
language standard supported by the current compiler and the latest
version supported by CMake.
Add documentation for these variables in a new page called
`CMAKE_<LANG>_STANDARD_LATEST` was added under the "Variables for
Languages" section of the `cmake-variables(7)` page.
Update each compiler-specific CMake script under
`${CMAKE_ROOT}\Modules\Compiler` to manually define the relevant
`CMAKE_<LANG>_STANDARD_LATEST` variable as necessary. This will
require updating and maintaining as newer compiler versions become
recognized by CMake.
Closes: #25717
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add `COMPILE_WARNING_AS_ERROR` target property and supporting
`CMAKE_COMPILE_WARNING_AS_ERROR` variable.
`COMPILE_WARNING_AS_ERROR` is initialized by
`CMAKE_COMPILE_WARNING_AS_ERROR`. It is a boolean variable. If it is
true, it expands to a different flag depending on the compiler such that
any warnings at compile will be treated as errors.
Supports compiler ids that I could find a relevant flag for.
|
| |
|
|
|
|
|
|
|
|
| |
Since commit f29e1874ad (Compiler/MSVC: use the `-external:I` flag for
system includes, 2020-05-19, v3.22.0-rc1~593^2) we use the new flag
followed by the include directory as a separate argument. Some versions
of `clang-cl` and `clang-tidy` do not support the flag unless the
include directory is attached to it, so use that form instead.
Fixes: #22979
|
| |
|
|
|
|
| |
C17 support has been available in MSVC since VS 16.8.
Fixes: #22816
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
We already do this for `clang-tidy`.
Fixes: #16554
|
| |
|
|
| |
See: #17904
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Supported since MSVC 19.28.29115 (VS 16.8.0 Preview 1.0).
|
| |
|
|
|
|
|
| |
MSVC >=19.27 supports a C11 switch.
The `c_restrict` feature has also been implemented.
Fixes: #21069
|
| |
|
|
|
|
|
| |
`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 f92ccbc306c20554af
(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
|
