This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/7] Emit macro expansion related diagnostics


I was thinking that you could walk the macro expansions to see if the two locations have an expansion in common, and if so compare the indices. I guess you could do this only if the locations have the same expansion location but are not themselves equal.

If comparing the expansion locations is enough for how this function is used that's fine, but the name should be adjusted to be more specific.

Dodji Seketeli <dodji@redhat.com> wrote:

Jason Merrill <jason@redhat.com> writes:

> On 10/03/2011 06:49 PM, Dodji Seketeli wrote:
>> Good question.  Is the below better?
>
>> +  if (linemap_location_from_macro_expansion_p (set, pre))
>> +    pre = linemap_resolve_location (set, pre,
>> +                                   LRK_MACRO_EXPANSION_POINT, NULL);
>> +
>> +  if (linemap_location_from_macro_expansion_p (set, post))
>> +    post = linemap_resolve_location (set, post,
>> +                                    LRK_MACRO_EXPANSION_POINT,
>> +                                    NULL);
>
> This looks like two different virtual locations from the same macro
> expansion will compare equal.

Yes.  I thought this was enough to not regress compared to the current
situation where two tokens from the same macro expansion have the
spelling location of macro expansion point anyway.  This is used for
#pragma disagnostic changes in diagnostic_report_diagnostic.

Otherwise, I am not sure how this should behave wrt nested macro
expansions.

-- 
		Dodji


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]