Commit Graph

119 Commits

Author SHA1 Message Date
Alexander Kornienko 027899dab6 Remove references to the ast_type_traits namespace
Follow up to cd62511496 /
https://reviews.llvm.org/D74499

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D92994
2020-12-11 00:58:46 +01:00
Aaron Ballman 819ff6b945 Improve dynamic AST matching diagnostics for conversion errors
Currently, when marshaling a dynamic AST matchers, we check for the type
and value validity of matcher arguments at the same time for some matchers.
For instance, when marshaling hasAttr("foo"), the argument is first type
checked to ensure it's a string and then checked to see if that string can
locate an attribute with that name. Similar happens for other enumeration
conversions like cast kinds or unary operator kinds. If the type is
correct but the value cannot be looked up, we make a best-effort attempt
to find a nearby name that the user might have meant, but if one cannot
be found, we throw our hands up and claim the types don't match.

This has an unfortunate behavior that when the user enters something of
the correct type but a best guess cannot be located, you get confusing
error messages like:
Incorrect type for arg 1. (Expected = string) != (Actual = String).

This patch splits the argument check into two parts: if the types don't
match, give a type diagnostic. If the type matches but the value cannot
be converted, give a best guess diagnostic or a value could not be
located diagnostic. This addresses PR47057.
2020-09-23 12:13:36 -04:00
Nathan James f51a319cac
[ASTMatchers] Enhanced support for matchers taking Regex arguments
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
2020-07-02 14:52:25 +01:00
Dmitri Gribenko b5fc1deb5b Use libClangTesting in the unittest for AST matchers
Summary:
The unittest for AST matchers has its own way to specify language
standards. I unified it with the shared infrastructure from
libClangTesting.

Reviewers: jdoerfert, hlopko

Reviewed By: hlopko

Subscribers: mgorny, sstefan1, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D81150
2020-06-04 17:40:39 +02:00
Stephen Kelly 8d62eba105 Add some explicit use of TK_AsIs 2020-05-23 01:04:44 +01:00
Stephen Kelly a30d411629 Set traversal explicitly where needed in tests
Reviewers: aaron.ballman, shafik

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D72531
2020-05-21 22:34:38 +01:00
Nathan James db71354e4f [ASTMatchers] Fixed CastKind being parsed incorrectly for dynamic matchers
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
2020-04-09 15:09:45 +01:00
Nathan James bf968e28ee [ASTMatchers] Add support for dynamic matching of ofKind narrowing matcher
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
2020-04-09 14:33:04 +01:00
Johannes Doerfert f9d558c871 [OpenMP] "UnFix" layering problem with FrontendOpenMP
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
2020-04-07 14:41:18 -05:00
Nathan James 427c1dc4f4 [ASTMatchers] Matchers that take enumerations args provide hints with invalid arguments
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
2020-04-06 20:00:30 +01:00
Johannes Doerfert 97aa593a83 [OpenMP] Fix layering problem with FrontendOpenMP
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
2020-04-06 13:04:26 -05:00
Johannes Doerfert 931c0cd713 [OpenMP][NFC] Move and simplify directive -> allowed clause mapping
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
2020-04-06 00:04:08 -05:00
Benjamin Kramer ddf77f10a3 One more batch of things found by g++ 6 2020-01-29 00:50:34 +01:00
Benjamin Kramer adcd026838 Make llvm::StringRef to std::string conversions explicit.
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.
2020-01-28 23:25:25 +01:00
David Green 170de3de2e [ParserTest] Move raw string literal out of macro
Some combinations of gcc and ccache do not deal well with raw strings in
macros. Moving the string out to attempt to fix the bots.
2020-01-05 11:24:04 +00:00
Stephen Kelly f0722333dd Allow newlines in AST Matchers in clang-query files
Reviewers: aaron.ballman

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D71842
2019-12-27 15:25:57 +00:00
Evgenii Stepanov 5ca97d0def Revert "Allow newlines in AST Matchers in clang-query files" + 1
Revert "Fix -Wunused-lambda-capture warnings."
This reverts commit 2369560f4a.
This reverts commit 522ee29a4f.

