Incorrect mention of 'alignof' in a diagnostic about 'alignas'

[int6]

% cat main.cpp
class alignas(void) Bar {};

➜  test ../build/debug/bin/clang++ -std=c++11 ./alignas.cpp
./alignas.cpp:1:15: error: invalid application of 'alignof' to an incomplete type 'void'
class alignas(void) A {};
             ~^~~~~
1 error generated.

Should 'alignof' in the first diagnostic message be replaced with 'alignas'? Although alignas equivalent to alignas(alignof(type)).

[AaronBallman]

The trouble is this bit: https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L2882

When parsing the alignment argument for alignas and given a parenthesized type, we process it how the standard specifies by parsing it as an alignof expression (http://eel.is/c++draft/dcl.attr#dcl.align-3), but we have no way to tell Sema that the type trait we're actually after is alignas instead. Thus, we complain about the invalid alignof incorrectly.

Making alignas into an actual type trait would be possible but a bit novel (it's not a unary expression or a type trait, it's an attribute). Threading through "hey, you're building an alignas expression" also doesn't seem particularly clean. I think it might be that the correct approach here is to lift the logic out of ActOnUnaryExprOrTypeTraitExpr() into a new ActOnAlignasTypeArgument() function or somesuch.

[int6]

The trouble is this bit: https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L2882

When parsing the alignment argument for alignas and given a parenthesized type, we process it how the standard specifies by parsing it as an alignof expression (http://eel.is/c++draft/dcl.attr#dcl.align-3), but we have no way to tell Sema that the type trait we're actually after is alignas instead. Thus, we complain about the invalid alignof incorrectly.

Making alignas into an actual type trait would be possible but a bit novel (it's not a unary expression or a type trait, it's an attribute). Threading through "hey, you're building an alignas expression" also doesn't seem particularly clean. I think it might be that the correct approach here is to lift the logic out of ActOnUnaryExprOrTypeTraitExpr() into a new ActOnAlignasTypeArgument() function or somesuch.

Thanks for your reply and suggestion aaron, I'll try to understand this part and I'd be happy to do something about it

[yronglin]

Fixed by f75b735