> > 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
