[all-commits] [llvm/llvm-project] 8a5458: [C23] Fix typeof handling in enum declarations (#1...

[Aaron Ballman via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8a5458c79ac71fa1628b1b78de188a9f5598fbeb
      https://github.com/llvm/llvm-project/commit/8a5458c79ac71fa1628b1b78de188a9f5598fbeb
  Author: Aaron Ballman <aaron at aaronballman.com>
  Date:   2025-07-07 (Mon, 07 Jul 2025)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/include/clang/Parse/Parser.h
    M clang/lib/Parse/ParseExpr.cpp
    M clang/lib/Parse/ParseExprCXX.cpp
    M clang/lib/Parse/ParseOpenMP.cpp
    M clang/lib/Parse/ParseTemplate.cpp
    M clang/lib/Parse/Parser.cpp
    A clang/test/Parser/c23-typeof.m
    M clang/test/Parser/c2x-typeof.c

  Log Message:
  -----------
  [C23] Fix typeof handling in enum declarations (#146394)

We have a parsing helper function which parses either a parenthesized
expression or a parenthesized type name. This is used when parsing a
unary operator such as sizeof, for example.

The problem this solves is when that construct is ambiguous. Consider:

	enum E : typeof(int) { F };

After we've parsed the 'typeof', what ParseParenExpression() is
responsible for is '(int) { F }' which looks like a compound literal
expression when it's actually the parens and operand for 'typeof'
followed by the enumerator list for the enumeration declaration. Then
consider:

	sizeof (int){ 0 };

After we've parsed 'sizeof', ParseParenExpression is responsible for
parsing something grammatically similar to the problematic case.

The solution is to recognize that the expression form of 'typeof' is
required to have parentheses. So we know the open and close parens that
ParseParenExpression handles must be part of the grammar production for
the operator, not part of the operand expression itself.

Fixes #146351



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications