Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* 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.
Since CMake is written in C++98 any clang-format configuration must
set `Standard` to `Cpp03` so that `A<A<int> >` is not rewritten as
`A<A<int>>`. However, this will cause `U"foo"` to be rewritten as
`U "foo"`. Add markup to turn clang-format off in the one place
that the latter case occurs so that we do not need a separate
`.clang-format` config file for it.
Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
VS 2013 originally claimed to support initializer lists but a bug was
found in which it generated bad code silently. For this reason we
previously considered support to not be present. However, Update 3 adds
a hard error on cases that previously generated bad code, so it is now
safe to use initializer lists with VS 2013 Update 3 or greater. At
worst a compiler error will be issued in the cases that do not work, but
that is no different from any other compiler-specific workaround a
project code may need.
The only reason this failed to compile on VS 2013 was because the
compiler uses different initializer_list constructor argument types than
our dummy implementation. The standard does not specify the non-default
constructor argument types for initializer_list. Use a template to
match any two-arg constructor a compiler might select (e.g. begin/end or
begin/len). Use #error to preserve the error on VS 2013.
This bug caused c_function_prototypes to not be recorded at configure
time when compiling with -std=gnu99 or similar. In the case of feature
recording, that was not a problem, because the logic in
CMakeDetermineCompileFeatures.cmake currently assumes that a feature
present for an earlier standard is present for a later standard.
However, the detection strings are also used in WriteCompilerDetectionHeader,
so the feature macro has been defined to '0' when using a later language
dialect.
Fix that by not checking the existence of the __STDC_VERSION__ macro at
all when detecting C90 features.
Define an empty string in CMAKE_<LANG>_STANDARD_DEFAULT to mean that
the toolchain has no notion of lanuage standard levels. In this case
the <LANG>_STANDARD[_REQUIRED] properties will have no effect.
Update the RunCMake.CompileFeatures test to exclude the
LinkImplementationFeatureCycle test when there is no standard default.
It can never fail because no use of specific features will adjust the
CXX_STANDARD level required for any target since the standard levels
have no meaning in this case.
Whenever feature support is added to a compiler, the CompileFeatures
test needs to be updated to set expected availability of features.
Add #error directives to ensure the test fails if expectations are
not set.
Suggested-by: Stephen Kelly <steveire@gmail.com>
965a50dc Features: Fix GNU 4.4 and 4.5 C standard level flags
7f4154a4 Features: Fix CompileFeatures non-feature tests for space in path
f40c19b5 Features: Fix CompileFeatures test for C non-features
Fix the <lang>_non_features try_compile calls to work correctly when
there is a space in the path. Otherwise they all fail due to the space
instead of the lack of a feature.
004e1540 Features: Record for GNU 4.4.
2a5ca650 Features: Wrap failure-test in UNIX condition.
1ae2c6b2 Features: Blacklist cxx_constexpr test for GNU 4.5.
c66e3317 Features: Use a more-common feature in cycle-test.
c43a6dc5 Features: Update comment in test to match the code.
78259135 Features: Test presence of cxx_auto_type with genex.
7b9fc88b Features: Remove outdated comment.
The purpose of that test is to cover the case where the genex
reports '1', and the feature is chosen to be present on all/most
supported compilers. GNU 4.4 does not support cxx_nullptr.
The change in commit 1f19ac4d (Features: Adjust cxx_variadic_templates
unit test for GNU < 4.7., 2015-01-11) pacified GNU 4.6, but leaves
SolarisStudio 12.4 complaining:
"cxx_variadic_templates.cpp", line 5: Error: Partial specialization for Interface<Is...> has identical arguments.
1 Error(s) detected.
Implement a preprocessor test for using the partial specialization
workaround needed by GNU 4.6.
SolarisStudio considers 'auto' to be a storage class specifier in
C++98 mode (as appropriate), and considers variables without a specified
type to be of type int. So, it treats
auto x = 3.14;
as
auto int x = 3.14;
which in C++98 mode is equivalent to
int x = 3.14;
and it does not fail to compile as expected.
Change the test to use a reference so that the type must be known.
The unit test for this fails with GNU 4.6:
Building CXX object CMakeFiles/test_cxx_variadic_templates.dir/cxx_variadic_templates.cpp.o
CompileFeatures/cxx_variadic_templates.cpp: In static member function ‘static int Interface<I, Is>::accumulate()’:
CompileFeatures/cxx_variadic_templates.cpp:18:31: sorry, unimplemented: cannot expand ‘Is ...’ into a fixed-length argument list
CMakeFiles/test_cxx_variadic_templates.dir/build.make:54: recipe for target 'CMakeFiles/test_cxx_variadic_templates.dir/cxx_variadic_templates.cpp.o' failed
The workaround is to use a specialization:
http://stackoverflow.com/questions/1989552http://stackoverflow.com/questions/11297376
Because not all compilers under test support the existing 'activation
features', add another test to ensure that compilers which support
both static_assert and nullptr behave as expected in this test.
The purpose of the feature listing in these tests is to make other
features from the same feature set (eg "C++11 features") available.
The compilers under test until now have supported these 'activation
features', but MSVC does not. Use the cxx_static_assert feature
instead to activate the feature set.
The tests below test the presence of both cxx_final and cxx_override,
only one of which is supported by MSVC. The test is in part intended
to verify that the COMPILE_FEATURES genex supports multiple arguments
and allows users to define names for groups of features (Clang already
calls cxx_final and cxx_override 'override control' as a group). Keep
the test, and allow the expectation to be set as appropriate.
Clang 3.4 uses C99 by default, and Clang 3.6 uses C11 by default:
http://thread.gmane.org/gmane.comp.compilers.clang.devel/39379
GNU 4.9 uses C90 by default, and GNU 5.0 uses C11 by default:
https://gcc.gnu.org/gcc-5/changes.html
Test that the default compiler settings result in the expected dialect
macros being defined for both C and CXX. Remove the unused main.c
file from the CompileFeatures unit test.
Allow setting build properties based on the features available
for a target. The availability of features is determined at
generate-time by evaluating the link implementation.
Ensure that the <LANG>_STANDARD determined while evaluating
COMPILE_FEATURES in the link implementation is not lower than that
provided by the INTERFACE of the link implementation. This is
similar to handling of transitive properties such as
POSITION_INDEPENDENT_CODE.
Add properties and variables corresponding to CXX equivalents.
Add features for c_function_prototypes (C90), c_restrict (C99),
c_variadic_macros (C99) and c_static_assert (C11). This feature
set can be extended later.
Add a <PREFIX>_RESTRICT symbol define to WriteCompilerDetectionHeader
to conditionally represent the c_restrict feature.
Remove the use of check_cxx_source_compiles which is now just getting in
the way.
Blacklist the cxx_alignof feature in the test with GNU 4.7. The test
file compiles, but it is documented as available first in GNU 4.8.
Kitware Robot
Brad King
Robert Maynard
Levi Morrison
Stephen Kelly