Re: [PATCH/RFC] C++ FE: expression ranges (v2)

[David Malcolm <dmalcolm at redhat dot com>]

On Mon, 2015-11-23 at 10:59 +0100, Richard Biener wrote:
> On Sat, Nov 21, 2015 at 9:21 AM, Jakub Jelinek <jakub@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).

Thanks.

Does the following look like the kind of thing you had in mind?  (just
the tree.def part for now).   Presumably usable for both lvalues and
rvalues, where the thing it wraps is what's important.  It merely exists
to add an EXPR_LOCATION, for a usage of the wrapped thing.

diff --git a/gcc/tree.def b/gcc/tree.def
index 44e5a5e..30fd766 100644
--- a/gcc/tree.def
+++ b/gcc/tree.def
@@ -1407,6 +1407,13 @@ DEFTREECODE (CILK_SPAWN_STMT, "cilk_spawn_stmt", tcc_statement, 1)
 /* Cilk Sync statement: Does not have any operands.  */
 DEFTREECODE (CILK_SYNC_STMT, "cilk_sync_stmt", tcc_statement, 0)
 
+/* Wrapper to add a source code location to an expression, either one
+   that doesn't have one (such as an INTEGER_CST), or to a usage of a
+   variable (e.g. PARAM_DECL or VAR_DECL), where we want to record
+   the site in the source where the variable was *used* rather than
+   where it was declared.  */
+DEFTREECODE (LOCATION_EXPR, "location_expr", tcc_unary, 1)
+
 /*
 Local variables:
 mode:c