[PATCH 07/22] Implement token range tracking within libcpp and C/C++ FEs

[Richard Biener]

On Tue, Sep 15, 2015 at 12:20 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote:
>> > diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h
>> > index 760467c..c7558a0 100644
>> > --- a/gcc/cp/parser.h
>> > +++ b/gcc/cp/parser.h
>> > @@ -61,6 +61,8 @@ struct GTY (()) cp_token {
>> >    BOOL_BITFIELD purged_p : 1;
>> >    /* The location at which this token was found.  */
>> >    location_t location;
>> > +  /* The source range at which this token was found.  */
>> > +  source_range range;
>>
>> Is it just me or does location now feel somewhat redundant with range?  Can't we
>> compress that somehow?
>
> For a token I'd expect it is redundant, I don't see how it would be useful
> for a single preprocessing token to have more than start and end locations.
> But generally, for expressions, 3 locations make sense.
> If you have
> abc + def
> ~~~~^~~~~
> then having a range is useful.  In any case, I'm surprised that the ranges aren't encoded in
> location_t (the data structures behind it, where we already stick also
> BLOCK pointer).

Probably lack of encoding space ... I suppose upping location_t to
64bits coud solve
some of that (with its own drawback on increasing size of core structures).

Richard.

>         Jakub