On 19 February 2016 at 19:13, David Malcolm <dmalc...@redhat.com> wrote:
>> 68425.c:3:34: warning: excess elements in array initializer (6
>> elements,
>> expected 2)
>> const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
>> ^~~~~~~~~~~~~
>
> Yes, that would be ideal. Unfortunately, not every tree expression
> node has a location stored for it, so implementing the underlined range
> might be tricky to do. (in particular, INTEGER_CST doesn't. I hope to
> look into that for gcc 7, perhaps with a wrapper node to provide
> locations for expr nodes that don't have them).
Do you think that would be better than storing the locations in the
parent expression? That is, instead of adding extra wrapper nodes,
with all those tree nodes wasting space just to provide a location,
add extra location slots to every tree that may have an operand. Or
perhaps you are thinking about adding some lighter wrapper which is
just a loc+tree* or something like that.
In the case above (for C), struct constructor_stack could keep track
of token locations passed by the parser (all tokens have locations,
but those locations are not saved in all trees). In fact, I see that
there is already a lot of location passing in the corresponding code,
but probably all of them refer to input_location or some such.
Cheers,
Manuel.
