[Patch / RFC] PR 39681

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,

I had a look to this rather old PR, which doesn't seem particularly 
high-priority, to be honest. It's about the error message we produce for 
things like:

int main()
{
int* p = new foo;
}

where, besides the obvious error message about foo, we also print:

39681.C:3:16: error: expected ‘,’ or ‘;’ before ‘foo’

which seems redundant and boring. The first thing I noticed is that in 
cp_parser_new_type_id, at variance with cp_parser_type_id, when 
cp_parser_type_specifier_seq sets error_mark_node as 
type_specifier_seq.type we don't notice. If change it to also return 
error_mark_node we have a chance to do something in the immediate 
callers. That would allow to avoid the above error message. However, I 
noticed that I could do the check a couple of levels above, that is in 
cp_parser_init_declarator and cp_parser_late_parse_one_default_arg, and 
this allows to catch more redundant error messages about expected 
semicolons (see the ext and c-c++-common testcases below, I like that *a 
lot* ;): it's just matter of skipping to the end of the statement. I'm 
not 100% sure about many details of this, eg, whether the diagnostics 
could somehow regress in some particular situations. But the patch boots 
and tests fine (the cp_parser_late_parse_one_default_arg bits take care 
of the C++11 NSDMI case, for example, see error8.C).

Finally, as a last remark, the PR also talks about "expected 
type-specifier before ‘foo’" not being an optimal error message, or at 
least not being clear enough. Well, ICC prints something quite similar 
in this case and related ones (only talks about type instead of 
type-specifier, less technical). All in all I'm not convinced we should 
change cp_parser_type_specifier_seq to print something else, but I think 
it would be just an additional tweak.

Thanks,
Paolo.

/////////////////////////

Attachment: CL_39681
Description: Text document

Attachment: patch_39681
Description: Text document