Commit Graph

112 Commits

Author SHA1 Message Date
Eli Friedman b13e64eb60 Fix error recovery with in-class initializer.
Previously, for a field with an invalid in-class initializer, we
would create a CXXDefaultInitExpr referring to a null Expr*.
This is not a good idea.

llvm-svn: 185216
2013-06-28 21:07:41 +00:00
Richard Smith e83b1d3e7a More of N3652: don't add an implicit 'const' to 'constexpr' member functions when checking for overloads in C++1y.
llvm-svn: 184865
2013-06-25 18:46:26 +00:00
Richard Smith 51f0317e52 PR16377: Allow evaluation of statement expressions in constant evaluation,
why not. Apparently GCC supports this.

llvm-svn: 184396
2013-06-20 03:00:05 +00:00
Richard Smith 82c9b5183f Fix handling of const_cast from prvalue to rvalue reference: such a cast is
only permitted if the source object is of class type, and should materialize a
temporary for the reference to bind to.

llvm-svn: 184017
2013-06-14 22:27:52 +00:00
Richard Smith 4055de40ab Implement core issue 903: only integer literals with value 0 and prvalues of
type std::nullptr_t are null pointer constants from C++11 onwards.

llvm-svn: 183883
2013-06-13 02:46:14 +00:00
Richard Smith cc1b96d356 PR12086, PR15117
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
2013-06-12 22:31:48 +00:00
Richard Smith faadef7369 Recursively lifetime-extend into array temporaries. These can get implicitly
created through binding a reference-to-array to an initializer list.

llvm-svn: 183594
2013-06-08 00:02:08 +00:00
Richard Smith ea4ad5d841 When a static storage duration temporary appears in a constant expression, it
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
2013-06-06 08:19:16 +00:00
Richard Smith e6c0144208 Model temporary lifetime-extension explicitly in the AST. Use this model to
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
2013-06-05 00:46:14 +00:00
Richard Smith 844010455d Refactor constant expression evaluation to associate the complete object of a
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
2013-06-03 05:03:02 +00:00
Richard Smith a23ab514c2 PR14772: Support constant expression evaluation for _Atomic types.
* 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
2013-05-23 00:30:41 +00:00
Richard Smith 0838f3a1f2 Suppress bogus "use of undefined constexpr function" error if the function body
was erroneous and got discarded.

llvm-svn: 181758
2013-05-14 05:18:44 +00:00
Richard Smith 430c23bb42 Handle parens properly when initializing a char array from a string literal.
llvm-svn: 181159
2013-05-05 16:40:13 +00:00
Richard Smith 9f8400eca4 PR15884: In the 'taking the address of a temporary' extension, materialize the
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
2013-05-01 19:00:39 +00:00
Richard Smith 3da88fac54 C++1y: support simple variable assignments in constexpr functions.
llvm-svn: 180603
2013-04-26 14:36:30 +00:00
Richard Smith d9f663b510 C++1y constexpr extensions, round 1: Allow most forms of declaration and
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
2013-04-22 15:31:51 +00:00
Richard Smith 9543c5e371 Fix array constant expression evaluation bug: we can have different values for
different array elements, even if they're all constructed using the same
default constructor.

llvm-svn: 180017
2013-04-22 14:44:29 +00:00
Richard Smith 034185c2f9 The 'constexpr implies const' rule for non-static member functions is gone in
C++1y, so stop adding the 'const' there. Provide a compatibility warning for
code relying on this in C++11, with a fix-it hint. Update our lazily-written
tests to add the const, except for those ones which were testing our
implementation of this rule.

llvm-svn: 179969
2013-04-21 01:08:50 +00:00
Richard Smith d202924db6 Clarify the diagnostic for -Wnested-anon-types.
llvm-svn: 174032
2013-01-31 03:11:12 +00:00
Richard Smith 254d2666e4 Add a -pedantic warning: an anonymous union within an anonymous union is not
permitted in standard C++, despite being silently accepted by many (all?) major
C++ implementations.

llvm-svn: 173643
2013-01-28 00:54:05 +00:00
Richard Smith e10d304d20 PR11851 (and duplicates): Whenever a constexpr function is referenced,
instantiate it if it can be instantiated and implicitly define it if it can be
implicitly defined. This matches g++'s approach. Remove some cases from
SemaOverload which were marking functions as referenced when just planning how
overload resolution would proceed; such cases are not actually references.

