On Wed, Dec 3, 2025, at 1:47 AM, Liam Miller-Cushon wrote: > My feeling is that perhaps it's worth the extra memory to not have to > duplicate that code for all of those `JCTree`s, and also to avoid the risk of > trying to store end positions on trees that don't support it. But I am open > to making those changes if there's a preference for it.
Yeah, you've done the analysis I think I would have done. And, it does seem l;ke there has been a fundamental shift in the desire/need to keep end positions around since times past. Simplicity says to go with a field in every JCTree these days. A more informed opinion would probably require more detailed analysis. I note that you can offset the space of the endPos fields that are not strictly required against the savings of the EndPosTable itself. I also wonder, just for curiousity sake, whether this would help with some of the (uncommon) problem cases in the existing situation, where the endPos of a non-terminal end element might not be the endPos of the entire tree -- IIRC, the issue was with C-style array declarations. The one test I would suggest to add (if necessary) in the "tree position" set of tests would be to verify that the new field is set in all applicable cases, with maybe some thought being given to synthetic nodes. -- Jon