clang/lib/ASTMatchers/Dynamic/Parser.cpp:610:13: warning: implicit conversion turns string literal into bool: 'const char [35]' to 'bool' [-Wstring-conversion]
    assert(!"Newline should never be found here");
2019-12-26 18:07:20 -08:00
Stephen Kelly 522ee29a4f Allow newlines in AST Matchers in clang-query files
Reviewers: aaron.ballman

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D71842
2019-12-26 20:40:33 +00:00
Stephen Kelly 831b636861 Revert "Allow newlines in AST Matchers in clang-query files"
This reverts commit 6a3ecf4dc7.
2019-12-26 20:16:23 +00:00
Stephen Kelly 6a3ecf4dc7 Allow newlines in AST Matchers in clang-query files
Reviewers: aaron.ballman

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D71842
2019-12-26 20:00:59 +00:00
Jonas Devlieghere 2b3d49b610 [Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368942
2019-08-14 23:04:18 +00:00
Stephane Moore a0a47d8ac1 [clang] Update isDerivedFrom to support Objective-C classes 🔍
Summary:
This change updates `isDerivedFrom` to support Objective-C classes by
converting it to a polymorphic matcher.

Notes:
The matching behavior for Objective-C classes is modeled to match the
behavior of `isDerivedFrom` with C++ classes. To that effect,
`isDerivedFrom` matches aliased types of derived Objective-C classes,
including compatibility aliases. To achieve this, the AST visitor has
been updated to map compatibility aliases to their underlying
Objective-C class.

`isSameOrDerivedFrom` also provides similar behaviors for C++ and
Objective-C classes. The behavior that
`cxxRecordDecl(isSameOrDerivedFrom("X"))` does not match
`class Y {}; typedef Y X;` is mirrored for Objective-C in that
`objcInterfaceDecl(isSameOrDerivedFrom("X"))` does not match either
`@interface Y @end typedef Y X;` or
`@interface Y @end @compatibility_alias X Y;`.

Test Notes:
Ran clang unit tests.

Reviewers: aaron.ballman, jordan_rose, rjmccall, klimek, alexfh, gribozavr

Reviewed By: aaron.ballman, gribozavr

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D60543

llvm-svn: 368632
2019-08-12 23:23:35 +00:00
Tom Stellard 2e97d2aa1b cmake: Add CLANG_LINK_CLANG_DYLIB option
Summary:
Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against
libclang_shared.so instead of the individual component libraries.

Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru

Subscribers: arphaman, cfe-commits, llvm-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63503

llvm-svn: 365092
2019-07-03 22:45:55 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Fangrui Song 5313327f61 Add explicit dependency on clangSerialization for a bunch of components to fix -DBUILD_SHARED_LIBS=on build
This is a more thorough fix of rC348911.
The story about -DBUILD_SHARED_LIBS=on build after rC348907 (Move PCHContainerOperations from Frontend to Serialization) is:

1. libclangSerialization.so defines PCHContainerReader dtor, ...
2. clangFrontend and clangTooling define classes inheriting from PCHContainerReader, thus their DSOs have undefined references on PCHContainerReader dtor
3. Components depending on either clangFrontend or clangTooling cannot be linked unless they have explicit dependency on clangSerialization due to the default linker option -z defs. The explicit dependency could be avoided if libclang{Frontend,Tooling}.so had these undefined references.

This patch adds the explicit dependency on clangSerialization to make them build.

llvm-svn: 348915
2018-12-12 08:02:18 +00:00
Fangrui Song f7868ec25b Revert "[ASTMatchers] Fix DynamicASTMatchersTests again"
This reverts commit 8a6631a983ec9c1d22cc77c5f55a524a651740f0.

The last fix seems good in Debug mode.

llvm-svn: 343738
2018-10-03 22:56:26 +00:00
Fangrui Song f8c4f4e6e7 [ASTMatchers] Fix DynamicASTMatchersTests again
llvm-svn: 343722
2018-10-03 21:00:44 +00:00
Fangrui Song e154d4cbf5 [test] Fix -Wunused-variable in rC343665
llvm-svn: 343721
2018-10-03 20:53:53 +00:00
Stephen Kelly 7c787b8adf Allow comments with '#' in dynamic AST Matchers
Summary: This is necessary for clang-query to be able to handle comments.

Reviewers: aaron.ballman

Reviewed By: aaron.ballman

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D52751

llvm-svn: 343665
2018-10-03 07:56:43 +00:00
Shuai Wang e0248aecbe [ASTMatchers] Let isArrow also support UnresolvedMemberExpr, CXXDependentScopeMemberExpr
Reviewers: aaron.ballman

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D52157

llvm-svn: 342407
2018-09-17 18:48:43 +00:00
Stephen Kelly fc934cd916 Allow binding to NamedValue resulting from let expression
Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D51259

llvm-svn: 341142
2018-08-30 23:11:09 +00:00
Nico Weber f3e043f67b Make add_clang_unittest formatting a bit more consistent.
llvm-svn: 330839
2018-04-25 16:20:43 +00:00
George Karpenkov 88a16a0790 [ASTMatchers] Introduce a matcher for matching any given Objective-C selector
Incudes a tiny related refactoring.

Differential Revision: https://reviews.llvm.org/D44858

llvm-svn: 328747
2018-03-29 00:51:12 +00:00
George Karpenkov 9d1d0c4c57 [ASTMatchers] Extend hasParameter and hasAnyParameter matches to handle Objective-C methods
Differential Revision: https://reviews.llvm.org/D44707

llvm-svn: 328746
2018-03-29 00:51:11 +00:00
Shoaib Meenai d806af3499 [CMake] Use PRIVATE in target_link_libraries for executables
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.

Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.

Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).

Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.