llvm-svn: 167514
2012-11-07 01:14:25 +00:00
Richard Smith bf83009c7f Partially roll back r166898; it exposed a bug in the standard.
The problem is as follows: C++11 has contexts which are not
potentially-evaluated, and yet in which we are required or encouraged to
perform constant evaluation. In such contexts, we are not permitted to
implicitly define special member functions for literal types, therefore
we cannot evalaute those constant expressions.

Punt on this in one more context for now by skipping checking constexpr
variable initializers if they occur in dependent contexts.

llvm-svn: 166956
2012-10-29 18:26:47 +00:00
Richard Smith 2f36dae5c0 When determining whether to try evaluating the initializer of a variable, check
whether the initializer is value-dependent rather than whether we are in a
dependent context. This allows us to detect some errors sooner, and fixes a
crash-on-invalid if a dependent type leaks out to a non-dependent context in
error recovery.

llvm-svn: 166898
2012-10-28 06:18:02 +00:00
Richard Smith 527b15e8f1 PR14171: Don't crash if we hit one of the paths where GetFullTypeForDeclarator
rebuilds a function type, and that function type has parens around its name.

llvm-svn: 166644
2012-10-24 23:51:56 +00:00
Richard Smith 6f3d435c5a DR1535: only potentially-evaluated typeid expressions are disallowed in constant
expressions, not *any* typeid on a polymorphic class type.

llvm-svn: 166156
2012-10-17 23:52:07 +00:00
Richard Smith cdd1da209d Fix treatment of case which came up on std-proposals@: 'void' is permitted in core constant expressions, despite not being a literal type.
llvm-svn: 164968
2012-10-01 20:36:17 +00:00
Hans Wennborg cb9ad9908b Move TLS check from LValueExprEvaluator::VisitVarDecl to
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
2012-08-29 18:27:29 +00:00
Hans Wennborg 2efa2c33ec Fix r162835 as per Richard's comments.
VisitVarDecl should return Error(E), and we should test that the address
of a TLS var can't be used as a constexpr.

llvm-svn: 162837
2012-08-29 09:17:34 +00:00
David Blaikie 1c7c8f7637 Implement warning for integral null pointer constants other than the literal 0.
This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...

There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.

Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.

Review by Sean Silva and Richard Smith.

llvm-svn: 161501
2012-08-08 17:33:31 +00:00
Richard Smith 45edb704d3 When building a conditional operator where one operand is a throw-expression
and the other is a glvalue of class type, don't forget to copy-initialize a
temporary when performing the lvalue-to-rvalue conversion on the glvalue.
Strangely, DefaultLvalueConversions misses this part of the lvalue-to-rvalue
conversions.

llvm-svn: 161450
2012-08-07 22:06:48 +00:00
Richard Smith 9fce7bc721 Fix crash when constant-evaluating a CXXConstructExpr representing
value-initialization for an array of class type with a trivial default
constructor.

llvm-svn: 160024
2012-07-10 22:12:55 +00:00
Richard Smith 1b9f2eb76b PR13290: Constant-evaluation support for CXXConstructExprs which construct a
multidimensional array of class type. Also, preserve zero-initialization when
evaluating an initializer list for an array, in case the initializers refer to
later elements (which have preceding zero-initialization).

llvm-svn: 159904
2012-07-07 22:48:24 +00:00
Richard Smith e20c83d9ed PR12670: Support for initializing an array of non-aggregate class type from an
initializer list. Patch by Olivier Goffart, with extra testcases by Meador Inge
and Daniel Lunow.

llvm-svn: 159896
2012-07-07 08:35:56 +00:00
Richard Smith d86812d95c PR13273: When performing list-initialization with an empty initializer list,
actually perform value initialization rather than trying to fake it with a call
to the default constructor. Fixes various bugs related to the previously-missing
zero-initialization in this case.

I've also moved this and the other list initialization 'special case' from
TryConstructorInitialization into TryListInitialization where they belong.

llvm-svn: 159733
2012-07-05 08:39:21 +00:00
Richard Smith 1355465227 Additional testing for fixes in r158289 and r158290 to allow implicitly-declared
constructors for non-literal types to be constexpr in some circumstances.

llvm-svn: 159513
2012-07-02 06:15:40 +00:00
Richard Smith 26d4cc1b96 Fix lifetime issue for backing APValue of OpaqueValueExpr in recursive
constexpr function evaluation, and corresponding ASan / valgrind issue in
tests, by storing the corresponding value with the relevant stack frame. This
also prevents re-evaluation of the source of the underlying OpaqueValueExpr,
which makes a major performance difference for certain contrived code (see
testcase update).

