[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077 --- Comment #9 from Marek Polacek --- Fixed for GCC 10.2 and 11.
[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:30529e2faa482bc749c65a490763dbc2ccaf63ac
commit r10-8470-g30529e2faa482bc749c65a490763dbc2ccaf63ac
Author: Marek Polacek
Date: Thu Jul 9 20:44:05 2020 -0400
c++: Fix tentative parsing of enum-specifier [PR96077]
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.
gcc/cp/ChangeLog:
PR c++/96077
* parser.c (cp_parser_enum_specifier): Commit to tentative parse
after we've seen an opening brace.
gcc/testsuite/ChangeLog:
PR c++/96077
* g++.dg/parse/enum14.C: New test.
(cherry picked from commit 4fd124a23664c712f1bb1a7e91fa23fe83d72c0b)
[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Marek Polacek --- .
[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077
--- Comment #7 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:4fd124a23664c712f1bb1a7e91fa23fe83d72c0b
commit r11-2064-g4fd124a23664c712f1bb1a7e91fa23fe83d72c0b
Author: Marek Polacek
Date: Thu Jul 9 20:44:05 2020 -0400
c++: Fix tentative parsing of enum-specifier [PR96077]
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.
gcc/cp/ChangeLog:
PR c++/96077
* parser.c (cp_parser_enum_specifier): Commit to tentative parse
after we've seen an opening brace.
gcc/testsuite/ChangeLog:
PR c++/96077
* g++.dg/parse/enum14.C: New test.
[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #6 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549852.html
[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #5 from Marek Polacek ---
We probably need to commit like this to get errors:
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -19412,7 +19412,10 @@ cp_parser_enum_specifier (cp_parser* parser)
"ISO C++ forbids empty unnamed enum");
}
else
- cp_parser_enumerator_list (parser, type);
+ {
+ cp_parser_commit_to_tentative_parse (parser);
+ cp_parser_enumerator_list (parser, type);
+ }
/* Consume the final '}'. */
braces.require_close (parser);
[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077
--- Comment #4 from Marek Polacek ---
Doesn't even need to be in the ?: operator:
int
main ()
{
enum { E = (2 } e;
if (E != 2)
__builtin_abort ();
}
[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #3 from Marek Polacek ---
This is sneaky:
int main ()
{
enum { a = true ? 2 : (3 /* missing ")" here */ } l_e;
if (a != 2)
__builtin_abort ();
}
we never reported the error and 'a' was set to 0 instead of 2. I plan to poke
more.
[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077 --- Comment #2 from Haoxin Tu --- (In reply to Jonathan Wakely from comment #1) > It's not ideal to provide a testcase that doesn't compile for an > accepts-invalid bug. A testcase that actually compiles is a better > demonstration that the invalid code is accepted OK, I got it. Thank you Jonathan. I will do better next time.
[Bug c++/96077] GCC accepts ill-legal local enum definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2020-07-06
--- Comment #1 from Jonathan Wakely ---
It's not ideal to provide a testcase that doesn't compile for an
accepts-invalid bug. A testcase that actually compiles is a better
demonstration that the invalid code is accepted, e.g.
int main () {
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 /* missing ")" here */ } l_e; //accept
}
Every version from 4.0 onwards behaves the same (I didn't test anything older).
