Closed DeepakRautela02 closed 1 year ago
When you use the API's that descend into & through function calls into the bodies of those functions, you end up examining nodes from a different syntax tree than the original tree you started with. The purpose of descending through the call into the body of the called function is to search for symbols and other semantics. These can vary depending on the call site due to parameters or other let statements in scope before the call (for example the table function has dynamic scoping), but also that you may actually be descending into the body of a stored database function that is not even specified in your query. Because the symbols can vary due to call site, you almost always end up examining nodes from a different syntax tree in order to represent the different symbol information. In your case, you end up examining nodes from a syntax tree that is just a copy of the body of the method in the let statement, so all the positions are relative to just that body.
I don't think there is a good way currently to correlate those nodes back to nodes in the original syntax tree. However, that seems like a good improvement.
I've added the ability to get at the (until how hidden) SyntaxTree object from a SyntaxElement. A syntax tree now has a property Original that refers to the original tree that the tree may have been copied from and also an OffsetInOriginal property that tells you the start of the copied tree from its location in the original tree. So now you can know if the syntax node you are accessing comes from a copied subsection of another tree and figure out the position of that node within the original tree.
It is still possible that the node does not belong to the original query tree at all, since it could have come from a database function. You can attempt to compare the original syntax tree for the node to the query's syntax tree to see if they are the same.
In the above query, when we find tables in the query with the logic with the
fnDescend
delegate mentioned in the Readme.md, when the let statement view is parsed then theTextStart
property of the tableDeviceProcessEvents
is having the value 3, which is relative to the function body.Whereas the TextStart property represents
The position in the source where the element's first token starts
in its description. Which ideally should be giving the absolute index in the query for that table.