Re: [PATCH 0/6] Tracking locations of tokens resulting from macro expansion

[Dodji Seketeli <dodji at redhat dot com>]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> On Fri, Dec 10, 2010 at 5:11 AM, Dodji Seketeli <dodji@redhat.com> 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.

Thanks.

> Ideally, we should avoid introduction of yet another flag for this.

I agree.

> 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.

Actually that's what the second patch does. Only tokens resulting from
macro expansion have the new virtual location. Other tokens just have
the plain old spelling location and thus don't incur any cost.

-- 
	Dodji