This is spinoff #2 from 16777: we accept this piece of code: ------------------------ struct X { void X::bar() {} }; ------------------------ I'm not sure we should. icc8 gives this message: g/x> icc -Xc -ansi -c x.cc x.cc(2): warning #470: qualified name is not allowed in member declaration void X::bar() {} ^ Can someone point me to the part of the standard that clarifies this? W.
[dcl.meaning]/1: "A declarator-id shall not be qualified except for the definition of a member function (9.3) or static data member (9.4) or nested class (9.7) outside of its class, the definition or explicit instantiation of a function, variable or class member of a namespace outside of its namespace, or the definition of a previously declared explicit specialization outside of its namespace, or the declaration of a friend function that is a member of another class or namespace." Confirmed, not a regression.
G++ will issue a diagnostic about this usage with -pedantic. The decision not to issue a diagnostic in the default mode is conscious and intentional; G++ has historically accepted this code, and there is no semantic problem with accepting it. There are some members of the GCC community that are very much opposed to making the compiler stricter in the default mode. Jason, Nathan, do you think we should turn this diagnostic on by default (as a pedwarn), or just close this PR? If the latter, should we document this extension?
Well, we've been tightening the compiler in many places. I consider this a particularly useless extension -- it's true that it doesn't hurt anyone, but it adds nothing whatsoever of value to the language. I would be very much surprised if more than a handful of people have ever used it, and I can't think of a reason why it would be undue to ask them to fix their codes. In the interest of sticking with the language standards and to simplify the compiler, I vote for removing the extension. Even documenting it seems a waste of time to me. W.
Subject: Re: Accepts qualified member function declaration in class "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | G++ will issue a diagnostic about this usage with -pedantic. | | The decision not to issue a diagnostic in the default mode is conscious and | intentional; G++ has historically accepted this code, and there is no semantic | problem with accepting it. There are some members of the GCC community that are | very much opposed to making the compiler stricter in the default mode. | | Jason, Nathan, do you think we should turn this diagnostic on by default (as a | pedwarn), or just close this PR? If the latter, should we document | this extension? We should make it a diagnostic and give a switch to people who are "annoyed" to turn it off. -- Gaby
A pedwarn might be the way to go, but I don't feel strongly about it.
I would dearly love to be able to say -Woverzealous-qualification or something like that to turn on this warning. It would make keeping our code portable much easier.
Dan, why can't you use -pedantic? That's the best way of avoiding gnuisms.
Pain. We have a very large application, and we cannot afford to fix all the warnings -pedantic gives. This is another case of "we want to turn on and off individual warnings, please". We're getting mighty tired of having to fix this particular problem in our source over and over again every time we try our app with a non-gcc compiler; pretty please let us turn this warning on by itself...
Also, the non-gcc compiler we're trying our code with supports some but not all gnuisms, so -pedantic would actually cause us to fix much more of our code than is practically neccessary for the kind of portability we want at the moment.
Subject: Re: Accepts qualified member function declaration in class I wouldn't mind turning this diagnostic on by default as a pedwarn. As usual, people who want their code to build anyway can use -fpermissive. I'm strongly opposed to adding a flag for this diagnostic; I don't want to use warning flags for things that make the code technically ill-formed. I'm not particularly sympathetic to Dan's desire to be able to make GCC exactly as pedantic as EDG. If you don't want to deal with all the warnings from -pedantic, you can also filter them out with grep. Jason
We build everything with -Werror so errors are flagged as fatal. If we added -pedantic, we'd have to stop using -Werror, and implement the fatal error check ourselves in a wrapper, which would be a huge pain. gcc-4.1 had a stated goal of giving every warning a name, and letting them be turned on and off individually. See http://gcc.gnu.org/wiki/Warning%20Message%20Control I thought I was asking for something along the same lines. I can't understand why anybody would oppose the ability to turn on and off warnings selectively; Jason, are you also opposed to that feature of gcc-4.1? I am all in favor of forcing code to be C++ compliant, but I have to tell you I just spent the last year whipping a codebase into shape in that regard, and I'd really like to be able to pick my battles, and not have to fight the tools to do so.
Subject: Re: Accepts qualified member function declaration in class dank at kegel dot com wrote: > gcc-4.1 had a stated goal of giving every warning a name, > and letting them be turned on and off individually. > Jason, are you also opposed to that feature of gcc-4.1? No. The difference is that this diagnostic should really be an error, we're just making it a pedwarn to allow noncompliant code to build when it's clear what it means. But I suppose if people want to be able to turn pedwarns on and off individually under the same scheme, I can accept that. Jason
Subject: Re: Accepts qualified member function declaration in class "jason at redhat dot com" <gcc-bugzilla@gcc.gnu.org> writes: | Subject: Re: Accepts qualified member function declaration | in class | | dank at kegel dot com wrote: | > gcc-4.1 had a stated goal of giving every warning a name, | > and letting them be turned on and off individually. | > Jason, are you also opposed to that feature of gcc-4.1? | | No. The difference is that this diagnostic should really be an error, | we're just making it a pedwarn to allow noncompliant code to build when | it's clear what it means. While I said previously that I would prefer a switch over a documented extensions; I would also like to point out that pedwarns really are differents beasts -- and really are errors. They are not like the kind of "uninitialized var" warnings. -- Gaby
Sounds like we're in violent agreement, then.
We have consensus to change this to a pedwarn by default; I'll take care of that.
Subject: Bug 16782 CVSROOT: /cvs/gcc Module name: gcc Changes by: mmitchel@gcc.gnu.org 2005-09-28 14:50:18 Modified files: gcc/cp : decl.c ChangeLog gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.law: static-mem5.C gcc/testsuite/g++.old-deja/g++.mike: p8154.C Added files: gcc/testsuite/g++.dg/parse: qualified4.C Log message: PR c++/16782 * decl.c (grokdeclarator): Always pedwarn about overqualified member names. PR c++/16782 * g++.dg/parse/qualified4.C: New test. * g++.old-deja/g++.law/static-mem5.C: Use -w -fpermissive. * g++.old-deja/g++.mike/p8154.C: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1428&r2=1.1429 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4904&r2=1.4905 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6110&r2=1.6111 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/qualified4.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.law/static-mem5.C.diff?cvsroot=gcc&r1=1.3&r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.mike/p8154.C.diff?cvsroot=gcc&r1=1.3&r2=1.4
Fixed in 4.1.0.