Re: [PATCH 1/7] Linemap infrastructure for virtual locations

[Dodji Seketeli <dodji@redhat.com>]

Jason Merrill <jason@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