Differential Revision: https://reviews.llvm.org/D40823

llvm-svn: 319840
2017-12-05 21:49:56 +00:00
Eric Christopher 04a26127c5 Use EXPECT_TRUE rather than EXPECT_EQ(true, ...) to clean up the code and silence a null conversion warning.
llvm-svn: 307989
2017-07-14 02:03:03 +00:00
Peter Wu 0f215dd8ae [ASTMatchers] temporary disable tests with floating suffix
r305022 assumed that floatLiteral(equals(1.2)) would also match 1.2f and
1.2l, but apparently that is not the case. Until it is clear how to
match, temporary disable the test to fix CI.

llvm-svn: 305025
2017-06-08 22:58:12 +00:00
Peter Wu a9244b57ff [ASTMatchers] Add clang-query support for equals matcher
Summary:
This allows the clang-query tool to use matchers like
"integerLiteral(equals(32))". For this to work, an overloaded function
is added for each possible parameter type.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D33094

llvm-svn: 305022
2017-06-08 22:00:58 +00:00
Peter Wu 2bbed50a45 [ASTMatchers] Add support for floatLiterals
Summary:
Needed to support something like "floatLiteral(equals(1.0))". The
parser for floating point numbers is kept simple, so instead of ".1" you
have to use "0.1".

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D33135

llvm-svn: 305021
2017-06-08 22:00:50 +00:00
Peter Wu c04b198c50 [ASTMatchers] Add support for boolean literals
Summary:
Recognize boolean literals for future extensions ("equals(true)").
Note that a specific VariantValue constructor is added to resolve
ambiguity (like "Value = 5") between unsigned and bool.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D33093

llvm-svn: 305020
2017-06-08 22:00:38 +00:00
Mehdi Amini 9670f847b8 [NFC] Header cleanup
Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <claprix@yandex.ru>

Differential Revision: https://reviews.llvm.org/D20100

