Re: [C++ PATCH] Improve location info [1/many]

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,

On 08/12/2014 05:09 PM, Marek Polacek wrote:
> > Furthermore, the arguments should have their own locations in EXPR_LOCATION;
> > I don't think we need to track them separately.  If their locations are
> > wrong that's something to fix directly, rather than adding a special case
> > for function arguments.
> >
> > So I think I'd like to drop the arg_loc/convert_like changes from this
> > patch.
> The problem is that we can't set EXPR_LOCATION of neither integer_cst nor
> declaration, because only EXPR_Ps can have locations.  That means setting
> EXPR_LOCATIONS of argument here:
> int i = 3;
> foo (i);
> wouldn't work (VAR_DECL), but here
> int i = 3;
> foo (-i);
> it should (NEGATE_EXPR).  Bummer.  So I think we'll have to pursue something
> else.  One possibility (and I think you mentioned this at Cauldron) would be to
> create a new tree code, called e.g. LOCATION_EXPR.  This expr would wrap
> a tcc_constant or a tcc_declaration, and add a location_t to it, thus something
> like:
>
> struct GTY(()) tree_location_expr {
>    struct tree_base base;
>    location_t loc;
> };
>   
> Would that make sense?
Lately I'm not spending much time on these issues, and I'm glad that you 
do, by the way, but I'm still under the impression that something like 
the above is necessary, for templates, for example. Today, however, I 
have a (new for me) thought: why wrapping ("somebody" also suggested a 
NOP_EXPR at some point ;) instead of simply changing integer_cst & co to 
natively have a location?!? Memory use will increase, that for sure, but 
maybe something can be optimized at an abstraction level lower than most 
normal uses, like, if the location is not set, share a node similar to 
current integer_cst, I'm sure a lot can be done in this area. However, 
most *uses* of the beefed up integer_cst would be straightforward, it 
will just become possible to store and fetch the location like for the 
other EXPRs, and there will be no risks of leaking into the middle-end 
new unhandled tree nodes.

Paolo.