Commit Graph

1013 Commits

Author SHA1 Message Date
Douglas Gregor 621003e7b9 Check the return type of lambda expressions.
llvm-svn: 150503
2012-02-14 21:20:44 +00:00
Douglas Gregor 3e308b1fba Implement support for lambda capture pack expansions, e.g.,
[&values...] { print(values...); }

llvm-svn: 150497
2012-02-14 19:27:52 +00:00
Douglas Gregor 1b66d8c287 Simple test ensuring that we perform direct initialization when copy-capturing in lambdas
llvm-svn: 150442
2012-02-14 00:03:38 +00:00
Douglas Gregor b4328233c1 Link together the call operator produced from transforming a lambda
expression with the original call operator, so that we don't try to
separately instantiate the call operator. Test and tweak a few more
bits for template instantiation of lambda expressions.

llvm-svn: 150440
2012-02-14 00:00:48 +00:00
Richard Smith 6331c408b5 Deal with a horrible C++11 special case. If a non-literal type has a constexpr
constructor, and that constructor is used to initialize an object of static
storage duration such that all members and bases are initialized by constant
expressions, constant initialization is performed. In this case, the object
can still have a non-trivial destructor, and if it does, we must emit a dynamic
initializer which performs no initialization and instead simply registers that
destructor.

llvm-svn: 150419
2012-02-13 22:16:19 +00:00
Douglas Gregor 0c46b2b7ce Introduce support for template instantiation of lambda
expressions. This is mostly a simple refact, splitting the main "start
a lambda expression" function into smaller chunks that are driven
either from the parser (Sema::ActOnLambdaExpr) or during AST
transformation (TreeTransform::TransformLambdaExpr). A few minor
interesting points:

  - Added new entry points for TreeTransform, so that we can
  explicitly establish the link between the lambda closure type in the
  template and the lambda closure type in the instantiation.
  - Added a bit into LambdaExpr specifying whether it had an explicit
  result type or not. We should have had this anyway.

This code is 'lightly' tested.

llvm-svn: 150417
2012-02-13 22:00:16 +00:00
Richard Smith 3607ffee5c Update constexpr implementation to match CWG's chosen approach for core issues
1358, 1360, 1452 and 1453.
 - Instantiations of constexpr functions are always constexpr. This removes the
   need for separate declaration/definition checking, which is now gone.
 - This makes it possible for a constexpr function to be virtual, if they are
   only dependently virtual. Virtual calls to such functions are not constant
   expressions.
 - Likewise, it's now possible for a literal type to have virtual base classes.
   A constexpr constructor for such a type cannot actually produce a constant
   expression, though, so add a special-case diagnostic for a constructor call
   to such a type rather than trying to evaluate it.
 - Classes with trivial default constructors (for which value initialization can
   produce a fully-initialized value) are considered literal types.
 - Classes with volatile members are not literal types.
 - constexpr constructors can be members of non-literal types. We do not yet use
   static initialization for global objects constructed in this way.

llvm-svn: 150359
2012-02-13 03:54:03 +00:00
Douglas Gregor e096a35518 Implement the standard decltype() semantics described in C++11
[dcl.type.simple]p4, which treats all xvalues as returning T&&. We had
previously implemented a pre-standard variant of decltype() that
doesn't cope with, e.g., static_ast<T&&>(e) very well.

llvm-svn: 150348
2012-02-12 18:57:57 +00:00
Douglas Gregor 81495f341d Within the body of a lambda expression, decltype((x)) for an
id-expression 'x' will compute the type based on the assumption that
'x' will be captured, even if it isn't captured, per C++11
[expr.prim.lambda]p18. There are two related refactors that go into
implementing this:

  1) Split out the check that determines whether we should capture a
  particular variable reference, along with the computation of the
  type of the field, from the actual act of capturing the
  variable. 
  2) Always compute the result of decltype() within Sema, rather than
  AST, because the decltype() computation is now context-sensitive.