llvm-svn: 275882
2016-07-18 19:02:11 +00:00
Benjamin Kramer cf236ec299 Prune away some unused using decls. NFC.
Found by clang's misc-unused-using-decls.

llvm-svn: 272156
2016-06-08 15:34:36 +00:00
Alexander Kornienko f11e099052 Reorder ASTNodeKind::AllKindInfo to match NodeKindId.
Summary:
AllKindInfo is being indexed by NodeKindId, so the order must match.
Extended ASTTypeTraits tests to cover this.

Reviewers: sbenza

Subscribers: cfe-commits, klimek

Differential Revision: http://reviews.llvm.org/D19059

llvm-svn: 266268
2016-04-14 00:47:40 +00:00
Aaron Ballman 7e7b7b2def Reapply r259210 with a fix for RegistryTest.cpp.
Patch by Richard Thomson.

llvm-svn: 259359
2016-02-01 14:11:47 +00:00
Chris Bieneman 2bf68c6c1c Remove autoconf support
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html

    "This is the way [autoconf] ends
    Not with a bang but a whimper."
    -T.S. Eliot

Reviewers: chandlerc, grosbach, bob.wilson, echristo

Subscribers: klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D16472

llvm-svn: 258862
2016-01-26 21:30:40 +00:00
Aaron Ballman 2b6963fce9 Add AST matcher support for FunctionDecls with the hasBody matcher.
Patch by Aleksei Sidorin.

llvm-svn: 258322
2016-01-20 16:26:48 +00:00
Aaron Ballman e8295d7980 Add AST matcher for paren expressions.
Patch by Adrian Zgorzałek.

llvm-svn: 258321
2016-01-20 16:17:39 +00:00
Benjamin Kramer 94355aeff8 [AST] Re-add TypeLocs and NestedNameSpecifierLocs to the ParentMap.
This relands r250831 after some fixes to shrink the ParentMap overall
with one addtional tweak: nodes with pointer identity (e.g. Decl* and
friends) can be store more efficiently so I put them in a separate map.
All other nodes (so far only TypeLoc and NNSLoc) go in a different map
keyed on DynTypedNode. This further uglifies the code but significantly
reduces memory overhead.

Overall this change still make ParentMap significantly larger but it's
nowhere as bad as before. I see about 25 MB over baseline (pre-r251008)
on X86ISelLowering.cpp. If this becomes an issue we could consider
splitting the maps further as DynTypedNode is still larger (32 bytes)
than a single TypeLoc (16 bytes) but I didn't want to introduce even
more complexity now.

Differential Revision: http://reviews.llvm.org/D14011

llvm-svn: 251101
2015-10-23 09:04:55 +00:00
Benjamin Kramer 998039e2f6 Shrink DynTypedNode by one pointer from 40 to 32 bytes (on x86_64).
The MemoizationData cache was introduced to avoid a series of enum
compares at the cost of making DynTypedNode bigger. This change reverts
to using an enum compare but instead of building a chain of comparison
the enum values are reordered so the check can be performed with a
simple greater than. The alternative would be to steal a bit from the
enum but I think that's a more complex solution and not really needed
here.

I tried this on several large .cpp files with clang-tidy and didn't
notice any performance difference. The test change is due to matchers
being sorted by their node kind.

Differential Revision: http://reviews.llvm.org/D13946

llvm-svn: 250905
2015-10-21 16:33:15 +00:00
Benjamin Kramer e8c51fdbd6 Revert "[AST] Put TypeLocs and NestedNameSpecifierLocs into the ParentMap."
Putting DynTypedNode in the ParentMap bloats its memory foot print.
Before the void* key had 8 bytes, now we're at 40 bytes per key which
can mean multiple gigabytes increase for large ASTs and this count
doesn't even include all the added TypeLoc nodes. Revert until I come
up with a better data structure.

This reverts commit r250831.

llvm-svn: 250889
2015-10-21 10:07:26 +00:00