> On Thu, May 08, 2025 at 02:22:00PM GMT, Michael Paquier wrote:
> On Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote:
> > Ah, I see what you mean. I think the idea is fine, it will simplify
> > certain things as well as address the issue. But I'm afraid adding
> > start/end location to A_Expr is a bit too invasive, as it's being used
> > for many other purposes. How about introducing a new expression for this
> > purposes, and use it only in in_expr/array_expr, and wrap the
> > corresponding expressions into it? This way the change could be applied
> > in a more targeted fashion.
>
> Yes, that feels invasive. The use of two static variables to track
> the start and the end positions in an expression list can also be a
> bit unstable to rely on, I think. It seems to me that this part
> could be handled in a new Node that takes care of tracking the two
> positions, instead, be it a start/end couple or a location/length
> couple? That seems necessary to have when going through
> jumbleElements().
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.