llvm-svn: 150347
2012-02-12 18:42:33 +00:00
Douglas Gregor 1a22d2889b Lambdas have a deleted default constructor and a deleted copy
assignment operator, per C++ [expr.prim.lambda]p19. Make it so.

llvm-svn: 150345
2012-02-12 17:34:23 +00:00
Sebastian Redl a935179ab7 Represent C++ direct initializers as ParenListExprs before semantic analysis
instead of having a special-purpose function.

- ActOnCXXDirectInitializer, which was mostly duplication of
  AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
  ago), is dropped completely.
- MultiInitializer, which was an ugly hack I added, is dropped again.
- We now have the infrastructure in place to distinguish between
  int x = {1};
  int x({1});
  int x{1};
-- VarDecl now has getInitStyle(), which indicates which of the above was used.
-- CXXConstructExpr now has a flag to indicate that it represents list-
   initialization, although this is not yet used.
- InstantiateInitializer was renamed to SubstInitializer and simplified.
- ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
  always produces a ParenListExpr. Placed that so far failed to convert that
  back to a ParenExpr containing comma operators have been fixed. I'm pretty
  sure I could have made a crashing test case before this.

The end result is a (I hope) considerably cleaner design of initializers.
More importantly, the fact that I can now distinguish between the various
initialization kinds means that I can get the tricky generalized initializer
test cases Johannes Schaub supplied to work. (This is not yet done.)

This commit passed self-host, with the resulting compiler passing the tests. I
hope it doesn't break more complicated code. It's a pretty big change, but one
that I feel is necessary.

llvm-svn: 150318
2012-02-11 23:51:47 +00:00
Eli Friedman c9751069f5 Make sure Sema creates a field for 'this' captures. (Doug, please double-check that this is correct.)
llvm-svn: 150292
2012-02-11 02:51:16 +00:00
Douglas Gregor 28be7c5e20 Add simple semantic test for C++11 [expr.prim.lambda]p16, which covers recursive capture. This is far more interesting for IRgen.
llvm-svn: 150283
2012-02-10 23:38:02 +00:00
Douglas Gregor f0d495100c Implement C++11 [expr.lambda.prim]p13, which prohibits lambdas in
default arguments if in fact those lambdas capture any entity.

llvm-svn: 150282
2012-02-10 23:30:22 +00:00
Douglas Gregor a1bffa26ca Allow implicit capture of 'this' in a lambda even when the capture
default is '=', and reword the warning about explicitly capturing
'this' in such lambdas to indicate that only explicit capture is
banned. 

Introduce Fix-Its for this and other "save the programmer from
themself" rules regarding what can be explicitly captured and what
must be implicitly captured.

llvm-svn: 150256
2012-02-10 17:46:20 +00:00
Douglas Gregor 01db64f0ac Add test from [expr.prim.lambda]p12, which deals with odr-use and
nested captures. We currently don't get odr-use correct in array
bounds, so that bit is commented out while we sort out what we need to
do.

llvm-svn: 150255
2012-02-10 16:48:36 +00:00
Douglas Gregor 04bbab586b Don't introduce a lambda's operator() into the class until after we
have finished parsing the body, so that name lookup will never find
anything within the closure type. Then, add this operator() and the
conversion function (if available) before completing the class.

llvm-svn: 150252
2012-02-10 16:13:20 +00:00
Richard Smith 63168c7533 PR11684, core issue 1417:
o Correct the handling of the restrictions on usage of cv-qualified and
  ref-qualified function types.
o Fix a bug where such types were rejected in template type parameter default
  arguments, due to such arguments not being treated as a template type arg
  context.
o Remove the ExtWarn for usage of such types as template arguments; that was
  a standard defect, not a GCC extension.
o Improve the wording and unify the code for diagnosing cv-qualifiers with the
  code for diagnosing ref-qualifiers.

llvm-svn: 150244
2012-02-10 11:05:11 +00:00
Douglas Gregor 136b2f24f0 Add a lambda example from the working draft.
llvm-svn: 150239
2012-02-10 09:37:05 +00:00
Douglas Gregor f02455e5ee Add various tests for captures and the reaching scope of the lambda
expression. Implement C++11 [expr.prim.lambda]p12's requirement that
capturing a variable will odr-use it.

