On Thu, May 8, 2025 at 2:36 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>
> > 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.
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.
--
Sami
