Re: [PATCH 3/7] Emit macro expansion related diagnostics

[Jason Merrill <jason at redhat dot com>]

On 09/19/2011 09:58 AM, Dodji Seketeli wrote:
> +   The part that goes from the third to the heighth line of this

An extra 'h' snuck in there. :)

> Inside the definition of a macro M, you can have another macro M'.
> And M' is going to be eventually expanded into a token FOO.
>
> So, to paraphrase what I said earlier, FOO [which is at a point in the
> definition of the macro M] is itself inside the expanded macro M'.

So what we're dealing with here is the token FOO.  We start with its 
fully-expanded location, and then step out to see where it was expanded 
from.  If that location is still within a macro expansion, we step out 
again until we are at the point in the source that originally triggered 
a macro expansion.  Right?

I don't understand how that unwinding operation maps onto a function 
called linemap_macro_map_loc_to_def_point, and why we need to use both 
that function and linemap_macro_map_loc_to_exp_point here.

I'm afraid this is leading me to question the basic model again.

> +      1    #define OPERATE(OPRD1, OPRT, OPRD2) \
> +      2      OPRD1 OPRT OPRD2;
> +      3
> +      4    #define SHIFTL(A,B) \
> +      5      OPERATE (A,<<,B)
> +      6
> +      7    #define MULT(A) \
> +      8      SHIFTL (A,1)
> +      9
> +     10    void
> +     11    g ()
> +     12    {
> +     13      MULT (1.0);// 1.0 << 1; <-- so this is an error.
> +     14    }

Here "1.0" has the locations 2(OPRD1), 5(A), 8(A), 13(1.0).  "<<" has 
the locations 2(OPRT), 5(<<), 8(SHIFTL), 13(MULT).  Each token has 4 
locations, one for each of the macros involved plus one for the original 
expansion location.  So it seems like we ought to be able to get away 
with only storing one location per token in a macro expansion map.  Am I 
missing something?

Jason