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

Jakub Jelinek jakub@redhat.com
Tue Sep 15 11:01:00 GMT 2015


On Tue, Sep 15, 2015 at 12:33:58PM +0200, Richard Biener wrote:
> 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).

What I had in mind was just add
  source_location start, end;
to location_adhoc_data struct and use !IS_ADHOC_LOC locations to represent
just plain locations without block and without range (including the cases
where the range has both start and end equal to the locus) and IS_ADHOC_LOC
locations for the cases where either we have non-NULL block, or we have
some other range, or both.  But I haven't spent any time on that, so just
wondering if such an encoding has been considered.

	Jakub



More information about the Gcc-patches mailing list