Generalize the `__STDC_VERSION__` exception previously added for
AppleClang < 14 to also cover LLVM/Clang < 14. Although the two
vendors do not follow the same version scheme, the major versions
happen to match in this case.
Explicitly enable standard levels in the `CompileFeatures` test that are
expected to work in each job regardless of whether compiler inspection
detects support.
These versions of the compiler have experimental C++11 support and so do
not define `__cplusplus` correctly, but do define a feature macro we can
use to distinguish this mode.
The Intel Classic C++ compiler is based on EDG. It does not always
define `__cplusplus` correctly, but does define feature macros that we
can use to distinguish these modes.
The Intel Classic C++ compiler for Windows does not always define
`_MSVC_LANG` correctly, but does define feature macros that we can use
to distinguish these modes.
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 15.
* 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.
Fixes: #24315
Previously we added the language standard flag near the end of all
options, even after those added by `add_compile_options` and friends.
However, on some compilers such as MSVC, the `-std` flag may reset
defaults for flags that precede it on the command line. Move the
language standard flag to before all other flags that CMake adds for
other abstractions, and before those added by `add_compile_options`.
`CMAKE_<LANG>_FLAGS` should still precede the language flags though,
because they are meant to be treated as language-wide modifications to
the compiler defaults, similar to `$CC $CFLAGS`.
Fixes: #23860Fixes: #24170
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.
For the Intel Compiler for Windows we have some subtle preprocessor
checks in compiler feature detection to detect C++11 and C++14 modes.
Use these when detecting the default C++ dialect too.
SunPro 5.15 supports `-std=c++14` and several C++14 features.
SunPro 5.14 accepts `-std=c++14` but does not update its definition of
`__cplusplus` or any other macro to distinguish it from `-std=c++11`,
so we need to blacklist a couple features that do work but that we
cannot report for that version. We can still support `cxx_std_14`.
Co-Author: Robert Maynard <robert.maynard@kitware.com>
Previously compilers that only supported the meta-level flags
would not have any of the granular features listed. Now we
presume that they have full support and enable all the features.
Update granular feature tests to skip the actual compilation
checks for the presumed features.
The genex part of the test verifies that `$<COMPILE_FEATURES:...>`
evaluates as expected. It does not need to actually try using code with
the associated features, as that is tested separately.
`AddRequiredTargetC(xx)` feature didn't take the default compiler
standard into account, which possibly resulted in the use of an older
standard when some features requested it.
Fixes: #18686
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* 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.
Update `.clang-format` with configuration to make the 6.0 format as
close as possible to what 3.8 produced before. Then revise the style:
* Indent preprocessor directives (a feature new since 3.8)
* Add a newline and indentation before inheritance `:` and `,`
Rename the Git attribute identifying the format to include the
clang-format version number: `format.clang-format-6.0`. This will aid
external infrastructure in knowing what version of the tool to run.
Rather than repeating compiler version checks for feature availability,
generate genex expectations using the detect list of features. We
already separately verify that the list of features is correct.
8570dc7f64 Help: Update compiler versions in cmake-compile-features.7.rst
874d3d2948 Help: Add release note for C++ 20 support
7f295b1bd3 Features: Activate C++ 20 support for Clang 5.0+
71cb8ce3a1 Features: Activate C++ 20 support for GNU 8.0+
8f146c4508 Features: Activate C++ 20 support for MSVC 19.12.25835+
7fe580a362 Features: Add infrastructure for C++ 20 language standard
1b328e09a3 Features: Use -std=c++17 for C++ 17 on Clang 5.0+
0bc3e5788a Features: Use -std=c++17 for C++ 17 on GNU 8.0+
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1892
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
