[PATCH 0/6] Tracking locations of tokens resulting from macro expansion
Jeff Law
law@redhat.com
Mon Dec 13 15:10:00 GMT 2010
On 12/10/10 11:10, Dodji Seketeli wrote:
>>
>>> Several obversations can be made in that hypothetical example.
>>>
>>> - The location mentioned in the error message
>>>
>>> test.c:5:14: error: invalid operands to binary<< (have âdoubleâ and âintâ)
>>>
>>> is the spelling location of the token '<<'. I believe this makes more
>>> sense than the original behaviour.
>> Agreed. However, I suspect some will disagree and it may cause havoc
>> in automated code that parses error messages. Presumably there's a
>> way to get the old behavior, even if you're tracking all three
>> locations?
> The linemap API allows us to get the old behaviour (i.e, resolve virtual
> locations to the macro expansion point). But as most of the client code
> does that through the expand_location function, I wasn't sure how to
> introduce choice there in a convenient way. Maybe I should add another
> flag to control the "user interface" so to speak?
I'm not sure either. I wouldn't be terribly surprised if we end up
changing our minds (whatever they may be) after a period of time with
access to more thorough diagnostic information. ie, we may not know
what the right interface should be until after we've used the info for a
while. So I guess we should keep our options open for the UI issues.
Jeff
More information about the Gcc-patches
mailing list