This is an archive of the discontinued LLVM Phabricator instance.

[clang][OpenMP] Revert "OMPFlushClause is synthetic, no such clause exists"
ClosedPublic

Authored by lebedev.ri on Mar 5 2019, 9:22 AM.

Details

Summary

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...

Diff Detail

Repository
rL LLVM

Event Timeline

lebedev.ri created this revision.Mar 5 2019, 9:22 AM
lebedev.ri added a project: Restricted Project.Mar 5 2019, 9:24 AM
ABataev accepted this revision.Mar 5 2019, 9:43 AM

Hmm, do we really need the matches for the AST node that is not described/defined by the standard? If this is really so, I'm ok with this.

This revision is now accepted and ready to land.Mar 5 2019, 9:43 AM
gribozavr accepted this revision.Mar 5 2019, 10:03 AM

Hmm, do we really need the matches for the AST node that is not described/defined by the standard? If this is really so, I'm ok with this.

When the rubber meets the road, it does not matter what is in the spec, users will need to work with the ASTs that they get. If there's something in the AST, users will want to match it.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 5 2019, 11:45 PM