The overloadable attribute is sensitive to the syntactic position of the attribute

[AaronBallman]

Consider:

__attribute__((overloadable)) void func_bad(...); // error

void func_good(...) __attribute__((overloadable)); // okay

[[clang::overloadable]] void func_also_bad(...); // error
void func_also_bad_again(...) [[clang::overloadable]]; // error, this is the only diagnostic that makes sense to me

void okay_now_Im_just_baffled [[clang::overloadable]](...); // okay

The only diagnostic that makes sense (to me) is the one on func_also_bad_again() due to it being written in the type position and not being a type attribute.

https://godbolt.org/z/7qWjWdbGP is a live example. I think the two cases labeled error with no other comments should also be accepted.

[llvmbot]

@llvm/issue-subscribers-c

[AaronBallman]

https://reviews.llvm.org/D119664 should address this

[AaronBallman]

Fixed in 76032b0.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Aaron Ballman (AaronBallman)

Consider: ``` __attribute__((overloadable)) void func_bad(...); // error

void func_good(...) attribute((overloadable)); // okay

[[clang::overloadable]] void func_also_bad(...); // error
void func_also_bad_again(...) [[clang::overloadable]]; // error, this is the only diagnostic that makes sense to me

void okay_now_Im_just_baffled [clang::overloadable]; // okay

The only diagnostic that makes sense (to me) is the one on `func_also_bad_again()` due to it being written in the type position and not being a type attribute.

https://godbolt.org/z/7qWjWdbGP is a live example. I think the two cases labeled `error` with no other comments should also be accepted.
</details>