> > To clarify, I had in mind something like in the attached patch. The
> > idea is to make start/end location capturing relatively independent from
> > the constants squashing. The new parsing node conveys the location
> > information, which is then getting transformed to be a part of an
> > ArrayExpr. It's done for in_expr only here, something similar would be
> > needed for array_expr as well. Feedback is appreciated.
>
> Thanks! I took a quick look at v1-0001 and it feels like a much better approach
> than the quick hack I put together earlier. I will look thoroughly.
I took a look at v1-0001 and I am wondering if this can be further simplified.
We really need a new Node just to wrap the start/end locations of the List
coming from the in_expr and this node should not really be needed past parsing.
array_expr is even simpler because we have the boundaries available
when makeAArrayExpr is called.
So, I think we can create a new parse node ( parsenode.h ) that will only be
used in parsing (and gram.c only ) to track the start/end locations
and List and
based on this node we can create A_ArrayExpr and A_Expr with the List
of boundaries,
and then all we have to do is update ArrayExpr with the boundaries during
the respective transformXExpr call. This seems like a much simpler approach
that also addresses Michael's concern of defining static variables in gram.y to
track the boundaries.
what do you think?
--
Sami
