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
We need to support an incrementing node_id integer on every node allocation. This is used to power error_highlight, but also other tools like action view.
The text was updated successfully, but these errors were encountered:
Is there maybe another way these 2 usages could do what they do once they migrate to Prism? (they will need to change anyway since they use the experimental unstable RubyVM::AbstractSyntaxTree).
I guess the fundamental need is to identify a call node from a bytecode.
One idea to avoid the need to take/waste that space for every node would be to implicitly number all nodes by their order in the tree with some defined traversal (e.g. pre-order). Then to find node id N, we'd iterate nodes, incrementing our id counter for every node visited, and assuming they are the same nodes in the same order (which is very much what these usages need to assume to work), then return that nth node. E.g. by having some method on ParseResult making this easy.
We need to support an incrementing
node_id
integer on every node allocation. This is used to powererror_highlight
, but also other tools like action view.The text was updated successfully, but these errors were encountered: