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

Jakub Jelinek jakub@redhat.com
Tue Sep 15 10:28:00 GMT 2015


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).

	Jakub



More information about the Gcc-patches mailing list