[clang] [Clang][Sema] Fix lambdas mistakenly inheriting InImmediateFunctionContext (PR #232458)
Ferdinand Bachmann via cfe-commits
cfe-commits at lists.llvm.org
Sat Oct 17 01:43:07 PDT 2026
Ferdi265 wrote:
> I suspect the handling for non-call-operator methods on lambdas isn't what we want.
>
> Defaulted special member functions are automatically immediate-escalating. That implicitly everything except the lambdas's conversion operator, I think. Probably the conversion operator should also be immediate-escalating. (I think this is a gap in the standard: the standard says the function F is immediate if the call operator is immediate, but it doesn't mention anything about the conversion operator itself.)
>
> Example:
>
> ```
> auto a = []consteval{return 3;};
> constexpr auto b = (+a)();
> ```
you're right, I was thinking there is some case not covered here, thanks for the example.
[\[expr.const.imm\]/3](https://eel.is/c++draft/expr.const.imm#3) defines an immediate-escalating function as either a lambda call operator, a non-user-provided defaulted function (that isn't already `consteval`), or a function that results from the instantiation of a templated entity defined with `constexpr` (that isn't a prospective destructor).
>From the letter of that that doesn't cover the conversion operator from [\[expr.prim.lambda.closure\]/11](https://eel.is/c++draft/expr.prim.lambda#closure-11), since it is neither a template declared `constexpr` nor a non-user-provided defaulted function. It is simply defined to exist as a 'normal' member function by the standard.
I agree that this only makes sense if the conversion operator should also be immediate if the call operator is immediate. Otherwise the conversion operator of an immediate lambda would be uncallable in any context, right?
https://github.com/llvm/llvm-project/pull/232458
More information about the cfe-commits
mailing list