whether an expression is a (core) constant expression as a side-effect of
evaluation. This takes us from accepting far too few expressions as ICEs to
accepting slightly too many -- fixes for the remaining cases are coming next.
The diagnostics produced when an expression is found to be non-constant are
currently quite poor (with generic wording but reasonable source locations),
and will be improved in subsequent commits.
llvm-svn: 146289
or MemberExpr which refers to it. As a side-effect, MemberExprs which refer to
static member functions and static data members are now emitted as constant
expressions.
llvm-svn: 144468
reinstates r144273; a combination of r144333's fix for NoOp rvalue-to-lvalue
casts and some corresponding changes here resolve the regression which that
caused.
This patch also adds support for some additional forms of member function call,
along with additional testing.
llvm-svn: 144369
expression evaluation:
- When folding a non-value-dependent expression, we may try to use the
initializer of a value-dependent variable. If that happens, give up.
- In C++98, actually check that a const, non-volatile DeclRefExpr inside an ICE
is of integral or enumeration type (a reference isn't OK!)
- In C++11, DeclRefExprs for objects of const literal type initialized with
value-dependent expressions are themselves value-dependent.
- So are references initialized with value-dependent expressions (though this
case is missing from the C++11 standard, along with many others).
llvm-svn: 144056
partially undoes the revert in r143491, but does not introduce any new instances
of the underlying issue (which is not yet fixed) in code which does not use
the 'constexpr' keyword.
llvm-svn: 143905
to allow us to implement the C++11 rule that a non-active union member can't be
read, and use it to implement subobject access for string literals.
llvm-svn: 143677
just integers and floating point types. Since we don't support evaluating class
types or performing lvalue-to-rvalue conversions on array elements yet, this
just means pointer types right now.
llvm-svn: 143298
Track the function invocation where an lvalue referring to a constexpr function
parameter originated from, and use it to substitute the correct argument and to
determine whether such an argument's lifetime has ended.
llvm-svn: 143296
constexpr function arguments outside of their function (passing or returning
them by reference) does not work correctly yet.
Calling constexpr function templates does not work yet, since the bodies are not
instantiated until the end of the translation unit.
llvm-svn: 143234
are present in all the necessary places:
In constant expression evaluation, evaluate lvalues as lvalues and rvalues as
rvalues. Remove special case for caching reference initialization and fix a
cyclic initialization crash in the process.
llvm-svn: 143204
rvalue. An assertion to catch this is in ImpCastExprToType will follow, but
vector operations currently trip over this (due to omitting the usual arithmetic
conversions). Also add an assert to catch missing lvalue-to-rvalue conversions
on the LHS of ->.
llvm-svn: 143155
Richard Smith