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]

Reply via email to