microsoft / Kusto-Query-Language

Kusto Query Language is a simple and productive language for querying Big Data.
Apache License 2.0
510 stars 97 forks source link

Wrong TextStart index reported for the function body. #88

Closed DeepakRautela02 closed 1 year ago

DeepakRautela02 commented 1 year ago
let ProcessQuery = view()
{
DeviceProcessEvents
| where Timestamp > ago(30d)
};
ProcessQuery

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 the TextStart property of the table DeviceProcessEvents is having the value 3, which is relative to the function body.

image

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.

mattwar commented 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.

mattwar commented 1 year ago

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.