Hello,
Jason Merrill <ja...@redhat.com> writes:
>>>>>> // preprocessed output
>>>>>> # 3 "test.cpp" 3 4
>>>>>> sys_token
>>>>>> # 3 "test.cpp"
>>>>>> 3
>>>>>> # 3 "test.cpp" 3 4
>>>>>> sys_token
>>>
>>>> Yeah. For Built-in tokens that are expanded like that we only do track
>>>> their the location of their expansion, not their spelling location. So
>>>> this behaviour is expected as well.
>>>
>>> But surely you can do something to avoid this useless line marker in
>>> this case? A built-in token should never require a line change.
>>
>> What triggers the line change is the *expansion* of the built-in macro
>> __LINE__.
>>
>> That is, the token "3". As the existing location tracking facility
>> doesn't track the locations for tokens originating from the expansion of
>> built-in macros, the relationship "3" -> __LINE__ is lost.
>
> So what is the location of "3" in this case?
The location of the token "3" is 3, in that case. It's the line number
of the expansion point of the __LINE__ built-in macro. The token "3"
does not have a virtual location that allows us to "unwind" back to the
special built-in spelling location 1, that would mean that "3"
originates from a built-in macro.
> It seems to me that it doesn't really have its own location, and so
> we should be able to use whatever the current location is and not emit
> a line note.
The issue is that the location for "3" is not virtual, so there is not
much we can do about it.
But then I have just wrote the support for making that "3" token have a
virtual location. I am sending a small patchset as a follow-up to this
message.
Cheers.
--
Dodji
