Re: [PATCH] Add extra location information - PR43486

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 18 Sep 2012, Ian Lance Taylor wrote:

> On Tue, Sep 18, 2012 at 3:58 AM, Arnaud Charlet <charlet@adacore.com> wrote:
> >
> > Since this issue is more general, I have split my changes and introduced a new
> > tentative switch called -fextra-slocs, which is the subject of this email.
> 
> Sorry for picking on simple stuff, but the switch name seems
> meaningless, and there isn't any documentation.

My simple points are that size_t is better than int for when you want to 
store the length of a list on the host, and that when building up a list 
of locations for an expression list it would be better to use a VEC rather 
than a fixed-length array.

> Another approach might be to tie this to the
> location information, because the location information does generally
> survive fold-const.  E.g., perhaps we could grab a bit in the location
> information to mean that it is special.  And we could keep an
> on-the-side hash table mapping special location values to additional
> location information.

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

I would guess that much of the patch would be unchanged with such an 
approach - you still need to pass extra location information to various 
places, but the details of how you attach it to the expressions might be 
different.

I would say that a location_t mapping to a set of other locations more 
complicated than at present should have some structure to how it maps to 
them.  That is, rather than just mapping to an array of values with those 
values used in different ways for different source code constructs, it 
should be possible to tell that a given location_t is mapping to certain 
locations as corresponding to first and second operands of an binary 
operator (for example).

-- 
Joseph S. Myers
joseph@codesourcery.com