llvm-svn: 150237
2012-02-10 09:26:04 +00:00
Douglas Gregor 12695101ec Implement the conversion to a function pointer for lambda expressions,
per C++ [expr.prim.lambda]p6.

llvm-svn: 150236
2012-02-10 08:36:38 +00:00
Richard Smith 0cd4ab194b Update to new resolution for DR1458. When taking the address of an object of
incomplete class type which has an overloaded operator&, it's now just
unspecified whether the overloaded operator or the builtin is used.

llvm-svn: 150234
2012-02-10 07:41:06 +00:00
Douglas Gregor 940a550f0d Don't allow deduction of a lambda result type from an initializer
list; it is not an expression.

llvm-svn: 150194
2012-02-09 18:40:39 +00:00
Douglas Gregor a30a0bc1db Tests for C++ [expr.prim.lambda]p5. We already implement all of these
semantics. 

llvm-svn: 150190
2012-02-09 18:19:44 +00:00
Douglas Gregor 7345626a5b Implement return type deduction for lambdas per C++11
[expr.prim.lambda]p4, including the current suggested resolution of
core isue 975, which allows multiple return statements so long as the
types match. ExtWarn when user code is actually making use of this
extension.

llvm-svn: 150168
2012-02-09 10:18:50 +00:00
Douglas Gregor 656bc62a73 Remove the "unsupported" error for lambda expressions. It's annoying,
and rapidly becoming untrue.

llvm-svn: 150165
2012-02-09 08:26:42 +00:00
Douglas Gregor 291af2b7e6 Add a test for the non-aggregaticity of lambda types per C++11
[expr.prim.lambda].

llvm-svn: 150164
2012-02-09 08:15:36 +00:00
Douglas Gregor 8962549164 Implement C++ [expr.prim.lambda]p2, which bans lambda expressions in
unevaluated operands. Be certain that we're marking everything
referenced within a capture initializer as odr-used.

llvm-svn: 150163
2012-02-09 08:14:43 +00:00
Richard Smith 4d59eebb49 DR1359: A constexpr constructor does not need to initialize an empty struct or
empty union. This still rejects anonymous member structs or unions which only
contain such empty class types, pending standard wording defining exactly what
an empty class type is.

llvm-svn: 150157
2012-02-09 06:40:58 +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
Douglas Gregor 199cec7673 Implement capture-by-copy for arrays in lambdas.
llvm-svn: 150138
2012-02-09 02:45:47 +00:00
Douglas Gregor 3d23f78852 When we create a non-static data member in the closure object for a
capture, make sure we actually add the field.

llvm-svn: 150135
2012-02-09 02:12:34 +00:00
Douglas Gregor 8c50e7c5e3 Various interrelated cleanups for lambdas:
- Complete the lambda class when we finish the lambda expression
    (previously, it was left in the "being completed" state)
  - Actually return the LambdaExpr object and bind to the resulting
  temporary when needed.
  - Detect when cleanups are needed while capturing a variable into a
  lambda (e.g., due to default arguments in the copy constructor), and
  make sure those cleanups apply for the whole of the lambda
  expression.
    

llvm-svn: 150123
2012-02-09 00:47:04 +00:00
Douglas Gregor 8390afde4e Minor comment fix
llvm-svn: 150090
2012-02-08 21:19:04 +00:00
Douglas Gregor c70fe353ea When computing the type of a local variable reference within a lambda,
only add 'const' for variables captured by copy in potentially
evaluated expressions of non-mutable lambdas. (The "by copy" part was
missing).

llvm-svn: 150088
2012-02-08 20:56:50 +00:00
Douglas Gregor 21f4692c62 When completing a lambda expression, make sure to check and attach the
body of the lambda to the function call operator.

llvm-svn: 150087
2012-02-08 20:17:14 +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 3c7ad4e01b Add more testing for r149776.
llvm-svn: 150061
2012-02-08 06:41:34 +00:00
Richard Smith da7c4ba1af Implement the agreed resolution to DR1457: a signed left shift of a 1 bit into
the sign bit doesn't have undefined behavior, but a signed left shift of a 1 bit
out of the sign bit still does. As promised to Howard :)

