I have noticed that ASTMatchers do not include anything to help determine the happens-before relationship
syntactically: that is, whether element A occurs before B during in-order traversal of the AST.
Such matching would be necessarily very imprecise (e.g. confused by goto’s, etc.),
but could actually be very useful in places where control flow elements are not anticipated
(or in places where “grep” is an only alternative, and a person writing the matcher would not
mind the presence of false positives or false negatives).
It seems it could be easily implemented by having a “consuming” matcher, e.g.
matchDescendantsConsuming(A, B, C)
would match A, but then start matching B from the place where it left of after A was matched, etc.
Would a patch adding such a matcher be accepted?
Is lack of ordering-aware matchers a conscious design decision?