From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10054 invoked by alias); 13 Dec 2010 15:38:43 -0000 Received: (qmail 10038 invoked by uid 22791); 13 Dec 2010 15:38:43 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Dec 2010 15:38:38 +0000 Received: by vws6 with SMTP id 6so3485721vws.20 for ; Mon, 13 Dec 2010 07:38:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.185.1 with SMTP id cm1mr3944399qcb.29.1292254716075; Mon, 13 Dec 2010 07:38:36 -0800 (PST) Received: by 10.229.75.70 with HTTP; Mon, 13 Dec 2010 07:38:36 -0800 (PST) In-Reply-To: <4D062D34.1050606@redhat.com> References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <4D025930.6020000@redhat.com> <4D062D34.1050606@redhat.com> Date: Mon, 13 Dec 2010 16:35:00 -0000 Message-ID: Subject: Re: [PATCH 0/6] Tracking locations of tokens resulting from macro expansion From: Gabriel Dos Reis To: Jeff Law Cc: Dodji Seketeli , gcc-patches@gcc.gnu.org, tromey@redhat.com, joseph@codesourcery.com, lopezibanez@gmail.com Content-Type: text/plain; charset=windows-1252 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/msg00996.txt.bz2 On Mon, Dec 13, 2010 at 8:27 AM, Jeff Law wrote: > On 12/10/10 11:10, Dodji Seketeli wrote: >>> >>>> Several obversations can be made in that hypothetical example. >>>> >>>> - The location mentioned in the error message >>>> >>>> =A0 test.c:5:14: error: invalid operands to binary<< =A0 (have =91doub= le=92 and >>>> =91int=92) >>>> >>>> is the spelling location of the token '<<'. I believe this makes more >>>> sense than the original behaviour. >>> >>> Agreed. =A0However, I suspect some will disagree and it may cause havoc >>> in automated code that parses error messages. =A0Presumably there's a >>> way to get the old behavior, even if you're tracking all three >>> locations? >> >> The linemap API allows us to get the old behaviour (i.e, resolve virtual >> locations to the macro expansion point). But as most of the client code >> does that through the expand_location function, I wasn't sure how to >> introduce choice there in a convenient way. Maybe I should add another >> flag to control the "user interface" so to speak? > > I'm not sure either. =A0I wouldn't be terribly surprised if we end up cha= nging > our minds (whatever they may be) after a period of time with access to mo= re > thorough diagnostic information. =A0ie, we may not know what the right > interface should be until after we've used the info for a while. =A0So I = guess > we should keep our options open for the UI issues. Agreed. One thing we should also keep in mind though: GCC has already way too many flags. Having dedicated flags to control every single aspect does not necessarily make for good design. -- gaby