Jason Merrill <ja...@redhat.com> writes:
> On 05/15/2012 10:17 AM, Dodji Seketeli wrote:
>> It fixes the test case gcc.dg/cpp/paste12.c because that test case runs
>> with -ftrack-macro-expansion turned off. Otherwise, you are right that
>> the issue exists only when we aren't tracking virtual locations.
>
> I still don't understand why this change should be needed; it seems
> like a kludge disguised as a trivial change from one function to
> another. If we're going to kludge, I'd rather explicitly set the flag
> with a comment.
>
> But why do we need the set_invocation_location flag at all?
I understand this set_invocation_location business as the poor man's
approach of tracking the expansion point location prior to the
ftrack-macro-expansion machinery.
When we are about to expand a macro M that is the top-most macro of the
expansion stack, we set it to record the expansion point of M. This is
what cpp_get_token_with_location does.
> When do we not want to set invocation_location if we're beginning to
> expand a macro?
If M itself involves expanding another macro M', we are supposed to call
the (internal function) cpp_get_token_1 that does not set
set_invocation_location. So that the only expansion point recorded is
the one for M, not the one for M'.
Said otherwise, cpp_get_token_with_location is the preferred external top-most
entry point to use to get a token (otherwise, we don't handle expansion
point locations), and cpp_get_token_1 should only used internally.
Now, looking at how surprising this is turning out to be, I am thinking
that cpp_get_token should, like cpp_get_token_with_location just set
pfile->set_invocation_location, just like cpp_get_token_with_location.
Would you agree?
--
Dodji
