This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 3/7] Emit macro expansion related diagnostics
- From: Jason Merrill <jason at redhat dot com>
- To: Dodji Seketeli <dodji at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, tromey at redhat dot com, gdr at integrable-solutions dot net, joseph at codesourcery dot com, burnus at net-b dot de, charlet at act-europe dot fr, bonzini at gnu dot org
- Date: Tue, 04 Oct 2011 16:58:27 -0400 (EDT)
- Subject: 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 <firstname.lastname@example.org> wrote:
Jason Merrill <email@example.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