On Wed, 12 Nov 2025, Alejandro Colomar wrote:
> > but you may be able to reduce the number of
> > diagnostics, by using the matching_parens machinery (with
> > skip_until_found_close) to go to the closing ')' after parsing the type
> > name (successfully or unsuccessfully).
>
> Okay, thanks. BTW, how should I deal with those excess errors in the
> testsuite? Tests like
>
> _Maxof (static int); /* { dg-error "to something not a type" } */
>
> trigger excess errors that I don't know how to deal with.
>
> c.c:12:16: error: invalid application of ‘_Maxof’ to something not a
> type
> 12 | _Maxof(static int);
> | ^~~~~~
> c.c:12:16: error: expected ‘)’ before ‘static’
> 12 | _Maxof(static int);
> | ~^~~~~~
> | )
You can have multiple dg-error directives referencing the same line. E.g.
/* { dg-error "expected" "syntax error" { target *-*-* } .-1 } */
on the next line (here "expected" is the regular expression to test for,
"syntax error" is the description that appears in the test name after PASS
or FAIL - each dg-* test for a given line needs to have a distinct
description to avoid duplicate lines in the .sum file - and ".-1" is a
relative line number).
--
Joseph S. Myers
[email protected]