Issue: #17849

Clang 5.0 added support for the `-std=c++17` flag.

Ruben Van Boxem authored Jun 18, 2017 and Brad King committed Jun 27, 2017

The `cl.exe` style command line does not accept the `-std=` options.
Instead behave like MSVC where we don't define standard levels.

Fixes: #16266

Condition all calls to `_record_compiler_features_{c,cxx}` on
`_result EQUAL 0` so that adding new language standards later does
not need to update them.  Avoid some duplicate compiler version
checks by conditioning C11 and CXX14 feature recording on the
existence of `CMAKE_{C11,CXX14}_STANDARD_COMPILE_OPTION` (whose
setting already used the version check).

Simplify and de-duplicate per-compiler feature recording macros and
convert to a centralized per-language macro.

Drop the 'UNIX' condition on Clang compiler features.  This enables
use of compile features with MinGW Clang, though additional work may
be needed for clang-cl.

Prior to commit v3.4.0-rc1~71^2 (Project: Determine default language
dialect for the compiler, 2015-09-15) we always guessed the default
language standard dialect based on the compiler version.  This was not
reliable so that commit switched to computing the default language
standard dialect while detecting the compiler id.

When a toolchain file uses CMakeForceCompiler to set the compiler id
then the detection does not occur.  Therefore commit v3.4.0-rc1~54^2
(Project: Don't require computed default dialect if compiler was forced,
2015-09-22) made the lack of detection an error only if the compiler was
not forced.  However, this means that projects using CMakeForceCompiler
no longer even get the guess that we had before so <LANG>_COMPILER does
not work.

Due to the sophistication of CMake's compiler detection logic projects
should be ported away from using CMakeForceCompiler.  In the meantime,
restore a guess of the default language standard dialect when the
compiler is forced.

Commit 7235334a (Project: Determine default language dialect for the
compiler., 2015-09-15) introduced a mechanism to determine the default
dialect used for the running compiler.  If conditions in
the <CompilerId>-<Lang>.cmake file are such that compile features for
that version of the compiler should be supported, the _DEFAULT_STANDARD
is set to the computed value.

However, the CMakeForceCompiler module allows users to bypass execution of the
compiler by CMake.  In that case, do not set the _DEFAULT_STANDARD variable at
all, which effectively disables the compile-features where the module is used.

No compile features have ever been recorded where the module is used so no
functionality is lost.

Stephen Kelly authored Sep 15, 2015 and Brad King committed Sep 18, 2015

Use the __cplusplus and __STDC_VERSION__ macros to automatically
determine the default dialect for the compiler while determining its
id and version.

Stephen Kelly authored Feb 04, 2015 and Brad King committed Feb 04, 2015

If no compiler feature information is known for a given compiler
version, do not set a language standard default either.  The two
settings must be recorded consistently.

GNU-CXX already has complex logic and sets the _result to 0 before
tests which may set it to something else.

Change the other modules to be consistent with that.

Fraser Hutchison authored Nov 19, 2014 and Brad King committed Nov 19, 2014

When testing CMAKE_<LANG>_COMPILER_ID values against "MSVC", do not
allow the definition of the "MSVC" variable to be expanded.

Fraser Hutchison authored Nov 19, 2014 and Brad King committed Nov 19, 2014

When testing CMAKE_<LANG>_COMPILER_ID values against "MSVC", do not
allow the definition of the "MSVC" variable to be expanded.

Avoid using -std=c++1y for compilers which support -std=c++14, for
example.

Clang 3.4 supports all features currently known to CMake.

These are compiler-specific, compiler version specific, extension specific
and standard version specific.

The Clang-CXX module is going to get version-specific checks, and
the version system for AppleClang is not the same as Clang.

Teach the compiler identification preprocessor tests to report when
Clang simulates MSVC, and what version.  If not MSVC, assume GNU.

Teach compiler information modules Clang-(C|CXX) to recognize when Clang
simulates MSVC and skip loading the GNU information.

Teach the Windows-MSVC platform information to recognize when it is
loaded as the simulated compiler and use that version information
instead of the real compiler's (different) version scheme.

Add platform modules Windows-Clang-(C|CXX) and support module
Windows-Clang to load either Windows-MSVC or Windows-GNU and wrap
the corresponding information macros.

This corresponds to the g++ and clang++
option -fvisibility-inlines-hidden on linux. On Windows with MinGW,
this corresponds to -fno-keep-inline-dllexport. That option is
not supported by clang currently.

While Clang presents an almost identical interface to GNU there will be
some differences.  Split the compiler information modules to allow
separate rules for Clang.  Start by loading the GNU rules but leave a
place to add Clang-specific information.

Map to the platform and compiler information for GNU because the
compilers are command-line compatible for common operations.  Later we
can add Clang-specific features as necessary.  We honor the preferred
capitalization is "Clang", not the common mis-spelling "CLang".