On Wed, Sep 19, 2012 at 09:18:39AM +0200, Arnaud Charlet wrote: > Thanks for your feedback. > > > I also think this is to be preferred. I think of location_t as being, for > > most of the compiler, an opaque handle to location information. Just as > > it can now represent information about different concepts of location in > > the presence of macro expansion, so it's entirely reasonable for a > > location_t value to represent information about a range of locations > > (start and end points) for an expression, or to represent information > > about the locations (or ranges of locations) of the operands and operators > > of an expression (in the absence of an unfolded AST, where for locations > > of operands themselves you could just look one level down in the AST). > > OK, I agree that's an interesting/promising approach (using/reserving a bit > to add a level of indirection into a separate hash table), I'll investigate > what it could take to implement such approach, which would indeed get rid > of the duplicate_expr_locations() calls, since this would be implicit as > part of protected_set_expr_location() somehow, right?
Please also read Dodji's slides from Cauldron on this: http://dodji.seketeli.net/talks/gnu-cauldron-2012/track-macro-locations.pdf and discuss with him, there is also the "Combine location with block using block_locations" patchset floating around that interferes with this partially. But range locations as part of location_t is definitely the way to go, we want that for proper diagnostics anyway. Jakub
