On 09/15/2015 04:33 AM, Richard Biener wrote:
On Tue, Sep 15, 2015 at 12:20 PM, Jakub Jelinek <ja...@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).
If we're going to 64 bits, then we might consider making it a pointer so
that we don't have to spend so much time building up an encoding scheme.
Jeff
