[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