[c23] `typeof(type-name)` in enumeration fixed underlying type is broken

[MisterDA]

Setting a typeof(type-name) in an enumeration fixed underlying type is broken: an error is raised explaining that the identifiers are not declared, but we're in the process of declaring them. The bug is present in clang 20.1.0. GCC 15.1 doesn't have this bug.

See C23 6.7.3.6.p4 Typeof specifiers

If the typeof operators are applied to an expression, they yield the type of their operand. Otherwise, they designate the same type as the type name with any nested typeof specifier evaluated.

Interestingly, typeof(expression) isn't broken!

https://gcc.godbolt.org/z/TGWYdhndo

enum e : int {
    E = 0,
};

enum f : typeof(int) {
    F = 0, /* error: use of undeclared identifier 'F' */
};

int g = 0;

enum g : typeof(g) {
    G = 0,
};

int main() {}

<source>:6:5: error: use of undeclared identifier 'F'
    6 |     F = 0,
      |     ^
1 error generated.
Compiler returned: 1

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Antonin Décimo (MisterDA)

Setting a `typeof(type-name)` in an enumeration fixed underlying type is broken: an error is raised explaining that the identifiers are not declared, but we're in the process of declaring them. The bug is present in clang 20.1.0. GCC 15.1 doesn't have this bug.

See C23 6.7.3.6.p4 Typeof specifiers

> If the typeof operators are applied to an expression, they yield the type of their operand. Otherwise, they designate the same type as the type name with any nested typeof specifier evaluated.

Interestingly, typeof(expression) isn't broken!

https://gcc.godbolt.org/z/TGWYdhndo

enum e : int {
    E = 0,
};

enum f : typeof(int) {
    F = 0, /* error: use of undeclared identifier 'F' */
};

int g = 0;

enum g : typeof(g) {
    G = 0,
};

int main() {}

<source>:6:5: error: use of undeclared identifier 'F'
    6 |     F = 0,
      |     ^
1 error generated.
Compiler returned: 1

[AaronBallman]

I've started debugging this a bit and at least part of the issue is that we see typeof(int) { and think it's a compound literal expression when we're parsing the (int) { bit. You can't run into this situation with the other unary expressions because those don't result in a type.

[AaronBallman]

This issue can be traced back for roughly forever: https://godbolt.org/z/cEoqTfG7n

[MisterDA]

Right, IIUC the problem can somewhat be reduced to this example:

// the following (invalid construct)
typeof(int) { 0 } x;
//  should be parsed as (still invalid)
(typeof(int)) { 0 } x;
// but is parsed as
typeof((int) { 0 }) x;

Feel free to rename the bug report as you see fit if needed.