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

[Jeff Law]

On 09/15/2015 06:54 AM, Manuel López-Ibáñez wrote:
> On 15 September 2015 at 14:18, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> Of course this boils down to "uses" of a VAR_DECL using the shared tree
>> node.  On GIMPLE some stmt kinds have separate locations for each operand
>> (PHI nodes), on GENERIC we'd have to invent a no-op expr tree code to
>> wrap such uses to be able to give them distinct locations (can't use sth
>> existing as frontends would need to ignore them in a different way than say
>> NOP_EXPRs or NON_LVALUE_EXPRs).
>>
>
> The problem with that approach (besides the waste of memory implied by
> a whole tree node just to store one location_t) is keeping those
> wrappers in place while making them transparent for most of the
> compiler. According to Arnaud, folding made this approach infeasible:
> https://gcc.gnu.org/ml/gcc-patches/2012-09/msg01222.html
>
> The other two alternatives are to store the location of the operands
> on the expressions themselves or to store them as on-the-side
> data-structure, but they come with their own drawbacks. I was
> initially more in favour of the wrapper solution, but after dealing
> with NOP_EXPRs, having to deal also with LOC_EXPR would be a nightmare
> (as you say, they will have to be ignored in a different way). The
> other alternatives seem less invasive and the problems mentioned here
> https://gcc.gnu.org/ml/gcc-patches/2012-11/msg00164.html do not seem
> as serious as I thought (passing down the location of the operand is
> becoming  the norm anyway).
I suspect any on-the-side data structure to handle this is ultimately 
doomed to failure.  Storing the location info for the operands in the 
expression means that anything that modifies an operand would have to 
have access to the expression so that location information could be 
updated.  Ugh.

As painful as it will be, the right way is to stop using DECL nodes like 
this and instead be using another node that isn't shared.  That allows 
atttaching location information.  David and I kicked this around before 
he posted his patch and didn't come up with anything better IIRC.

These wrapper nodes are definitely going to get in the way of folders 
and all kinds of things.  So it's not something that's going to be easy 
to add without digging into and modifying a lot of code.

I've always considered this a wart, but fixing that wart hasn't seemed 
worth the effort until recently.

Jeff