This reverts rL352390 / D57280.
As discussed in https://reviews.llvm.org/D57112#inline-506781,
'flush' clause does not exist in the OpenMP spec, it can not be
specified, and OMPFlushClause class is just a helper class.
Now, here's the caveat. I have read @ABataev's
Well, I think it would be good to filter out OMPC_flush somehow
because there is no such clause actually, it is a pseudo clause
for better handling of the flush directive.
as if that clause is pseudo clause that only exists for the sole
purpose of simplifying the parser. As in, it never reaches AST.
I did not however try to verify that. Too bad, i was wrong.
It absolutely *does* reach AST. Therefore my understanding/justification
for the change was flawed, which makes the patch a regression which must be reverted.
@gribozavr has brought that up again in https://reviews.llvm.org/D57112#inline-521238
...
Sorry to be late for this discussion, but I don't think this conclusion
follows. ASTMatchers are supposed to match the AST as it is.
Even if OMPC_flush is synthetic, it exists in the AST, and users might
want to match it. I think users would find anything else (trying to filter
out AST nodes that are not in the source code) to be surprising. For example,
there's a matcher materializeTemporaryExpr even though this AST node is a
Clang invention and is not a part of the C++ spec.Matching only constructs that appear in the source code is not feasible with
ASTMatchers, because they are based on Clang's AST that exposes tons of semantic
information, and its design is dictated by the structure of the semantic information.
See "RFC: Tree-based refactorings with Clang" in cfe-dev for a library that will
focus on representing source code as faithfully as possible.Not to even mention that this code is in ASTTypeTraits, a general library for
handling AST nodes, not specifically for AST Matchers...