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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Mon, Dec 13, 2010 at 8:27 AM, Jeff Law <law@redhat.com> wrote:
> 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.

Agreed.  One thing we should also keep in mind though:  GCC has already
way too many flags.  Having dedicated flags to control every single
aspect does not necessarily make for good design.

-- gaby