[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