On Thu, May 27, 2021 at 07:58:03PM +0000, Joseph Myers wrote:
> On Thu, 27 May 2021, Tobias Burnus wrote:
>
> > @Joseph: I CC'ed you in case you have comments regarding
> > c-parser.c's c_parser_check_balanced_raw_token_sequence (comment update)
> > and c_parser_check_tight_balanced_raw_token_sequence (new); the latter
> > is essentially cp_parser_skip_balanced_tokens with slight adaptions.
>
> I don't understand why the name says either "tight" or "balanced". As far
> as I can see, c_parser_check_tight_balanced_raw_token_sequence isn't
> checking for balanced token sequences (in the sense defined in C2x) at all
> and would accept e.g. }]{[ as being balanced. Is that really what's
> supposed to be accepted there? If it is, the comment on the function
> definition needs to explain the exact definition of what token sequences
> are accepted.
Not }]{[ but {[}], true.
I guess what Tobias posted comes from the C++ FE cp_parser_skip_balanced_tokens
which is apparently my fault.
The C++ grammar is:
balanced-token-seq:
balanced-token
balanced-token-seq balanced-token
balanced-token:
( balanced-token-seq opt )
[ balanced-token-seq opt ]
{ balanced-token-seq opt }
any token other than a parenthesis, a bracket, or a brace
so I bet we need something like the C c_parser_check_balanced_raw_token_sequence
instead in the C++ FE too.
For the particular OpenMP use case, I think it really doesn't matter which
one we use, if the opening and closing parens kinds/counts would match but
they wouldn't be balanced, it would be invalid in any case and we'd reported
it during parsing of the iterators.
Jakub
