Optionally keeping token locations in `TreeTraversingParser`

[indyteo]

Is your feature request related to a problem? Please describe.

Currently, the TreeTraversingParser always returns TokenStreamLocation.NA when calling current[Token]Location().
https://github.com/FasterXML/jackson-databind/blob/3.x/src/main/java/tools/jackson/databind/node/TreeTraversingParser.java#L180C5-L188C6
Thus, locations are lost if doing parser = context.treeAsTokens(parser.readValueAsTree()) (obviously no one would just do that like this, but it is the most simple way to illustrate that).

The location is particularly relevant for error messages, and in that scenario all subsequent errors would be harder to debug without that info.

Describe the solution you'd like

If the JsonNode class had an optional field to refer to its origin as a TokenStreamLocation, it would be possible for the BaseNodeDeserializer to fill that field automatically when deserializing the tree.
Then, the TreeTraversingParser would be able to use that info to provide accurate locations instead.

If we consider that it could have an impact on performance to compute that extra info (which I believe is already precomputed anyway, at least in YAML I've looked at the code, and the SnakeYAML engine already have the Mark in each event), a DeserializationFeature toggle could be added to control whether to keep that info or not.

Usage example

Usage wouldn't be any different from how it can be done now, it would just maybe return something useful (and still nothing otherwise, it would be a kind of "best-effort").

Additional context

If you are ok about this feature being added, I can contribute it. I've already dived into the code to analyze whether it was already possible right now, and have a pretty clear vision of what would need to change (and I believe it's not that much).

Thanks

[cowtowncoder]

I can see usefulness of such a feature, but I am not sure of feasibility: note that a few JsonNode types (NullNode, BooleanNode, MissingNode) are "light-weight" values, sharing limited set of pre-created instances. So it is not possible to just add mutable location field, for example.

Maybe withLocation(TokenStreamLocation) method could be added... but this can get pretty complicated.

[indyteo]

Hmm, interesting. I was not aware of the existence of immutable node types. Yeah, maybe .withLocation(...) creating a new instance with the given location, and having a DeserializationFeature toggle flag off by default so it does not impact performances of existing applications.
What do you think would be the complication you're talking about? Simply having to modify each subclass of JsonNode? Again, it would be a "best-effort", so when location is not available, then no location is available, period. Currently, there are NO LOCATION AT ALL, so basically anything would be better 😄
I could give that a try, and see how it turns out, maybe.

[cowtowncoder]

Technically all scalar JsonNodes (NumberNodes, StringNode) are immutable, come to think of it. Only Array/ObjectNodes are mutable.

But. Yes, trying things out would be useful, to see kinds of things you uncover.

Feature to use would be JsonNodeFeature (instead of general DeserializationFeature) fwtw.

I also think ability to keep track of TokenStreamLocation for JsonNode would be appreciated by many developers so it'd be a Good Thing. As long as overhead in non-tracking case is nominal.