Hi Joseph,
On Tue, Oct 14, 2025 at 03:49:58PM +0000, Joseph Myers wrote:
> > + c_inhibit_evaluation_warnings++;
> > + if (c_parser_next_token_is (parser, CPP_OPEN_PAREN)
> > + && c_token_starts_compound_literal (c_parser_peek_2nd_token
> > (parser)))
> > + {
> > + /* Either operator ( type-name ) or operator unary-expression
> > + starting with a compound literal. */
>
> All this logic is massively overcomplicated for something that only
> accepts a type name and not an expression at all. Don't copy irrelevant
> logic from other syntax constructs that's not needed here. Just parse a
> type name in parentheses (and thus you don't need to handle storage class
> specifiers that might appear for a compound literal either, for example).
> (And if the feature did end up supporting expressions as well, then
> refactoring things so that the logic for "unary expression or
> parenthesized type name" doesn't need replicating for all of
> sizeof/countof, alignof (as an extension) and maxof/minof would be a good
> idea, though maybe complicated by the various evaluation and error
> handling logic.)
I've significantly simplified this. However, the diagnostics are a bit
worse. For example:
c.c:9:16: error: invalid application of ‘_Maxof’ to something not a type
9 | _Maxof(static int);
| ^~~~~~
c.c:9:16: error: expected ‘;’ before ‘static’
9 | _Maxof(static int);
| ^~~~~~
| ;
c.c:9:26: error: expected statement before ‘)’ token
9 | _Maxof(static int);
| ^
Is this acceptable? The first diagnostic is correct, but the others are
consequences of failing too early in the parsing.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
signature.asc
Description: PGP signature
