The following invalid code snippet triggers a broken diagnostic since at least GCC 2.95.3: ==================== struct A { bool b; }; void f(A a) { a.b--; } ==================== bug.cc: In function 'void f(A)': bug.cc:8: error: invalid use of '--' on bool variable '#'component_ref' not supported by dump_decl#<declaration error>'
Confirmed. The problem is obvious: error ("invalid use of %<--%> on bool variable %qD", arg); %qD should be %qE.
But do we really want 'a.A::b' ?!?
(In reply to comment #2) > But do we really want 'a.A::b' ?!? Well the error message needs rewording also. Something like: invalid use of %<--%> on bool lvalue %qE
Subject: Re: Broken diagnostic: 'component_ref' not supported by dump_decl "pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes: | But do we really want 'a.A::b' ?!? No, we don't. The format specific is OK -- e.g. it should be %qD. However, the caller of error() should make sure it gives a _DECL. It isn't really the diagnostic machinery's business here to second guess a type error correction. Of course, it would have been better if we had diagnostics with carret... -- Gaby
Thanks Gaby, let's see what I can do...
Another testcase: void f(bool *b) { (*b)--; } And another one: bool &g(void); void f(bool *b) { g()--; } So variable in the error message does not make sense at all. We want to use lvalue instead.
(In reply to comment #4) > | But do we really want 'a.A::b' ?!? > > No, we don't. The format specific is OK -- e.g. it should be %qD. However, > the caller of error() should make sure it gives a _DECL. It isn't > really the diagnostic machinery's business here to second guess > a type error correction. Actually "variable a" or "variable b" does not make sense here, we really want to use the word lvalue instead of variable as shown by my other two testcases. Yes I know it is not the diagnostic machinery's business here to second guess a type error correction but I am saying we need to change the error message fully. We should not be using "variable %qD" when we can get any kind of lvalues here. -- Pinski
Subject: Re: Broken diagnostic: 'component_ref' not supported by dump_decl "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Another testcase: | void f(bool *b) | { | (*b)--; | } | | And another one: | bool &g(void); | | void f(bool *b) | { | g()--; | } Interesting testcase. This makes me revise my previous opinion to: we should not use any of the format specifier at all -- not %qD, not %qE. | So variable in the error message does not make sense at all. We want to use | lvalue instead. What has this to do with lvalue? I believe the restriction is that, it just does not make any sense to decrement a bool -- be it an lvalue or an rvalue. Paolo, what about error ("invalid use of Boolean expression as operand to %<operator--%>") ? -- Gaby
(In reply to comment #8) > Paolo, what about > > error ("invalid use of Boolean expression as operand to %<operator--%>") > > ? Cetainly works for me...
Subject: Bug 33208 Author: paolo Date: Sun Sep 2 13:02:31 2007 New Revision: 128025 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128025 Log: /cp 2007-09-02 Paolo Carlini <pcarlini@suse.de> PR c++/33208 * typeck.c (build_unary_op): Fix error message for Boolean expression as operand to operator--. /testsuite 2007-09-02 Paolo Carlini <pcarlini@suse.de> PR c++/33208 * g++.dg/other/error18.C: New. * g++.dg/expr/bitfield3.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/other/error18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/expr/bitfield3.C
Fixed.