[PATCH] D45194: [Sema] Defer checking constexpr lambda until after we've finished the lambda class.

Faisal Vali via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Apr 4 14:03:38 PDT 2018


faisalv added a comment.

LGTM - can you commit?
Thank you!



================
Comment at: clang/lib/AST/ExprConstant.cpp:4313
+    // We're in a lambda; determine the lambda capture field maps unless we're
+    // just constexpr checking a lambda's call operator. constexpr checking is
+    // done before the captures have been added to the closure object, so we
----------------
should we say something about only explicitly specified constexpr checking (as opposed to constexpr inference) is done prior to capture information being stored in the CXXRecordDecl? *shrug*.

Also the upside of having the expression evaluator evaluate these expressions is we could diagnose such lambdas as ill-formed (though no-diagnostic required per the standard): 
  void f() {
    volatile int v = 1;
    [&] () constexpr { return v; };  // can never be a core constant expression, right?
  }

I think I agree w you though - so, for now lets stick with this version of the patch?


================
Comment at: clang/lib/AST/ExprConstant.cpp:5212
+      cast<DeclRefExpr>(E)->refersToEnclosingVariableOrCapture()) {
+    // We don't track the lambda's captures in a potential constant expression.
+    if (Info.checkingPotentialConstantExpression())
----------------
How about something along the lines of : We don't always have a complete capture-map when checking or inferring if the function call operator meets the requirements of a constexpr function - and we don't need to evaluate the captures to determine constexprness (dcl.constexpr C++17)?


https://reviews.llvm.org/D45194





More information about the cfe-commits mailing list