https://github.com/AaronBallman created
https://github.com/llvm/llvm-project/pull/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
>From 94cd71d65fe27cdde0c39416a0e2e709af98ed0c Mon Sep 17 00:00:00 2001
From: Aaron Ballman <aa...@aaronballman.com>
Date: Mon, 30 Jun 2025 13:26:57 -0400
Subject: [PATCH] [C23] Fix typeof handling in enum declarations
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
---
clang/docs/ReleaseNotes.rst | 2 ++
clang/include/clang/Parse/Parser.h | 8 ++++++-
clang/lib/Parse/ParseExpr.cpp | 34 +++++++++++++++++++++---------
clang/lib/Parse/Parser.cpp | 3 ++-
clang/test/Parser/c2x-typeof.c | 10 +++++++++
5 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 45b5f77545361..1b12061dad85b 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -304,6 +304,8 @@ C23 Feature Support
which clarified how Clang is handling underspecified object declarations.
- Clang now accepts single variadic parameter in type-name. It's a part of
`WG14 N2975 <https://open-std.org/JTC1/SC22/WG14/www/docs/n2975.pdf>`_
+- Fixed a bug with handling the type operand form of ``typeof`` when it is used
+ to specify a fixed underlying type for an enumeration. #GH146351
C11 Feature Support
^^^^^^^^^^^^^^^^^^^
diff --git a/clang/include/clang/Parse/Parser.h
b/clang/include/clang/Parse/Parser.h
index a47e23ffbd357..ced9613b9ab9b 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -4184,7 +4184,12 @@ class Parser : public CodeCompletionHandler {
/// ParseParenExpression - This parses the unit that starts with a '(' token,
/// based on what is allowed by ExprType. The actual thing parsed is
returned
/// in ExprType. If stopIfCastExpr is true, it will only return the parsed
- /// type, not the parsed cast-expression.
+ /// type, not the parsed cast-expression. If ParenKnownToBeNonCast is true,
+ /// the initial open paren and its matching close paren are known to be part
+ /// of another grammar production and not part of the operand. e.g., the
+ /// typeof and typeof_unqual operators in C. If it is false, then the
function
+ /// has to parse the parens to determine whether they're part of a cast or
+ /// compound literal expression rather than a parenthesized type.
///
/// \verbatim
/// primary-expression: [C99 6.5.1]
@@ -4210,6 +4215,7 @@ class Parser : public CodeCompletionHandler {
/// \endverbatim
ExprResult ParseParenExpression(ParenParseOption &ExprType,
bool stopIfCastExpr, bool isTypeCast,
+ bool ParenKnownToBeNonCast,
ParsedType &CastTy,
SourceLocation &RParenLoc);
diff --git a/clang/lib/Parse/ParseExpr.cpp b/clang/lib/Parse/ParseExpr.cpp
index 3cf3d4ea7d705..c6731fca7bfa7 100644
--- a/clang/lib/Parse/ParseExpr.cpp
+++ b/clang/lib/Parse/ParseExpr.cpp
@@ -758,7 +758,8 @@ ExprResult Parser::ParseCastExpression(CastParseKind
ParseKind,
ParsedType CastTy;
SourceLocation RParenLoc;
Res = ParseParenExpression(ParenExprType, false /*stopIfCastExr*/,
- isTypeCast == TypeCastState::IsTypeCast, CastTy,
+ isTypeCast == TypeCastState::IsTypeCast,
+ false /*ParenKnownToBeNonCast*/, CastTy,
RParenLoc);
// FIXME: What should we do if a vector literal is followed by a
@@ -2110,12 +2111,24 @@ Parser::ParseExprAfterUnaryExprOrTypeTrait(const Token
&OpTok,
// If it starts with a '(', we know that it is either a parenthesized
// type-name, or it is a unary-expression that starts with a compound
// literal, or starts with a primary-expression that is a parenthesized
- // expression.
+ // expression. Most unary operators have an expression form without parens
+ // as part of the grammar for the operator, and a type form with the parens
+ // as part of the grammar for the operator. However, typeof and
+ // typeof_unqual require parens for both forms. This means that we *know*
+ // that the open and close parens cannot be part of a cast expression,
+ // which means we definitely are not parsing a compound literal expression.
+ // This disambiguates a case like enum E : typeof(int) { }; where we've
+ // parsed typeof and need to handle the (int){} tokens properly despite
+ // them looking like a compound literal, as in sizeof (int){}; where the
+ // parens could be part of a parenthesized type name or for a cast
+ // expression of some kind.
+ bool ParenKnownToBeNonCast =
+ OpTok.isOneOf(tok::kw_typeof, tok::kw_typeof_unqual);
ParenParseOption ExprType = ParenParseOption::CastExpr;
SourceLocation LParenLoc = Tok.getLocation(), RParenLoc;
- Operand = ParseParenExpression(ExprType, true/*stopIfCastExpr*/,
- false, CastTy, RParenLoc);
+ Operand = ParseParenExpression(ExprType, true /*stopIfCastExpr*/, false,
+ ParenKnownToBeNonCast, CastTy, RParenLoc);
CastRange = SourceRange(LParenLoc, RParenLoc);
// If ParseParenExpression parsed a '(typename)' sequence only, then this
is
@@ -2589,10 +2602,11 @@ bool Parser::tryParseOpenMPArrayShapingCastPart() {
return !ErrorFound;
}
-ExprResult
-Parser::ParseParenExpression(ParenParseOption &ExprType, bool stopIfCastExpr,
- bool isTypeCast, ParsedType &CastTy,
- SourceLocation &RParenLoc) {
+ExprResult Parser::ParseParenExpression(ParenParseOption &ExprType,
+ bool stopIfCastExpr, bool isTypeCast,
+ bool ParenKnownToBeNonCast,
+ ParsedType &CastTy,
+ SourceLocation &RParenLoc) {
assert(Tok.is(tok::l_paren) && "Not a paren expr!");
ColonProtectionRAIIObject ColonProtection(*this, false);
BalancedDelimiterTracker T(*this, tok::l_paren);
@@ -2747,7 +2761,7 @@ Parser::ParseParenExpression(ParenParseOption &ExprType,
bool stopIfCastExpr,
T.consumeClose();
ColonProtection.restore();
RParenLoc = T.getCloseLocation();
- if (Tok.is(tok::l_brace)) {
+ if (!ParenKnownToBeNonCast && Tok.is(tok::l_brace)) {
ExprType = ParenParseOption::CompoundLiteral;
TypeResult Ty;
{
@@ -2757,7 +2771,7 @@ Parser::ParseParenExpression(ParenParseOption &ExprType,
bool stopIfCastExpr,
return ParseCompoundLiteralExpression(Ty.get(), OpenLoc, RParenLoc);
}
- if (Tok.is(tok::l_paren)) {
+ if (!ParenKnownToBeNonCast && Tok.is(tok::l_paren)) {
// This could be OpenCL vector Literals
if (getLangOpts().OpenCL)
{
diff --git a/clang/lib/Parse/Parser.cpp b/clang/lib/Parse/Parser.cpp
index 18f399aca59e8..2f201cc49cf0b 100644
--- a/clang/lib/Parse/Parser.cpp
+++ b/clang/lib/Parse/Parser.cpp
@@ -1607,7 +1607,8 @@ ExprResult Parser::ParseAsmStringLiteral(bool
ForAsmLabel) {
EnterExpressionEvaluationContext ConstantEvaluated(
Actions, Sema::ExpressionEvaluationContext::ConstantEvaluated);
AsmString = ParseParenExpression(ExprType, true /*stopIfCastExpr*/, false,
- CastTy, RParenLoc);
+ false /*ParenKnownToBeNonCast*/, CastTy,
+ RParenLoc);
if (!AsmString.isInvalid())
AsmString = Actions.ActOnConstantExpression(AsmString);
diff --git a/clang/test/Parser/c2x-typeof.c b/clang/test/Parser/c2x-typeof.c
index 9c836dfa6d823..245c127d71e03 100644
--- a/clang/test/Parser/c2x-typeof.c
+++ b/clang/test/Parser/c2x-typeof.c
@@ -42,3 +42,13 @@ _Static_assert(__builtin_offsetof(typeof(s), i) == 0);
_Static_assert(__builtin_offsetof(typeof_unqual(struct S), i) == 0);
_Static_assert(__builtin_offsetof(typeof_unqual(s), i) == 0);
+// Show that typeof and typeof_unqual can be used in the underlying type of an
+// enumeration even when given the type form. Note, this can look like a
+// compound literal expression, which caused GH146351.
+enum E3 : typeof(int) { ThirdZero }; // (int) {}; is not a compound literal!
+enum E4 : typeof_unqual(int) { FourthZero }; // Same here
+
+// Ensure that this invalid construct is diagnosed instead of being treated
+// as typeof((int){ 0 }).
+typeof(int) { 0 } x; // expected-error {{a type specifier is required for all
declarations}} \
+ expected-error {{expected identifier or '('}}
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
