On Mon, Jul 13, 2020 at 10:08:52AM -0400, Nathan Sidwell wrote:
> On 7/10/20 11:43 AM, Marek Polacek via Gcc-patches wrote:
> > Here's an interesting issue: in this code a ) is missing:
> >
> > enum { E = (2 } e;
> >
> > but we compile the code anyway, and E is set to 0 in build_enumerator,
> > which is sneaky.
> >
> > The problem is that cp_parser_enum_specifier parses tentatively, because
> > when we see the enum keyword, we don't know yet if we'll find an
> > enum-specifier, opaque-enum-declaration, or elaborated-enum-specifier.
> >
> > In this test when we call cp_parser_enumerator_list we're still parsing
> > tentatively, and as a consequence, parens.require_close (parser) in
> > cp_parser_primary_expression doesn't report any errors. But we only go
> > on to parse the enumerator-list after we've seen a {, at which point we
> > might as well commit -- we know we're dealing with an enum-specifier.
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> ok, (with the typo Jakub noticed fixed :)
Thanks.
> does this also fix 95288?
Hmm, in a way: instead of
95288.C:3:3: error: expected primary-expression before ‘enum’
3 | enum X
| ^~~~
with this patch we say
95288.C:5:8: error: expected ‘}’ before ‘.’ token
5 | a. // DOT
| ^
95288.C:4:5: note: to match this ‘{’
4 | {
| ^
but the rest of the output is the same.
Whether that means that 95288 is fixed, I'm not too sure. But since you opened
it, if you're happy with the diagnostic with this patch, I'll add the test and
close 95288.
Marek
