MOS-1852: Fix pattern construction to preserve actions after filters #34
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cool Story:
In the core of the project, we use three main entities: the syntax tree (Tree), the differential tree (DiffTree, inherited from Tree), and the pattern (Pattern, inherited from Tree). Essentially, the pattern is a differential tree with holes, and the differential tree is just a regular tree with actions. The expected flow is: first, we obtain a pair of "regular" trees from the parser, then build a differential tree from them, and finally perforate the differential tree to create a pattern.
This setup worked well until we started applying filters to the differential tree before perforation. The filters involve extracting subtrees from the original differential tree, and potentially extracting subtrees from these subtrees multiple times. The problem arises because the subtree node is not technically a node of the differential tree; it's a SubtreeNode object. In other words, the Action object is replaced by a SubtreeNode, which contains an Action object. In some cases, this nesting level increases (a SubtreeNode contains another SubtreeNode, which contains an Action), causing us to lose actions when constructing the pattern. The result is a pattern with holes but no actions. This is a bug.
To fix this, we need to properly build the pattern, taking into account that an Action can, in some cases, be a prototype of a PrototypeBasedNode.
Task:
Correct the pattern construction process to ensure that actions are preserved even after applying filters to the differential tree. Specifically, when building the pattern, we need to account for the possibility that an Action might be a prototype of a PrototypeBasedNode.