| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).
This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.
llvm-svn: 183872
|
|
|
|
|
|
|
|
| |
must be initialized by a constant expression (not just a core constant
expression), because we're going to emit it as a global. Core issue for this is
pending.
llvm-svn: 183388
|
|
|
|
|
|
|
|
|
| |
handle temporaries which have been lifetime-extended to static storage duration
within constant expressions. This correctly handles nested lifetime extension
(through reference members of aggregates in aggregate initializers) but
non-constant-expression emission hasn't yet been updated to do the same.
llvm-svn: 183283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
materialized temporary with the corresponding MaterializeTemporaryExpr. This is
groundwork for providing C++11's guaranteed static initialization for global
references bound to lifetime-extended temporaries (if the initialization is a
constant expression).
In passing, fix a couple of bugs where some evaluation failures didn't trigger
diagnostics, and a rejects-valid where potential constant expression testing
would assume that it knew the dynamic type of *this and would reject programs
which relied on it being some derived type.
llvm-svn: 183093
|
|
|
|
|
|
|
|
|
| |
* Treat _Atomic(T) as a literal type if T is a literal type.
* Evaluate expressions of this type properly.
* Fix a lurking bug where we built completely bogus ASTs for converting to
_Atomic types in C++ in some cases, caught by the tests for this change.
llvm-svn: 182541
|
|
|
|
| |
llvm-svn: 181983
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
llvm-svn: 181869
|
|
|
|
|
|
| |
was erroneous and got discarded.
llvm-svn: 181758
|
|
|
|
|
|
| |
debugging code from an unreachable codepath.
llvm-svn: 181731
|
|
|
|
|
|
|
|
| |
inefficient; we perform a linear scan of switch labels to find the one matching
the condition, and then walk the body looking for that label. Both parts should
be straightforward to optimize.
llvm-svn: 181671
|
|
|
|
|
|
|
|
| |
object x, x's subobjects can be constructed by constexpr constructor even if
they are of non-literal type, and can be read and written even though they're
not members of a constexpr object or temporary.
llvm-svn: 181506
|
|
|
|
| |
llvm-svn: 181388
|
|
|
|
|
|
| |
floating-point and pointer types.
llvm-svn: 181376
|
|
|
|
|
|
| |
integers.
llvm-svn: 181287
|
|
|
|
|
|
| |
call 'constexpr' assignment operators for a literal class type.
llvm-svn: 181284
|
|
|
|
|
|
| |
To pacify GCC warning about control reaching end of non-void function.
llvm-svn: 181197
|
|
|
|
|
|
|
|
|
|
|
|
| |
__alignof__ of a field.
This problem can only happen in C++11.
Also do some petty optimizations.
rdar://13784901
llvm-svn: 181185
|
|
|
|
| |
llvm-svn: 181184
|
|
|
|
| |
llvm-svn: 181181
|
|
|
|
| |
llvm-svn: 181173
|
|
|
|
|
|
|
| |
assignments in constant expressions. No significant functionality changes
(slight improvement to potential constant expression checking).
llvm-svn: 181170
|
|
|
|
|
|
|
|
| |
temporary to an lvalue before taking its address. This removes a weird special
case from the AST representation, and allows the constant expression evaluator
to deal with it without (broken) hacks.
llvm-svn: 180866
|
|
|
|
| |
llvm-svn: 180642
|
|
|
|
| |
llvm-svn: 180603
|
|
|
|
|
|
|
|
| |
statement in constexpr functions. Everything which doesn't require variable
mutation is also allowed as an extension in C++11. 'void' becomes a literal
type to support constexpr functions which return 'void'.
llvm-svn: 180022
|
|
|
|
|
|
|
| |
different array elements, even if they're all constructed using the same
default constructor.
llvm-svn: 180017
|
|
|
|
|
|
|
|
|
|
|
| |
Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in
CXXCtorInitializers and in InitListExprs to represent a default initializer.
There's an additional complication here: because the default initializer can
refer to the initialized object via its 'this' pointer, we need to make sure
that 'this' points to the right thing within the evaluation.
llvm-svn: 179958
|
|
|
|
|
|
|
|
| |
references thereto.
Patch by Tong Shen!
llvm-svn: 179585
|
|
|
|
|
|
| |
the AST.
llvm-svn: 179447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For this source:
const int &ref = someStruct.bitfield;
We used to generate this AST:
DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'const int' lvalue <NoOp>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'
Notice the lvalue inside the MaterializeTemporaryExpr, which is very
confusing (and caused an assertion to fire in the analyzer - PR15694).
We now generate this:
DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'int' <LValueToRValue>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'
Which makes a lot more sense. This allows us to remove code in both
CodeGen and AST that hacked around this special case.
The commit also makes Clang accept this (legal) C++11 code:
int &&ref = std::move(someStruct).bitfield
PR15694 / <rdar://problem/13600396>
llvm-svn: 179250
|
|
|
|
| |
llvm-svn: 173802
|
|
|
|
| |
llvm-svn: 173378
|
|
|
|
|
|
| |
commented on and approved by Richard Smith.
llvm-svn: 173377
|
|
|
|
|
|
|
|
| |
This change also makes the serialisation store the required semantics,
fixing an issue where PPC128 was always assumed when re-reading a
128-bit value.
llvm-svn: 173139
|
|
|
|
|
|
| |
OpenCL restrictions (OpenCL 1.2 spec 6.9)
llvm-svn: 172973
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
|
|
|
| |
in case condition type. // rdar://11577384.
Test is conditionalized on x86_64-apple triple as
I am not sure if the INT_MAX/LONG_MAX values in the test
will pass this test for other hosts.
llvm-svn: 172016
|
|
|
|
|
|
|
|
|
|
| |
with respect to the lower "left-hand-side bitwidth" bits, even when negative);
see OpenCL spec 6.3j. This patch both implements this behaviour in the code
generator and "constant folding" bits of Sema, and also prevents tests
to detect undefinedness in terms of the weaker C99 or C++ specifications
from being applied.
llvm-svn: 171755
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
| |
llvm-svn: 171192
|
|
|
|
| |
llvm-svn: 171191
|
|
|
|
| |
llvm-svn: 169095
|
|
|
|
|
|
| |
expressions, not *any* typeid on a polymorphic class type.
llvm-svn: 166156
|
|
|
|
|
|
|
| |
GCC has always supported this on PowerPC and 4.8 supports it on all platforms,
so it's a good idea to expose it in clang too. LLVM supports this on all targets.
llvm-svn: 165362
|
|
|
|
|
|
| |
Part of PR14005.
llvm-svn: 165117
|
|
|
|
|
|
| |
in core constant expressions, despite not being a literal type.
llvm-svn: 164968
|
|
|
|
|
|
| |
Tijl Coosemans!
llvm-svn: 164841
|
|
|
|
|
|
|
| |
parameter packs where the reference is not being expanded but the pack has
been. Previously, Clang would segfault in such cases.
llvm-svn: 163672
|
|
|
|
|
|
|
|
|
| |
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
|
|
|
|
|
|
|
|
|
|
|
| |
CheckLValueConstantExpression.
Richard pointed out that using the address of a TLS variable is ok in a
core C++11 constant expression, as long as it isn't part of the eventual
result of constant expression evaluation. Having the check in
CheckLValueConstantExpression accomplishes this.
llvm-svn: 162850
|