[Bug c++/103347] [9/10/11/12 Regression] Non-static data member initialization is erroneously allowed in C++03 with assignment to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103347
--- Comment #10 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:d71d019f63ed5d3fdb34579023bafa4dcf323f2c
commit r12-5488-gd71d019f63ed5d3fdb34579023bafa4dcf323f2c
Author: Marek Polacek
Date: Mon Nov 22 14:09:25 2021 -0500
c++: Fix missing NSDMI diagnostic in C++98 [PR103347]
Here the problem is that we aren't detecting a NSDMI in C++98:
struct A {
void *x = NULL;
};
because maybe_warn_cpp0x uses input_location and that happens to point
to NULL which comes from a system header. Jakub suggested changing the
location to the '=', thereby avoiding the system header problem. To
that end, I've added a new location_t member into cp_declarator. This
member is used when this declarator is part of an init-declarator. The
rest of the changes is obvious. I've also taken the liberty of adding
loc_or_input_loc, since I want to avoid checking for UNKNOWN_LOCATION.
PR c++/103347
gcc/cp/ChangeLog:
* cp-tree.h (struct cp_declarator): Add a location_t member.
(maybe_warn_cpp0x): Add a location_t parameter with a default
argument.
(loc_or_input_loc): New.
* decl.c (grokdeclarator): Use loc_or_input_loc. Pass init_loc
down
to maybe_warn_cpp0x.
* error.c (maybe_warn_cpp0x): Add a location_t parameter. Use it.
* parser.c (make_declarator): Initialize init_loc.
(cp_parser_member_declaration): Set init_loc.
(cp_parser_condition): Likewise.
(cp_parser_init_declarator): Likewise.
(cp_parser_parameter_declaration): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/nsdmi-warn1.C: New test.
* g++.dg/cpp0x/nsdmi-warn1.h: New file.
[Bug c++/103347] [9/10/11/12 Regression] Non-static data member initialization is erroneously allowed in C++03 with assignment to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103347 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #9 from Marek Polacek --- (In reply to Jakub Jelinek from comment #8) > And grokdeclarator isn't called with the actual initializer (DEFERRED_PARSE) > from which we could dig up the location of the first token. True, though cp_parser_member_declaration has initializer_token_start which carries the location of the '='. I suppose we could add another location_t to cp_declarator for init-declarators, and then just use it. For which I have a patch: $ ./cc1plus -quiet 103347.C -std=c++03 103347.C:3:13: warning: non-static data member initializers only available with ‘-std=c++11’ or ‘-std=gnu++11’ [-Wc++11-extensions] 3 | void *x = NULL; //invalid in C++03 mode | ^
[Bug c++/103347] [9/10/11/12 Regression] Non-static data member initialization is erroneously allowed in C++03 with assignment to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103347
Jakub Jelinek changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
Perhaps a faster way to fix this would be to try to warn on the = token rather
than on input_location which happens to be the location of NULL after
cp_parser_cache_defarg went through it.
For
struct test {
int x = 1 + 2; //invalid in C++03 mode
};
we strangely warn with caret on the 2, for int x = (1 + 2); with caret on )
etc.
maybe_warn_cpp0x doesn't really take a location_t though, probably it should.
And grokdeclarator isn't called with the actual initializer (DEFERRED_PARSE)
from which we could dig up the location of the first token.
[Bug c++/103347] [9/10/11/12 Regression] Non-static data member initialization is erroneously allowed in C++03 with assignment to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103347 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5
