From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23791 invoked by alias); 10 Dec 2010 12:34:04 -0000 Received: (qmail 23633 invoked by uid 22791); 10 Dec 2010 12:34:02 -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-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Dec 2010 12:33:57 +0000 Received: by qwg5 with SMTP id 5so3862805qwg.20 for ; Fri, 10 Dec 2010 04:33:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.229.200 with SMTP id jj8mr588595qcb.295.1291984435685; Fri, 10 Dec 2010 04:33:55 -0800 (PST) Received: by 10.229.75.70 with HTTP; Fri, 10 Dec 2010 04:33:55 -0800 (PST) In-Reply-To: <1291979498-1604-1-git-send-email-dodji@redhat.com> References: <1291979498-1604-1-git-send-email-dodji@redhat.com> Date: Fri, 10 Dec 2010 12:52:00 -0000 Message-ID: Subject: Re: [PATCH 0/6] Tracking locations of tokens resulting from macro expansion From: Gabriel Dos Reis To: Dodji Seketeli Cc: gcc-patches@gcc.gnu.org, tromey@redhat.com, joseph@codesourcery.com, lopezibanez@gmail.com Content-Type: text/plain; charset=ISO-8859-1 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/msg00868.txt.bz2 On Fri, Dec 10, 2010 at 5:11 AM, Dodji Seketeli wrote: > * Problem statement > > Let's consider the diagnostic GCC emits when an error occurs on an > expression that was defined in a macro that is later expanded: I like the general idea of the patch. Ideally, we should avoid introduction of yet another flag for this. I understand the concern about memory consumption, and I share it. But, it would be great we could limit that without introducing new flags -- because it seems the flags would be there only to expose implementation inefficiency, not fundamental user-level functionality. I suspect that for many reasonably well written C++ programs, all those loci are the same. Very few would have all three loci (and actually there is at least a fourth) different. I would suggest exploring functional interface where there are different location implementations, corresponding to the different sensible combinations of location kind. This way, only tokens that are actually macro expanded or created through macro expansion or strnigification get additional necessary slots.