The suppression of the potential constant expression checking in system headers
is also removed, since the problem it was working around is gone.

llvm-svn: 150059
2012-02-08 06:14:53 +00:00
Douglas Gregor e31e606ff3 Introduce basic ASTs for lambda expressions. This covers:
- Capturing variables by-reference and by-copy within a lambda
  - The representation of lambda captures
  - The creation of the non-static data members in the lambda class
  that store the captured variables
  - The initialization of the non-static data members from the
  captured variables
  - Pretty-printing lambda expressions

There are a number of FIXMEs, both explicit and implied, including:
  - Creating a field for a capture of 'this'
  - Improved diagnostics for initialization failures when capturing
  variables by copy
  - Dealing with temporaries created during said initialization
  - Template instantiation
  - AST (de-)serialization
  - Binding and returning the lambda expression; turning it into a
  proper temporary
  - Lots and lots of semantic constraints
  - Parameter pack captures

llvm-svn: 149977
2012-02-07 10:09:13 +00:00
Eli Friedman dd053f6fba Misc improvements to the diagnostic when a variable is odr-used in a context that is not allowed to capture variables.
Fixes PR11883.

llvm-svn: 149937
2012-02-07 00:15:00 +00:00
Richard Smith 2de5a939e2 constexpr: Implement DR1358: An instantiation of a constexpr function which
can't produce a constant expression is not ill-formed (so long as some
instantiation of that function can produce a constant expression).

llvm-svn: 149802
2012-02-05 02:30:54 +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
Richard Smith f4c51d9d76 In C++11 mode, when an integral constant expression is desired and we have a
value of class type, look for a unique conversion operator converting to
integral or unscoped enumeration type and use that. Implements [expr.const]p5.

Sema::VerifyIntegerConstantExpression now performs the conversion and returns
the converted result. Some important callers of Expr::isIntegralConstantExpr
have been switched over to using it (including all of those required for C++11
conformance); this switch brings a side-benefit of improved diagnostics and, in
several cases, simpler code. However, some language extensions and attributes
have not been moved across and will not perform implicit conversions on
constant expressions of literal class type where an ICE is required.

In passing, fix static_assert to perform a contextual conversion to bool on its
argument.

llvm-svn: 149776
2012-02-04 09:53:13 +00:00
Richard Smith 3f333f2edf Disallow constexpr main.
llvm-svn: 149770
2012-02-04 06:10:17 +00:00
Eli Friedman 24af850470 Implement implicit capture for lambda expressions.
Still left: explicit captures in lambdas need to cause implicit capture, and I need to take a look at the diagnostics for some cases.

llvm-svn: 149718
2012-02-03 22:47:37 +00:00
Douglas Gregor 1f79ca839c When a pack expansion occurs in the template argument list of an alias
template without a corresponding parameter pack, don't immediately
substitute the alias template. This is under discussion in the C++
committee, and may become ill-formed, but for now we match GCC.

llvm-svn: 149697
2012-02-03 17:16:23 +00:00
Douglas Gregor 8e07261362 Implement support for a pack expansion into a fixed-length
template. Such pack expansions can easily fail at template
instantiation time, if the expanded parameter packs are of the wrong
length. Fixes <rdar://problem/10040867>, PR9021, and the example that
came up today at Going Native.

llvm-svn: 149685
2012-02-03 07:34:46 +00:00
Richard Smith 84f6dcf2b5 constexpr:
* support the gcc __builtin_constant_p() ? ... : ... folding hack in C++11
  * check for unspecified values in pointer comparisons and pointer subtractions

llvm-svn: 149578
2012-02-02 01:16:57 +00:00
Douglas Gregor 6b8ef34f84 Diagnose the restriction on default arguments in C++11 [expr.prim.lambda]p5.
llvm-svn: 149517
2012-02-01 17:18:19 +00:00