This implements the default(firstprivate) clause as defined in OpenMP
Technical Report 8 (2.22.4).
Reviewed By: jdoerfert, ABataev
Differential Revision: https://reviews.llvm.org/D75591
Adds a matcher called `hasDirectBase` for matching the `CXXBaseSpecifier` of a class that directly derives from another class.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D81552
In general there is no way to get to the ASTContext from most AST nodes
(Decls are one of the exception). This will be a problem when implementing
the rest of APValue::dump since we need the ASTContext to dump some kinds of
APValues.
The ASTContext* in ASTDumper and TextNodeDumper is not always non-null.
This is because we still want to be able to use the various dump() functions
in a debugger.
No functional changes intended.
Reverted in fcf4d5e449 since a few dump()
functions in lldb where missed.
In general there is no way to get to the ASTContext from most AST nodes
(Decls are one of the exception). This will be a problem when implementing
the rest of APValue::dump since we need the ASTContext to dump some kinds of
APValues.
The ASTContext* in ASTDumper and TextNodeDumper is not always
non-null. This is because we still want to be able to use the various
dump() functions in a debugger.
No functional changes intended.
Added new Macros `AST(_POLYMORPHIC)_MATCHER_REGEX(_OVERLOAD)` that define a matchers that take a regular expression string and optionally regular expression flags. This lets users match against nodes while ignoring the case without having to manually use `[Aa]` or `[A-Fa-f]` in their regex. The other point this addresses is in the current state, matchers that use regular expressions have to compile them for each node they try to match on, Now the regular expression is compiled once when you define the matcher and used for every node that it tries to match against. If there is an error while compiling the regular expression an error will be logged to stderr showing the bad regex string and the reason it couldn't be compiled. The old behaviour of this was down to the Matcher implementation and some would assert, whereas others just would never match. Support for this has been added to the documentation script as well. Support for this has been added to dynamic matchers ensuring functionality is the same between the 2 use cases.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D82706
D80025 introduced a performance regression: in some cases, it makes
clang-tidy readability-container-size-empty ~80x slower (running on an internal
huge TU, before that patch 12s vs after 950s).
after this patch, we go back to 12s.
Differential Revision: https://reviews.llvm.org/D82771
Summary:
As discussed previously when landing patch for OpenMP in Flang, the idea is
to share common part of the OpenMP declaration between the different Frontend.
While doing this it was thought that moving to tablegen instead of Macros will also
give a cleaner and more powerful way of generating these declaration.
This first part of a future series of patches is setting up the base .td file for
DirectiveLanguage as well as the OpenMP version of it. The base file is meant to
be used by other directive language such as OpenACC.
In this first patch, the Directive and Clause enums are generated with tablegen
instead of the macros on OMPConstants.h. The next pacth will extend this
to other enum and move the Flang frontend to use it.
Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp
Reviewed By: jdoerfert, jdenny
Subscribers: arphaman, martong, cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits
Tags: #llvm, #openmp, #clang
Differential Revision: https://reviews.llvm.org/D81736
Summary:
In ASTMatcher, when we have `has(...)` and `hasParent(...)` called with the same internal matcher on the same node, the memoization process will mix-up the two calls because the direction of the traversal is not part of the memoization key.
This patch adds this information.
Reviewers: klimek
Reviewed By: klimek
Subscribers: Godin, njames93, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80025
...enumerations from TokenKinds.def and use the new macros from TokenKinds.def
to remove the hard-coded lists of traits.
All the information needed to generate these enumerations is already present
in TokenKinds.def. The motivation here is to be able to dump the trait spelling
without hard-coding the list in yet another place.
Note that this change the order of the enumerators in the enumerations (except
that in the TypeTrait enumeration all unary type traits are before all binary
type traits, and all binary type traits are before all n-ary type traits).
Apart from the aforementioned ordering which is relied upon, after this patch
no code in clang or in the various clang tools depend on the specific ordering
of the enumerators.
No functional changes intended.
Differential Revision: https://reviews.llvm.org/D81455
Reviewed By: aaron.ballman
Summary:
This patch exposes `TraversalKind` support in the `DynTypedMatcher` API. While
previously, the `match` method supported traversal logic, it was not possible to
set or get the traversal kind.
Reviewers: gribozavr, steveire
Subscribers: hokein, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80685
Summary: Adds a matcher called `hasOperands` for `BinaryOperator`'s when you need to match both sides but the order isn't important, usually on commutative operators.
Reviewers: klimek, aaron.ballman, gribozavr2, alexfh
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80054
Summary:
This patch adds support for importing fixed point literals, following
up to https://reviews.llvm.org/D46915 specifically for importing AST.
Reviewers: martong, leonardchan, ebevhan, a.sidorin, shafik
Reviewed By: martong
Subscribers: balazske, rnkovacs, teemperor, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77721
Summary: Requires hasCastKind arguments to have `CK_` prefixed to bring it in line with the documentation and other matchers that take enumerations.
Reviewers: klimek, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77503
Summary: Adds support for using the ofKind in clang-query and other dynamic matcher use cases
Reviewers: klimek, aaron.ballman, jdoerfert
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77791
This reverts commit 97aa593a83 as it
causes problems (PR45453) https://reviews.llvm.org/D77574#1966321.
This additionally adds an explicit reference to FrontendOpenMP to
clang-tidy where ASTMatchers is used.
This is hopefully just a temporary solution. The dependence on
`FrontendOpenMP` from `ASTMatchers` should be handled by CMake
implicitly, not us explicitly.
Reviewed By: aheejin
Differential Revision: https://reviews.llvm.org/D77666
Summary:
This adds support for giving hints when using dynamic matchers with enum args. Take this query, I couldn't figure out why the matcher wasn't working:
(Turns out it needed to be "IntegralToBoolean", but thats another bug itself)
```
clang-query> match implicitCastExpr(hasCastKind("CK_IntegralToBoolean"))
1:1: Error parsing argument 1 for matcher implicitCastExpr.
1:18: Error building matcher hasCastKind.
1:30: Incorrect type for arg 1. (Expected = string) != (Actual = String)
```
With this patch the new behaviour looks like this:
```
clang-query> match implicitCastExpr(hasCastKind("CK_IntegralToBoolean"))
1:1: Error parsing argument 1 for matcher implicitCastExpr.
1:18: Error building matcher hasCastKind.
1:30: Unknown value 'CK_IntegralToBoolean' for arg 1; did you mean 'IntegralToBoolean'
```
There are no test cases for this yet as there simply isn't any infrastructure for testing errors reported when parsing args that I can see.
Reviewers: klimek, jdoerfert, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: aaron.ballman, dexonsmith, mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77499
Summary:
ASTMatchers is used in various places and it now exposes the
LLVMFrontendOpenMP library to its users without them needing to depend
on it explicitly.
Reviewers: lebedev.ri
Subscribers: mgorny, yaxunl, bollu, guansong, martong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77574
Move the listing of allowed clauses per OpenMP directive to the new
macro file in `llvm/Frontend/OpenMP`. Also, use a single generic macro
that specifies the directive and one allowed clause explicitly instead
of a dedicated macro per directive.
We save 800 loc and boilerplate for all new directives/clauses with no
functional change. We also need to include the macro file only once and
not once per directive.
Depends on D77112.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D77113
This is a cleanup and normalization patch that also enables reuse with
Flang later on. A follow up will clean up and move the directive ->
clauses mapping.
Reviewed By: fghanim
Differential Revision: https://reviews.llvm.org/D77112
This is a cleanup and normalization patch that also enables reuse with
Flang later on. A follow up will clean up and move the directive ->
clauses mapping.
Differential Revision: https://reviews.llvm.org/D77112
Summary:
Currently, `optionally` can take multiple arguments, which commits it to a
particular strategy for those arguments (in this case, "for each"). We limit the
matcher to a single argument, which avoids any potential confusion and
simplifies the implementation. The user can retrieve multiple-argument
optionality, by explicitly using the desired operator (like `forEach`, `anyOf`,
`allOf`, etc.) with all children wrapped in `optionally`.
Reviewers: sbenza, aaron.ballman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D75556
Summary: The implementation of 'optionally' doesn't preserve bindings when none of the submatchers succeed. This patch adds a regression test for that behavior and fixes it.
Reviewers: aaron.ballman, sbenza
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D75365
Summary:
Acts on `BinaryOperator` and `UnaryOperator` and functions the same as `anyOf(hasOperatorName(...), hasOperatorName(...), ...)`
Documentation generation isn't perfect but I feel that the python doc script needs updating for that
Reviewers: aaron.ballman, gribozavr2
Reviewed By: aaron.ballman, gribozavr2
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D75040
Summary:
This revision adds matchers that match calls to the gtest EXPECT and ASSERT
macros almost like function calls. The matchers are placed in separate files
(GtestMatchers...), because they are specific to the gtest library.
Reviewers: gribozavr2
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74840
DynTypedNode and ASTNodeKind are implemented as part of the clang AST
library, which uses the main clang namespace. There doesn't seem to be a
need for this extra level of namespacing.
I left behind aliases in the ast_type_traits namespace for out of tree
clients of these APIs. To provide aliases for the enumerators, I used
this pattern:
namespace ast_type_traits {
constexpr TraversalKind TK_AsIs = ::clang::TK_AsIs;
}
I think the typedefs will be useful for migration, but we might be able
to drop these enumerator aliases.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D74499
Summary: Spells out some `auto`s explicitly and adds another test for the matcher `isExpandedFromMacro`.
Reviewers: aaron.ballman
Subscribers: gribozavr, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73975
Summary:
This revision adds a matcher `isExpandedFromMacro` that determines whether a
statement is (transitively) expanded from a given macro.
Reviewers: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73965
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Zahira Ammarguellat