From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10073 invoked by alias); 19 Nov 2012 16:17:40 -0000 Received: (qmail 9405 invoked by uid 55); 19 Nov 2012 16:17:20 -0000 From: "dodji at seketeli dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header Date: Mon, 19 Nov 2012 16:17:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: dodji at seketeli dot org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg01781.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D55252 --- Comment #6 from dodji at seketeli dot org 2= 012-11-19 16:17:20 UTC --- > I think this his how the macro expansion was designed to work: It > shows the location of the token that triggered the error. Yes. And there are cases where the GCC way seems to make more sense; for instance: $ cat -n test.c 1 #define OPERATE(OPRD1, OPRT, OPRD2) \ 2 OPRD1 OPRT OPRD2; 3=20=20=20=20 4 #define SHIFTL(A,B) \ 5 OPERATE (A,<<,B) 6=20=20=20=20 7 #define MULT(A) \ 8 SHIFTL (A,1) 9=20=20=20=20 10 void 11 g () 12 { 13 MULT (1.0);// 1.0 << 1; <-- so this is an error. 14 } $=20 With GCC: ./test.c: In function =E2=80=98g=E2=80=99: ./test.c:5:14: error: invalid operands to binary << (have =E2=80=98double= =E2=80=99 and =E2=80=98int=E2=80=99) OPERATE (A,<<,B) ^ ./test.c:2:9: note: in definition of macro =E2=80=98OPERATE=E2=80=99 OPRD1 OPRT OPRD2; ^ ./test.c:8:3: note: in expansion of macro =E2=80=98SHIFTL=E2=80=99 SHIFTL (A,1) ^ ./test.c:13:3: note: in expansion of macro =E2=80=98MULT=E2=80=99 MULT (1.0);// 1.0 << 1; <-- so this is an error. ^ $ With Clang: test.c:13:3: error: invalid operands to binary expression ('double' and 'in= t') MULT (1.0);// 1.0 << 1; <-- so this is an error. ^~~~~~~~~~ test.c:8:3: note: expanded from macro 'MULT' SHIFTL (A,1) ^ test.c:5:14: note: expanded from macro 'SHIFTL' OPERATE (A,<<,B) ^ test.c:2:9: note: expanded from macro 'OPERATE' OPRD1 OPRT OPRD2; ~~~~~ ^ ~~~~~ 1 error generated. $ So, at line 13.3, I think it doesn't make sense to talk about a binary expression (which is related to the '<<' operator). So yes, we chose to first point to the token on which the error appeared, and then print the context of the macro expansion all the way to the expansion point. Now I am not sure what the best approach should be. > I also agree that the clang way makes more sense in this case. Indeed.