Don't prematurely clean up an RAII object; there's another RAII object in the
same scope that tries to save and restore the same member!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291551 91177308-0d34-0410-b5e6-96231b3b80d8
fields in the class. This allows a better checking of member intiailizers and
in class initializers in regards to initialization ordering.
For instance, this code will now produce warnings:
class A {
int x;
int y;
A() : x(y) {} // y is initialized after x, warn here
A(int): y(x) {} // default initialization of leaves x uninitialized, warn here
};
Several test cases were updated with -Wno-uninitialized to silence this warning.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191068 91177308-0d34-0410-b5e6-96231b3b80d8
Fix to change r173414 that lead to Clang changing const to constexpr even under
-Wno-static-float-init.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173835 91177308-0d34-0410-b5e6-96231b3b80d8
and split it out of -Wgnu into its own warning flag.
* In C++11, this is now a hard error (GCC has no extension here in C++11 mode).
The error can be disabled with -Wno-static-float-init, and has a fixit to
add 'constexpr'.
* In C++98, this is still an ExtWarn, but is now controlled by
-Wstatic-float-init as well as -Wgnu.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173414 91177308-0d34-0410-b5e6-96231b3b80d8
when a class is forward declared, and the reference to the data
member in question does not occur within a method body.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151413 91177308-0d34-0410-b5e6-96231b3b80d8
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147357 91177308-0d34-0410-b5e6-96231b3b80d8
variable is initialized by a non-constant expression, and pass in the variable
being declared so that earlier-initialized fields' values can be used.
Rearrange VarDecl init evaluation to make this possible, and in so doing fix a
long-standing issue in our C++ constant expression handling, where we would
mishandle cases like:
extern const int a;
const int n = a;
const int a = 5;
int arr[n];
Here, n is not initialized by a constant expression, so can't be used in an ICE,
even though the initialization expression would be an ICE if it appeared later
in the TU. This requires computing whether the initializer is an ICE eagerly,
and saving that information in PCH files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146856 91177308-0d34-0410-b5e6-96231b3b80d8
Sam McCall