[clang] Valid constexpr noexcept expression with explicit lambda return type is rejected

[TheAliceBaskerville]

Godbolt Demo

Clang version: 22.0.0git

Reproducer:

clang test.cpp

test.cpp:

template<typename>
constexpr void bar() noexcept([]<typename...>() -> bool { return true; }()) {}

int main() {
    bar<void>();
}

Clang output:

test.cpp:2:31: error: noexcept specifier argument is not a constant expression
    2 | constexpr void bar() noexcept([]<typename...>() -> bool { return true; }()) {}
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test.cpp:2:16: note: in instantiation of exception specification for 'bar<void>' requested here
    2 | constexpr void bar() noexcept([]<typename...>() -> bool { return true; }()) {}
      |                ^
test.cpp:5:5: note: in instantiation of function template specialization 'bar<void>' requested here
    5 |     bar<void>();
      |     ^
test.cpp:2:31: note: undefined function 'operator()<>' cannot be used in a constant expression
    2 | constexpr void bar() noexcept([]<typename...>() -> bool { return true; }()) {}
      |                               ^
test.cpp:2:31: note: declared here

Expected behavior:

Successfully produces essentially empty executable.

Environment:

clang version 22.0.0git (https://github.com/llvm/llvm-project.git 779868de6975f6fd0ea17bb9a8e929037d3752d7)
Target: x86_64-w64-windows-gnu
Thread model: posix

Notes:

Removing -> bool results in successful compilation:

template<typename>
constexpr void bar() noexcept([]<typename...>() /*-> bool*/ { return true; }()) {}

int main() {
    bar<void>();
}

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: TheAliceBaskerville (TheAliceBaskerville)

[Godbolt Demo](https://godbolt.org/z/4x4KEGxeP)

Clang version: 22.0.0git

Reproducer:

clang test.cpp

test.cpp:

template<typename>
constexpr void bar() noexcept([]<typename...>() -> bool { return true; }()) {}

int main() {
    bar<void>();
}

Clang output:

test.cpp:2:31: error: noexcept specifier argument is not a constant expression
    2 | constexpr void bar() noexcept([]<typename...>() -> bool { return true; }()) {}
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test.cpp:2:16: note: in instantiation of exception specification for 'bar<void>' requested here
    2 | constexpr void bar() noexcept([]<typename...>() -> bool { return true; }()) {}
      |                ^
test.cpp:5:5: note: in instantiation of function template specialization 'bar<void>' requested here
    5 |     bar<void>();
      |     ^
test.cpp:2:31: note: undefined function 'operator()<>' cannot be used in a constant expression
    2 | constexpr void bar() noexcept([]<typename...>() -> bool { return true; }()) {}
      |                               ^
test.cpp:2:31: note: declared here

Expected behavior:

Successfully produces essentially empty executable.

Environment:

clang version 22.0.0git (https://github.com/llvm/llvm-project.git 779868de6975f6fd0ea17bb9a8e929037d3752d7)
Target: x86_64-w64-windows-gnu
Thread model: posix

Notes:

Removing -> bool results in successful compilation:

template<typename>
constexpr void bar() noexcept([]<typename...>() /*-> bool*/ { return true; }()) {}

int main() {
    bar<void>();
}

[tbaederr]

Seems like a lambda problem. The NoexceptExpr is:

CXXOperatorCallExpr 0x7e0f6e480838 '_Bool' '()'
|-ImplicitCastExpr 0x7e0f6e4807d8 'auto (*)(void) const -> _Bool' <FunctionToPointerDecay>
| `-DeclRefExpr 0x7e0f6e480710 'auto (void) const -> _Bool' lvalue CXXMethod 0x7e0f6e480600 'operator()' 'auto (void) const -> _Bool'
`-ImplicitCastExpr 0x7e0f6e480818 'const class (lambda at array.cpp:55:31)' lvalue <NoOp>
  `-MaterializeTemporaryExpr 0x7e0f6e4807f8 'class (lambda at array.cpp:55:31)' lvalue
    `-LambdaExpr 0x7e0f6e4803a8 'class (lambda at array.cpp:55:31)'
      |-CXXRecordDecl 0x7e0f6e47f7f0  implicit class definition
      | |-DefinitionData generic lambda pass_in_registers empty standard_layout trivially_copyable trivial literal has_constexpr_non_copy_move_ctor can_const_default_init
      | | |-DefaultConstructor exists trivial constexpr needs_implicit defaulted_is_constexpr
      | | |-CopyConstructor simple trivial has_const_param needs_implicit implicit_has_const_param
      | | |-MoveConstructor exists simple trivial needs_implicit
      | | |-CopyAssignment simple trivial has_const_param needs_implicit implicit_has_const_param
      | | |-MoveAssignment exists simple trivial needs_implicit
      | | `-Destructor simple irrelevant trivial constexpr
      | |-FunctionTemplateDecl 0x7e0f6e47fb08  operator()
      | | |-TemplateTypeParmDecl 0x7e0f6e47fa00  typename depth 0 index 0 ...
      | | |-CXXMethodDecl 0x7e0f6e47f948  constexpr operator() 'auto (void) const -> _Bool' inline
      | | | `-CompoundStmt 0x7e0f6e47fc18
      | | |   `-ReturnStmt 0x7e0f6e47fc00
      | | |     `-CXXBoolLiteralExpr 0x7e0f6e456658 '_Bool' true
      | | `-CXXMethodDecl 0x7e0f6e480600  used constexpr operator() 'auto (void) const -> _Bool' implicit_instantiation inline
      | |   `-TemplateArgument pack '<>'
      | |-FunctionTemplateDecl 0x7e0f6e4801c8  implicit operator bool (*)()
      | | |-TemplateTypeParmDecl 0x7e0f6e47fa00  typename depth 0 index 0 ...
      | | `-CXXConversionDecl 0x7e0f6e480108  implicit constexpr operator bool (*)() 'auto (*(void) const noexcept)(void) -> _Bool' inline
      | |-FunctionTemplateDecl 0x7e0f6e4802f8  implicit __invoke
      | | |-TemplateTypeParmDecl 0x7e0f6e47fa00  typename depth 0 index 0 ...
      | | `-CXXMethodDecl 0x7e0f6e480240  implicit __invoke 'auto (void) -> _Bool' static inline
      | `-CXXDestructorDecl 0x7e0f6e4803e0  implicit referenced constexpr ~(lambda at array.cpp:55:31) 'void (void) noexcept' inline default trivial
      `-CompoundStmt 0x7e0f6e47fc18
        `-ReturnStmt 0x7e0f6e47fc00
          `-CXXBoolLiteralExpr 0x7e0f6e456658 '_Bool' true

so the body is there, but later in CheckConstexprFunction, we have a null definition because FunctionDecl::getBody() returns null (and a null definition). FD is:

CXXMethodDecl 0x7e0f6e480600 <array.cpp:55:52, col:72> col:31 used constexpr operator() 'auto () const -> bool' implicit_instantiation inline
`-TemplateArgument pack '<>'

[TheAliceBaskerville]

I've been experimenting further and found two additional examples that appear to be related to this issue. Both of them crash Clang Front-end:

Example 1 (Godbolt Demo):

a{[]noexcept([]<b>(c){}(0)

Example 2 (Godbolt Demo):

a{[]noexcept([]<b>(c){}({})

Reproducer for both:

clang main.cpp

I'm not entirely sure if these are caused by the exact same bug, but they seem very likely related to the original problem. I've attached the preprocessed sources and associated run scripts for both of them (report.zip), hope that helps.

[safocl]

template<typename>
constexpr void bar() noexcept([]<typename...>() -> auto  { return true; }()) {}

this is well-formed with trailing-return-type as auto
https://godbolt.org/z/hvdxWY46e

[TheAliceBaskerville]

Code in question is well-formed according to ISO/IEC 14882:2020.

[expr.prim.lambda.general] §7.5.5.1 defines a lambda expression by the grammar at the very beginning of the section:

lambda-expression:
    lambda-introducer lambda-declarator(opt) compound-statement
    lambda-introducer < template-parameter-list > requires-clause(opt) lambda-declarator(opt) compound-statement
lambda-introducer:
    [ lambda-capture(opt) ]
lambda-declarator:
    ( parameter-declaration-clause ) decl-specifier-seq(opt)
        noexcept-specifier(opt) attribute-specifier-seq(opt) trailing-return-type(opt) requires-clause(opt)

According to these definitions, the lambda expression in code in question is []<typename...>() -> bool { return true; }.
Its lambda-introducer is []; per definition of the lambda_introducer, the lambda-capture is omitted; the template-parameter-list is typename..., the requires-clause is omitted. The () -> bool is the lambda-declarator, per definition of which, the parameter-declaration-clause is empty, and decl-specifier-seq, noexcept-specifier, attribute-specifier-seq and requires-clause are omitted. Lastly, the trailing-return-type is -> bool and { return true; } is the compound-statement.

[expr.prim.lambda.general] §7.5.5.1/5: "A lambda is a generic lambda if the lambda-expression has any generic parameter type placeholders (9.2.9.6), or if the lambda has a template-parameter-list."

Since the lambda-expression in the code in question has a template-parameter-list, it is a generic lambda.

[expr.prim.lambda.general] §7.5.5.1/4: "The lambda return type is auto, which is replaced by the type specified by the trailing-return-type if provided and/or deduced from return statements as described in 9.2.9.6."

Since a trailing-return-type is provided, the return type of the lambda in code in question is bool. As the return type contains no placeholder-type-specifier, no deduction from return statements occurs.

Concluding the provided citations, the lambda-expression in code in question is well-formed.

[expr.prim.lambda.general] §7.5.5.1/2: "A lambda-expression is a prvalue whose result object is called the closure object.

Since the lambda-expression is well-formed, it yields a closure object.

[expr.prim.lambda.closure] §7.5.5.2/3: "The closure type for a lambda-expression has a public inline function call operator (for a non-generic lambda) or function call operator template (for a generic lambda) (12.6.4) whose parameters and return type are described by the lambda-expression's parameter-declaration-clause and trailing-return-type respectively, and whose template-parameter-list consists of the specified template-parameter-list, if any."

Because the lambda-expression in question is generic lambda, its closure type has a public inline function call operator template. Since parameter-declaration-clause in lambda-expression is empty and trailing-return-type is -> bool, closure type's public inline function call operator template takes no parameters and has a return defined by the trailing-return-type. It's template-parameter-list is typename..., which is a template parameter pack ([temp.variadic] §13.7.4/1).

[expr.prim.lambda.closure] §7.5.5.2/4: "The function call operator or any given operator template specialization is a constexpr function if either the corresponding lambda-expression's parameter-declaration-clause is followed by constexpr or consteval, or it satisfies the requirements for a constexpr function (9.2.6)."
[dcl.constexpr] §9.2.6/3: "The definition of a constexpr function shall satisfy the following requirements:
(3.1) — its return type (if any) shall be a literal type;
(3.2) — each of its parameter types shall be a literal type;
(3.3) — it shall not be a coroutine (9.5.4);
(3.4) — if the function is a constructor or destructor, its class shall not have any virtual base classes;
(3.5) — its function-body shall not enclose (8.1)
(3.5.1) — a goto statement,
(3.5.2) — an identifier label (8.2),
(3.5.3) — a definition of a variable of non-literal type or of static or thread storage duration."

The closure type's function call operator template satisfies all requirements for a constexpr function:

• (3.1) is satisfied since bool is a fundamental type ([basic.fundamental] §6.8.2/10, §6.8.2/15);
• (3.2) is satisfied as there are no parameters;
• (3.3) is satisfied since { return true; } is not a coroutine ([dcl.fct.def.coroutine] §9.5.4/1);
• (3.4) is satisfied because it is an operator, not a constructor or destructor;
• (3.5.1)–(3.5.3) are satisfied as the function body of the operator contains no goto, identifier labels, or variable definitions.

Thus, the closure type's function call operator template is a constexpr function template returning bool.

In the code in question, the lambda-expression is followed by (), which calls the closure type's function call operator.
Since this operator is a function call operator template, a template instantiation is performed.

[temp.arg.explicit] §13.10.2/3: "A template argument list may be specified when referring to a specialization of a function template
(3.1) — when a function is called,
(3.2) — when the address of a function is taken, when a function initializes a reference to function, or when a pointer to member function is formed,
(3.3) — in an explicit specialization,
(3.4) — in an explicit instantiation, or
(3.5) — in a friend declaration."
[temp.arg.explicit] §13.10.2/4: "Trailing template arguments that can be deduced (13.10.3) or obtained from default template-arguments may be omitted from the list of explicit template-arguments. A trailing template parameter pack (13.7.4) not otherwise deduced will be deduced as an empty sequence of template arguments. If all of the template arguments can be deduced, they may all be omitted; in this case, the empty template argument list <> itself may also be omitted."

Accordingly, omission of explicit template arguments and empty template argument list results in deduction. Since the template-parameter-list of this function call operator template is template parameter pack, and since there are no function parameters to deduce from, the pack is deduced as an empty sequence of template arguments.

Concluding the provided citations, the call to the closure type's function call operator template is well-formed, with its template parameter pack deduced to empty pack. Hence, the diagnostic issued by Clang is incorrect.

Proving that the remaining code in question is well-formed is trivial.