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