Jason Merrill <ja...@redhat.com> writes:
> On 07/16/2011 10:37 AM, Dodji Seketeli wrote:
>> + /* This array of location is actually an array of pairs of
>> + locations. The elements inside it thus look like:
>> +
>> + x0,y0, x1,y1, x2,y2, ...., xn,yn.
>
> Pairs of locations still seems limited, given the flexibility of macro
> expansion; with macros that use other macros a particular token can be
> substituted an arbitrary number of times; the first time doesn't seem
> particularly special.
If you are talking about the case of a macro A that can have (among the
tokens of its replacement list) a token B that itself is a macro, then
this is supported by the current setup.
When A goes through its expansion process it's replaced by the tokens of
its replacement list. The B (like all the other tokens of the
replacement list of A) token is allocated a virtual location that
encodes the {xi,yi} pair, yes. But that virtual location of B also
encodes the location of the expansion point of B, which is not stored in
the line_map_macro::macro_locations you are talking about here. It is
stored in the line_map_macro::expansion.
Then when B goes through its expansion process, the same process of
virtual location allocation happens, recursively.
>
> But then, it seems that nothing uses the replacement point
> currently. The diagnostics mentioned in patch 3 only seem to use the
> spelling location and the expansion location:
>
>> [dodji@adjoa gcc]$ ./cc1 -quiet -ftrack-macro-expansion test.c
>> test.c: In function ‘g’:
>> test.c:5:14: erreur: invalid operands to binary << (have ‘double’ and ‘int’)
>> test.c:2:9: note: in expansion of macro 'OPERATE'
>> test.c:5:3: note: expanded from here
>> test.c:5:14: note: in expansion of macro 'SHIFTL'
>> test.c:8:3: note: expanded from here
>> test.c:8:3: note: in expansion of macro 'MULT2'
>> test.c:13:3: note: expanded from here
>
> So how do you expect to use the replacement point information?
In that example, this diagnostic
test.c:2:9: note: in expansion of macro 'OPERATE'
actually uses the replacement point information. It's just that it's
not obvious because the token on which the error happens is not an
argument of a function-like macro.
Consider this example instead:
$ cat -n test11.c
1 int var;
2 #define S(x) 1 + x
3 int foo (void)
4 {
5 return S( 2 + var() + 3);
6 }
$ ./cc1 -ftrack-macro-expansion -quiet ../../prtests/test11.c
test11.c: In function ‘foo’:
test11.c:5:20: erreur: called object ‘var’ is not a function
test11.c:2:18: note: in expansion of macro 'S'
test11.c:5:10: note: expanded from here
$
In this example, the error happens on the 'var' token which is passed as
an argument to the S function-like macro. And we want to point, in the
definition of S, to the location where the 'var' argument token is used.
That's the 2:18 location referred to by the line:
test11.c:2:18: note: in expansion of macro 'S'
--
Dodji
