You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like nth is implemented by getting the parent, then getting the children on * axis, and finding the element in question.
This produces arguably unexpected cases where nth is called from within a filter on an axis with an id, e.g. I would expect
to find the 1st argument of the CallExpression (1-based indexing, ouch).
Instead, this query returns nothing, because the 1st child of the CallExpression on axis * is actually the function that was called, located on .callee.
What now? Always just +1 the parameter for nth in this case? Not pretty, and doesn't work on ast nodes with multiple variable-length child arrays.
While testing this, I've also found that
/ ExpressionStatement / CallExpression / *
finds 'Identifier', 'Literal', 'ExpressionStatement':
What is happening here? Why is ExpressionStatement, which is the parent of the CallExpression, being matched by this Query?
The readme defines the / Axis as:
/ for direct child nodes
Edit: Turns out this last part is likely caused by astq considering the parent property (which I populated on my mozast to get nth to work) as a valid child axis.
The text was updated successfully, but these errors were encountered:
none of the inbuilt adapters support named parent axis
such a thing would generally not make sense in a tree AST
most of the inbuilt adapters do not support getParentNode at all
it may be a good idea to fully move away from this function. Keeping a parent stack to the current position in the Tree at all times would make the function fully obsolete, and remove any need for a parent property on nodes.
Unfortunately it seems like this library is not updated anymore, aside from basic dependency updates.
astq/src/astq-funcs-std.js
Lines 75 to 86 in ea8d5c8
It seems like
nth
is implemented by getting the parent, then getting the children on*
axis, and finding the element in question.This produces arguably unexpected cases where
nth
is called from within a filter on an axis with an id, e.g. I would expectrunning on the input ast of
to find the 1st argument of the CallExpression (1-based indexing, ouch).
Instead, this query returns nothing, because the 1st child of the CallExpression on axis
*
is actually the function that was called, located on.callee
.What now? Always just
+1
the parameter fornth
in this case? Not pretty, and doesn't work on ast nodes with multiple variable-length child arrays.While testing this, I've also found that
finds
'Identifier', 'Literal', 'ExpressionStatement'
:What is happening here? Why is ExpressionStatement, which is the parent of the CallExpression, being matched by this Query?
The readme defines the
/
Axis as:/
for direct child nodesEdit: Turns out this last part is likely caused by astq considering the
parent
property (which I populated on my mozast to getnth
to work) as a valid child axis.The text was updated successfully, but these errors were encountered: