Commit Graph

9 Commits

Author SHA1 Message Date
Richard Smith 1861ddfab1 PR37450: Fix bug that disabled some type checks for variables with deduced types.
Also improve diagnostic for the case where a type is non-literal because it's a lambda.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332286 91177308-0d34-0410-b5e6-96231b3b80d8
2018-05-14 20:15:04 +00:00
Erik Pilkington 6137fb61ce [AST] Don't track lambda captures when checking a potential constant expression.
Fixes PR36054.

Differential revision: https://reviews.llvm.org/D45194

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@329244 91177308-0d34-0410-b5e6-96231b3b80d8
2018-04-05 00:12:05 +00:00
Faisal Vali 65db7256b9 [cxx1z-constexpr-lambda] Implement captures - thus completing implementation of constexpr lambdas.
Enable evaluation of captures within constexpr lambdas by using a strategy similar to that used in CodeGen:
  - when starting evaluation of a lambda's call operator, create a map from VarDecl's to a closure's FieldDecls
  - every time a VarDecl (or '*this) that represents a capture is encountered while evaluating the expression via the expression evaluator (specifically the LValueEvaluator) in ExprConstant.cpp - it is replaced by the corresponding FieldDecl LValue (an Lvalue-to-Rvalue conversion on this LValue representation then determines the right rvalue when needed).

Thanks to Richard Smith and Hubert Tong for their review and feedback!

https://reviews.llvm.org/D29748



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295279 91177308-0d34-0410-b5e6-96231b3b80d8
2017-02-16 04:12:21 +00:00
Faisal Vali 25f75c4838 [cxx1z-constexpr-lambda] Implement constant evaluation of non-capturing lambda expressions.
Add a visitor for lambda expressions to RecordExprEvaluator in ExprConstant.cpp that creates an empty APValue of Struct type to represent the closure object. Additionally, add a LambdaExpr visitor to the TemporaryExprEvaluator that forwards constant evaluation of immediately-called-lambda-expressions to the one in RecordExprEvaluator through VisitConstructExpr.

This patch supports:
constexpr auto ID = [] (auto a) { return a; };
static_assert(ID(3.14) == 3.14);
static_assert([](auto a) { return a + 1; }(10) == 11);

Lambda captures are still not supported for constexpr lambdas.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291416 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-09 03:02:53 +00:00
Faisal Vali 81f1ca9eab [cxx1z-constexpr-lambda] Make conversion function constexpr, and teach the expression-evaluator to evaluate the static-invoker.
This patch has been sitting in review hell since july 2016 and our lack of constexpr lambda support is getting embarrassing (given that I've had a branch that implements the feature (modulo *this capture) for over a year.  While in Issaquah I was enjoying shamelessly trying to convince folks of the lie that this was Richard's fault ;) I won't be able to do so in Kona since I won't be attending - so I'm going to aim to have this feature be implemented by then.

I'm quite confident of the approach in this patch, which simply maps the static-invoker 'thunk' back to the corresponding call-operator (specialization).

Thanks!



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291397 91177308-0d34-0410-b5e6-96231b3b80d8
2017-01-08 18:56:11 +00:00
Faisal Vali e3fbde7486 Fix PR28366: Handle variables from enclosing local scopes more gracefully during constant expression evaluation.
Only look for a variable's value in the constant expression evaluation activation frame, if the variable was indeed declared in that frame, otherwise it might be a constant expression and be usable within a nested local scope or emit an error.


void f(char c) { 
  struct X {
    static constexpr char f() { 
      return c; // error gracefully here as opposed to crashing.
    }
  };
  int I = X::f();
}



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286748 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-13 06:09:16 +00:00
Faisal Vali 1543986483 [NFC] Rearrange an example-file so the c++14 specific example is on top.
This makes it easier to add C++1z examples to the bottom, just before the #endif.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@277287 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-31 01:19:17 +00:00
Faisal Vali 816893384b [cxx1z-constexpr-lambda] Make a lambda's closure type eligible as a literal-type in C++1z
Additionally, for pre-C++1z, instead of forbidding a lambda's closure type from being a literal type through circumlocutorily setting HasNonLiteralTypeFieldsOrBases falsely to true -- handle lambda's more directly in CXXRecordDecl::isLiteral().

One additional small step towards implementing constexpr-lambdas.

Thanks to Richard Smith for his review! 
https://reviews.llvm.org/D22662



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276514 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-23 04:05:19 +00:00
Faisal Vali a46d5cd16e [Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier (and its inference) on lambda expressions
Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body.

i.e.
  auto L = [] () constexpr { return 5; };
  static_assert(L() == 5); // OK
  auto Implicit = [] (auto a) { return a; };
  static_assert(Implicit(5) == 5); 

We do not support evaluation of lambda's within constant expressions just yet.

Implementation Strategy:
  - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location.
  - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body.

Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264513 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-26 16:11:37 +00:00