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.
nathan
--
Nathan Sidwell
