On Sat, Nov 21, 2015 at 9:21 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Sat, Nov 21, 2015 at 02:16:49AM -0500, Jason Merrill wrote:
>> On 11/19/2015 03:46 PM, Jason Merrill wrote:
>> >On 11/15/2015 12:01 AM, David Malcolm wrote:
>> >>As with the C frontend, there's an issue with tree nodes that
>> >>don't have locations: VAR_DECL, INTEGER_CST, etc:
>> >>
>> >> int test (int foo)
>> >> {
>> >> return foo * 100;
>> >> ^^^ ^^^
>> >> }
>> >>
>> >>where we'd like to access the source spelling ranges of the expressions
>> >>during parsing, so that we can use them when reporting parser errors.
>> >
>> >Hmm, I had been thinking to address this in the C++ front end by
>> >wrapping uses in another tree: NOP_EXPR for rvalues, VIEW_CONVERT_EXPR
>> >for lvalues.
>>
>> On the other hand, my direction seems likely to cause more issues,
>> especially with code that doesn't yet know how to handle VIEW_CONVERT_EXPR,
>> and could create ambiguity with explicit conversions. So I guess your
>> approach seems reasonable.
>
> But your approach would allow better diagnostics even in places where you
> don't have the structures with tree, location_t pairs around. With that
> it will be limited solely to the parser and nothing else, so even template
> instantiation if it is something that can be only detected when
> instantiating would be too late.
>
> I think using a new tree (rather than using NOP_EXPR/VIEW_CONVERT_EXPR)
> that would be just some expression with location and teaching the FE and
> folder about it might be even better.
Agreed. Note that we already have NON_LVALUE_EXPR and fold-const.c uses
that to stick locations on things that cannot have them.
OTOH I would like to get rid of NON_LVALUE_EXPR in the middle-end (and thus
fold-const.c).
Richard.
> Jakub
