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
