[clang] Clang accepts function attributes on lambdas in the wrong place

[usx95]

void foo() {
    auto x = [] [[noreturn]] (int msg) { throw; }; // accepted in wrong place.
    auto y = [](int msg) [[noreturn]] { throw; }; // not accepted in the right place
    auto z = [](int) [[clang::annotate_type("foo")]] {};
}

https://godbolt.org/z/sqnWo4v67

The attributes should be accepted after the parameters in the lambda declarator.
https://timsong-cpp.github.io/cppwp/n4868/expr.prim.lambda#nt:lambda-declarator

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Utkarsh Saxena (usx95)

```cpp void foo() { auto x = [] [[noreturn]] (int msg) { throw; }; // accepted in wrong place. auto y = [](int msg) [[noreturn]] { throw; }; // not accepted in the right place auto z = [](int) [[clang::annotate_type("foo")]] {}; } ``` https://godbolt.org/z/sqnWo4v67

The attributes should be accepted after the parameters in the lambda declarator.
https://timsong-cpp.github.io/cppwp/n4868/expr.prim.lambda#nt:lambda-declarator

[usx95]

I think we do not respect the following for function attributes
An attribute-specifier-seq in a lambda-declarator appertains to the type of the corresponding function call operator or operator template src

We get error that this attr cannot be applied to types.

[cor3ntin]

Per recent wording, the first line is correct.
https://eel.is/c++draft/expr.prim.lambda
https://eel.is/c++draft/expr.prim.lambda#closure-6.sentence-6

I think the second line is also correct
Per the wording you quoted (https://eel.is/c++draft/expr.prim.lambda#closure-6.sentence-5) + https://eel.is/c++draft/dcl.attr.noreturn#1.sentence-3
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2173r1.pdf

@AaronBallman

[AaronBallman]

auto x = [] [[noreturn]] (int msg) { throw; }; is grammatically and semantically correct; the noreturn attribute appertains to the lambda call operator.
auto y = [](int msg) [[noreturn]] { throw; }; is grammatically correct but semantically incorrect; the noreturn is being applied to the function type of the lambda call operator (https://eel.is/c++draft/expr.prim.lambda#closure-6.sentence-5) and noreturn is not allowed to appertain to that (https://eel.is/c++draft/dcl.attr.noreturn#1.sentence-3).
auto z = [](int) [[clang::annotate_type("foo")]] {}; is grammatically and semantically correct; the clang::annotate_type attribute appertains to the function type of the lambda call operator.

Clang's behavior is correct.

[jacobsa]

I filed the Google-internal bug that @usx95 synthesized into this report (thanks!). One relevant thing left out here is that this is all from the point of view of building in C++20 mode, where the grammar unambiguously says that attributes should be accepted only after the parameter list.

I'm not sure what the clang policy is about back-porting changes to the grammar, but it's pretty normal for me to see "you can't use that C++23 feature yet" diagnostics, so I was surprised about this one. If the policy is that clang shouldn't accept C++23 grammar in C++20 mode, then there's definitely a bug here.

[zygoloid]

Clang produces a warning by default when using this feature in C++20 mode or earlier, and rejects in -pedantic-errors mode. (Interestingly, GCC silently accepts.) That seems in line with our general policies for back-porting compatible language changes to earlier language versions. If you have a testcase where the warning isn't produced in C++20 mode, that would be a bug.

[jacobsa]

Indeed, sorry for not checking a little more deeply. There are so many flags in the command line we use, I missed this one!

Please ignore my comments then. I think the others were discussing something more substantive.