From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29308 invoked by alias); 13 Dec 2010 14:27:18 -0000 Received: (qmail 29164 invoked by uid 22791); 13 Dec 2010 14:27:17 -0000 X-SWARE-Spam-Status: No, hits=-6.9 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; Mon, 13 Dec 2010 14:27:12 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBDER3D3001923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 09:27:03 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oBDER2Ta010365; Mon, 13 Dec 2010 09:27:02 -0500 Received: from [10.3.113.58] (ovpn-113-58.phx2.redhat.com [10.3.113.58]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id oBDER0dR005331; Mon, 13 Dec 2010 09:27:01 -0500 Message-ID: <4D062D34.1050606@redhat.com> Date: Mon, 13 Dec 2010 15:10:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Dodji Seketeli CC: gcc-patches@gcc.gnu.org, tromey@redhat.com, joseph@codesourcery.com, gdr@integrable-solutions.net, lopezibanez@gmail.com Subject: Re: [PATCH 0/6] Tracking locations of tokens resulting from macro expansion References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <4D025930.6020000@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/msg00988.txt.bz2 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 >>> >>> test.c:5:14: error: invalid operands to binary<< (have ‘double’ and ‘int’) >>> >>> is the spelling location of the token '<<'. I believe this makes more >>> sense than the original behaviour. >> Agreed. However, I suspect some will disagree and it may cause havoc >> in automated code that parses error messages. Presumably 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. I wouldn't be terribly surprised if we end up changing our minds (whatever they may be) after a period of time with access to more thorough diagnostic information. ie, we may not know what the right interface should be until after we've used the info for a while. So I guess we should keep our options open for the UI issues. Jeff