From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2867 invoked by alias); 26 Sep 2011 20:22:50 -0000 Received: (qmail 2854 invoked by uid 22791); 26 Sep 2011 20:22:47 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 26 Sep 2011 20:22:29 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8QKM4cO006277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 16:22:04 -0400 Received: from localhost (ovpn-113-74.phx2.redhat.com [10.3.113.74]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8QKM2mI028529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 16:22:03 -0400 Received: by localhost (Postfix, from userid 500) id 7DE05DB3D; Mon, 26 Sep 2011 22:21:55 +0200 (CEST) From: Dodji Seketeli To: Jason Merrill Cc: gcc-patches@gcc.gnu.org, tromey@redhat.com, gdr@integrable-solutions.net, joseph@codesourcery.com, burnus@net-b.de, charlet@act-europe.fr, bonzini@gnu.org Subject: Re: [PATCH 3/7] Emit macro expansion related diagnostics References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <7ab852c58faea9efd81130c5a1ddc9e78b34bcc5.1310824121.git.dodji@redhat.com> <4E6E73F8.4030603@redhat.com> <4E74AA75.8090106@redhat.com> <4E778A26.1000707@redhat.com> <4E77ACA1.80205@redhat.com> <4E789C5B.20509@redhat.com> <4E793BF4.4010103@redhat.com> <4E7B497F.8060301@redhat.com> X-URL: http://www.redhat.com Date: Mon, 26 Sep 2011 21:11:00 -0000 In-Reply-To: <4E7B497F.8060301@redhat.com> (Jason Merrill's message of "Thu, 22 Sep 2011 10:43:11 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2011-09/txt/msg01645.txt.bz2 Jason Merrill writes: > On 09/21/2011 02:32 PM, Dodji Seketeli wrote: >> FWIW, I'd like the LRK_MACRO_PARM_REPLACEMENT name (or its >> replacement. ha ha) to hint at the fact that it really has to do with >> a token that is an /argument/ for a function-like macro. > > I disagree; arguments are the situation when the two locations differ, > but this one (yI) is always the source location in the macro > definition I think an interesting question to ask here is "the source location of what exactly?". The value of the source location is always the same, yes, but its meaning is different depending on if the token in question is an argument or not. When the token is not an argument, then yI is a source location for *that* token in the macro definition. It's then the spelling location for the token in question. When the token is an argument, then yI is a source location for *another* token. Namely, the parameter for that argument. Not necessarily the spelling location for the token we are observing. > while the first one (xI) is either that or, for macro arguments, a > virtual location. Yes, but it's always a locus of the observed token. Would LRK_MACRO_DEFINITION_LOCATION be better then? :-) -- Dodji