From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24637 invoked by alias); 14 Dec 2010 06:54:53 -0000 Received: (qmail 24629 invoked by uid 22791); 14 Dec 2010 06:54:52 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Dec 2010 06:54:48 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBE6sdX3013986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 01:54:39 -0500 Received: from adjoa.redhat.com (ovpn-113-36.phx2.redhat.com [10.3.113.36]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oBE6sYYi024686; Tue, 14 Dec 2010 01:54:35 -0500 From: Dodji Seketeli To: Paolo Bonzini Cc: gcc-patches@gcc.gnu.org, tromey@redhat.com, joseph@codesourcery.com, gdr@integrable-solutions.net, lopezibanez@gmail.com Subject: Re: [PATCH 3/6] Emit macro expansion related diagnostics References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <1291979498-1604-5-git-send-email-dodji@redhat.com> <4D063157.3050901@gnu.org> X-URL: http://www.redhat.com Date: Tue, 14 Dec 2010 07:24:00 -0000 In-Reply-To: <4D063157.3050901@gnu.org> (Paolo Bonzini's message of "Mon, 13 Dec 2010 15:44:39 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-12/txt/msg01060.txt.bz2 Paolo Bonzini writes: > On 12/10/2010 12:11 PM, Dodji Seketeli wrote: >> [dodji@adjoa gcc]$ ./cc1 -quiet -ftrack-macro-expansion test.c >> 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) >> In macro 'OPERATE' at test.c:2:9 >> Expanded at test.c:5:3 >> In macro 'SHIFTL' at test.c:5:14 >> Expanded at test.c:8:3 >> In macro 'MULT' at test.c:8:3 >> Expanded at test.c:13:3 >>=20 > > I'm not sure I share Jeff's doubts about the location to present. > Possibly _this_ could be controlled by a flag, though. > > Also, I know this is just an RFC, but the error message should > probably look like either this example: > > test.c:5:14: error: invalid operands to binary<< (have =E2=80=98double= =E2=80=99 and =E2=80=98int=E2=80=99) > test.c:2:9: note: in expansion of macro 'OPERATE' > test.c:5:3: note: expanded from here > test.c:5:14: note: in expansion of macro 'SHIFTL'=20 > test.c:8:3: note: expanded from here > test.c:8:3: note: in expansion of macro 'MULT' > test.c:13:3: note: expanded from here Sorry if I am dig into design consideration when we are talking about UI, but I think it is needed to clarify things here. The current custom in the compiler is that the " note:" prefix is displayed only when client code explicitely calls the 'inform' function. That sets the diagnostic kind to DK_NOTE. This seems a little bit different from what is done for macro expansion contexts. The macro expansion context is unwound implicitly. That is, the client code calls e.g: error_at (some_location, "An error occured") and if some_location appears to be the location of a token resulting from macro expansion the diagnostic machinery unwinds the expansion context and displays it to the user, regardless of what the diagnostic kind was. So the context lines are not prefixed with " note:" as the context is generated implicitely. This is similar to what G++ does when it displays template instantiation contexts. On the other hand, I find the " note:" usage more regular and thus easier to parse for tools that interact with the output of the compiler. So there could be some value in us using that prefix. However if we are to use that prefix for implicitely displayed contexts, I think we should factorize diagnostic_build_prefix to allow using the same prefix as the one used for e.g. DK_NOTE. Would that be acceptable? --=20 Dodji