This is an archive of the discontinued LLVM Phabricator instance.

[cxx1z-constexpr-lambda] Make conversion function constexpr
AbandonedPublic

Authored by faisalv on Mar 27 2016, 10:22 PM.

Details

Reviewers
rsmith
Summary

Mark the lambda's conversion to function-pointer as incontrovertibly constexpr.

auto L = [](auto a) { return a; };
constexpr int* (*fp)(int*) = L; // This is now allowed.

By itself this is not terribly useful. A subsequent patch will enable a call through the function pointer in a constant expression if the lambda's synthesized call operator is constexpr.

Diff Detail

Event Timeline

faisalv updated this revision to Diff 51770.Mar 27 2016, 10:22 PM
faisalv retitled this revision from to [cxx1z-constexpr-lambda] Make conversion function constexpr.
faisalv updated this object.
faisalv added a reviewer: rsmith.
faisalv added a subscriber: cfe-commits.
faisalv updated this revision to Diff 62814.Jul 5 2016, 7:32 PM
faisalv updated this object.

Mark the lambda's conversion to function-pointer as incontrovertibly constexpr.

auto L = [](auto a) { return a; };
constexpr int* (*fp)(int*) = L; // This is now allowed.

Instead of inserting the extension/compatibility-warning into the same list that houses the notes that identify errors that occurred during constant-folding (and subsequently modifying the logic to ignore such warnings when determining the result of constant folding), I resorted to the simple approach used to emit a warning for integer-overflow (during constant folding) by invoking getDiagnostics().Report.

Richard I hope you're OK with this approach - I know in Oulu I was leaning towards inserting the warning into the same list that houses the error-notes (or potentially creating another one, or having EvalInfo track whether an error-note truly occurred instead of relying simply on the size of the list) - and while doable (and potentially cleaner) - that change is a larger one that requires handing some subtleties, and can be done at a later time, if you feel strongly about it.

rsmith edited edge metadata.Jul 14 2016, 5:08 PM

I don't see how this approach can work; the fact that we happened to ask the expression evaluator to evaluate an expression is not sufficient reason for us to issue this warning. For instance:

auto a = []{};
void (*p)() = a;

... will ask the evaluator to evaluate the initializer of p, which it appears will now generate a bogus extension warning in C++11 and C++14 mode.

If you want to carry on down this path, I think you will need to do something similar to what we discussed at Oulu, but I expect getting a correct warning to be complex and difficult, so I think the best approach would be to give up on this compat warning / extension, and instead only turn on the constexpr flag in C++17 mode. We could burn a lot of time getting this compatibility warning / extwarn to work, and it seems better to make progress on the rest of the constexpr lambdas feature instead :)

faisalv abandoned this revision.Jan 8 2017, 11:13 AM

See richard's comment for why this attempt at implementing a compatibility warning for the constexpr conversion operator for lambda's is being abandoned.