On Mon, Jul 13, 2020 at 12:18:03PM -0400, Nathan Sidwell wrote:
> On 7/13/20 11:15 AM, Marek Polacek wrote:
> > 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.
>
> Yes, that's the fix I'd expect. I'm sorry the report didn't make it clear
> that the function-scope diagnostic is the poor one.
No worries. I've added the test and closed the PR.
Marek
