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

[Jason Merrill <jason@redhat.com>]

On 07/16/2011 10:37 AM, Dodji Seketeli wrote:
> As locations of macro locations
> decrease monotonically we need LINEMAPS_MACRO_HIGHEST_LOCATION (used in
> linemap_enter_macro) for reasons that are similar to why we need
> LINEMAPS_ORDINARY_HIGHEST_LOCATION.

Ah, I see, I was missing the use in linemap_enter_macro.  But then it's 
really LINEMAPS_MACRO_LOWEST_LOCATION, isn't it? :)

And I think you don't really need it: since we know exactly how many 
tokens a macro map has when we create it, you could just put the lower 
bound in start_location and index upward from there so we don't need 
LOCATION_POSSIBLY_IN_MAP_P (which is a strange name for an ordering 
predicate).

> +      bool expand_to_expansion_point_p =
> +       !linemap_tracks_macro_expansion_locs_p (line_table);
> +
> +    /* If LOC is the location of a token resulting from macro
> +       expansion, either expand to the location of the macro expansion
> +       point if we don't support tracking token locations accross
> +       macro expansion, or expand to the actual spelling location of
> +       the token where the error is if we do support tracking
> +       locations accross macro expansion.  */
> +      xloc =
> +       linemap_expand_location_full (line_table, loc,
> +                                     (expand_to_expansion_point_p)
> +                                     ? LRK_MACRO_EXPANSION_POINT
> +                                     : LRK_SPELLING_LOCATION,
> +                                     NULL);

Why is this logic here?  It seems like it would be better to just pass 
LRK_SPELLING_LOCATION and have linemap_expand_location_full do the best 
it can.

Also, in light of:

>         * include/line-map.h (linemap_expand_location_full): Add an output
>         parameter returning the spelling location the input location got
>         resolved to, at declaration point ...
>         * line-map.c (linemap_expand_location_full): ... and at definition
>         point.

it seems like what you really want is two functions, one that resolves 
one location to another, and a different function that just expands the 
result.

> +   This map shall be created when the macro is expanded. The map
> +   encodes the source location of the expansion point of the macro as
> +   well as the "original" source location of each token that is part
> +   of the macro replacement-list. If a macro is defined but never

Hmm.  The locations of the tokens in the macro definition are shared 
between all expansions of a particular macro, so I wonder if it would be 
possible to encode only the information about the actual macro 
invocation, i.e. the expansion point and the locations of the argument 
tokens.  That ought to be smaller than repeating all the macro token 
locations.

> +   ORIG_LOC is the orginal location of the token at the definition
> +   point of the macro. If you read the extensive comments of struct
> +   line_map_macro in line-map.h, this is the xI.

> +   If the token is part of a macro argument, ORIG_PARM_REPLACEMENT_LOC
> +   is the location of the point at wich the token (the argument)
> +   replaces the macro parameter in the context of the relevant macro
> +   definition. If you read the comments of struct line_map_macro in
> +   line-map.h, this is the yI.  */

I continue to find this description confusing.  In:

> +       int a = PLUS (1,2); <--- #2

Which of these is the location of "1"?  I'd think it would be an xI, but 
that isn't in the definition of a macro.

Jason