llvm-svn: 159189
2012-06-26 08:12:11 +00:00
Richard Smith 9dd6e8f3ac PR12826: Converting an lvalue to an xvalue is a no-op conversion, not an lvalue-to-rvalue conversion.
llvm-svn: 156803
2012-05-15 05:04:02 +00:00
John McCall d7bca7629c My first effort to do this more subtly failed, so elaborately
test for an invalid declaration at every single place in the
constant evaluator that's about to request a struct layout.

llvm-svn: 155868
2012-05-01 00:38:49 +00:00
Richard Smith 9ec1e48b59 PR12226: don't generate wrong code if a braced string literal is used to
initialize an array of unsigned char. Outside C++11 mode, this bug was benign,
and just resulted in us emitting a constant which was double the required
length, padded with 0s. In C++11, it resulted in us generating an array whose
first element was something like  i8 ptrtoint ([n x i8]* @str to i8).

llvm-svn: 154756
2012-04-15 02:50:59 +00:00
Richard Smith ac2f0b1f91 Allow vectors to be constructed from constexpr function arguments in
constant expressions.

llvm-svn: 152665
2012-03-13 20:58:32 +00:00
Nico Weber ccec40d9b7 Add -Wstring-plus-int, which warns on "str" + int and int + "str".
It doesn't warn if the integer is known at compile time and within
the bounds of the string.

Discussion: http://comments.gmane.org/gmane.comp.compilers.clang.scm/47203
llvm-svn: 151943
2012-03-02 22:01:22 +00:00
Richard Smith 35ecb36fcd Ensure that we instantiate static reference data members of class templates
early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is required, since references are
odr-used whether or not they satisfy the requirements for appearing in a
constant expression.

llvm-svn: 151881
2012-03-02 04:14:40 +00:00
Richard Smith 66c9699ac3 Implement constant expression support for __real__ and __imag__ on lvalue
complex numbers. Treat complex numbers as arrays of the corresponding component
type, in order to make std::complex behave properly if implemented in terms of
_Complex T.

Apparently libstdc++'s std::complex is implemented this way, and we were
rejecting a member like this:

  constexpr double real() { return __real__ val; }

because it was marked constexpr but unable to produce a constant expression.

llvm-svn: 150895
2012-02-18 22:04:06 +00:00
Richard Smith 0dea49e324 Fix a problem in the GCC testsuite, exposed by r150557. Compound literals
are represented as prvalues in C++; don't be fooled into thinking they're
global lvalues.

llvm-svn: 150870
2012-02-18 04:58:18 +00:00
Richard Smith 14a941380a Make sure all remaining parts of the constant evaluator are aware that an array
can be represented by an LValue, and use that to simplify the code a little.

llvm-svn: 150789
2012-02-17 03:35:37 +00:00
Richard Smith 17100bad0a constexpr tidyups:
* Fix bug when determining whether && / || are potential constant expressions
  * Try harder when determining whether ?: is a potential constant expression
  * Produce a diagnostic on sizeof(VLA) to provide a better source location

llvm-svn: 150657
2012-02-16 02:46:34 +00:00
Richard Smith b228a86fcf Implement DR1454. This allows all intermediate results in constant expressions
to be core constant expressions (including pointers and references to
temporaries), and makes constexpr calculations Turing-complete. A Turing machine
simulator is included as a testcase.

This opens up the possibilty of removing CCValue entirely, and removing some
copies from the constant evaluator in the process, but that cleanup is not part
of this change.

llvm-svn: 150557
2012-02-15 02:18:13 +00:00
Richard Smith 5a294e6a2c CWG issue 1405: mutable members are allowed in literal types, but can't undergo
lvalue-to-rvalue conversions in constant expressions.

llvm-svn: 150145
2012-02-09 03:29:58 +00:00
Richard Smith 90cacbbf3e Implement DR1458: Taking the address of an object of incomplete class type is
not a constant expression, because we can't tell whether the complete class type
will have an overloaded operator&.

llvm-svn: 150066
2012-02-08 08:11:33 +00:00
Richard Smith c82fae6070 constexpr: Fix implementation of DR1311: check for volatile qualifiers in
lvalue-to-rvalue conversions on the source type of the conversion, not the
target type (which has them removed for non-class types).

llvm-svn: 149796
2012-02-05 01:23:16 +00:00