[PATCH 3/7] Emit macro expansion related diagnostics

[Jason Merrill]

On 09/16/2011 03:55 AM, Dodji Seketeli wrote:
> +    test.c: In function ‘g’:
> +    test.c:5:14: error: 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
> +
> +   The part that goes from the third to the sixth line of this
> +   diagnostic (the lines containing the 'note:' string) is called the
> +   unwound macro expansion trace.  That's the part generated by this
> +   function.

No UTF-8 in the code, please.

Do you mean eighth rather than sixth?

> +      /* If the token at RESOLVED_LOCATION [at macro definition point]
> +         is itself inside an expanded macro then we keep unwinding the
> +         trace by reaching the "parent macro" that got expanded inside
> +         the definition of the macro of MAP...  */

This doesn't make sense to me; a macro definition can't be inside an 
expanded macro.  Can you describe this situation better?

> +  if (first_exp_point_map)
> +    *first_exp_point_map = map;
> +
> +  /* Walk LOC_VEC and print the macro expansion trace, unless the
> +     first macro which expansion triggered this trace was expanded
> +     inside a system header.  */
> +  if (!LINEMAP_SYSP (resolved_map))

Should the SYSP check use "map" rather than "resolved_map"?

Jason