ODR use. These traits don't have a definition as they're intended to be
used strictly at compile time. Change the tests to use static_assert to
move the entire thing into compile-time.
llvm-svn: 291036
to make reference to template parameters. This is only a partial
implementation; we retain the restriction that the argument must not be
type-dependent, since it's unclear how that would work given the existence of
other language rules requiring an exact type match in this context, even for
type-dependent cases (a question has been raised on the core reflector).
llvm-svn: 290647
Summary:
I needed to know whether a FieldDecl had an in-class
initializer for D26453. I used a narrowing matcher there, but a
traversal matcher might be generally useful.
Reviewers: sbenza, bkramer, klimek, aaron.ballman
Subscribers: aaron.ballman, Prazek, cfe-commits
Differential Revision: https://reviews.llvm.org/D28034
llvm-svn: 290492
The unit tests in this patch demonstrate the need to traverse template
parameter lists of DeclaratorDecls (e.g. VarDecls, CXXMethodDecls) and
TagDecls (e.g. EnumDecls, RecordDecls).
Fixes PR29042.
https://reviews.llvm.org/D24268
Patch from Lukasz
Łukasz Anforowicz <lukasza@chromium.org>!
llvm-svn: 281345
It was failing because it had an explicit check for whether we're on
Windows.
There are a few other similar explicit checks in this file which I
didn't remove because they serve as reasonable documentation that the
test doesn't work with a Windows triple.
llvm-svn: 274269
Summary:
This test was stat()'ing large swaths of /usr/lib hundreds of times, as
every invocation of matchesConditionally*() created a new Linux
toolchain.
In addition to being slow, perf indicated this was causing substantial
contention in the kernel.
Something is...interesting in the kernel, as without this patch I
sometimes see ~11m spent in the kernel, and sometimes ~5m. This
corresponds to bimodal ninja check-clang times of ~30s and ~20s.
It's not clear to me exactly what causes the bimodality. In any case,
this change makes this test run in 2.5s, down from 17s, and it seems to
cause us to get the 20s ninja check-clang time unconditionally.
Reviewers: chandlerc
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D21810
llvm-svn: 274257
These ExprWithCleanups are added for holding a RunCleanupsScope not
for destructor calls; rather, they are for lifetime marks. This requires
ExprWithCleanups to keep a bit to indicate whether it have cleanups with
side effects (e.g. dtor calls).
Differential Revision: http://reviews.llvm.org/D20498
llvm-svn: 272296
Summary:
This AST matcher will match a given CastExpr kind.
It's an narrowing matcher on CastExpr.
Reviewers: klimek, alexfh, sbenza, aaron.ballman
Subscribers: Prazek, jroelofs, aaron.ballman, klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D19871
llvm-svn: 269460
Summary:
This patch is adding support for a matcher to check string literal length.
This matcher is used in clang-tidy checkers and is part of this refactoring:
see: http://reviews.llvm.org/D19841
Reviewers: sbenza, klimek, aaron.ballman
Subscribers: alexfh, klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D19876
llvm-svn: 269274
Summary: Matcher proposed in the review of checker misc-assign-operator (name pending). Its goal is to find the direct enclosing function declaration of a statement and run the inner matcher on it. Two version is attached in this patch (thus it will not compile), to be decided which approach to take. The second one always chooses one single parent while the first one does a depth-first search upwards (thus a height-first search) and returns the first positive match of the inner matcher (thus it always returns zero or one matches, not more). Further questions: is it enough to implement it in-place, or ASTMatchersInternals or maybe ASTMatchFinder should be involved?
Reviewers: sbenza
Subscribers: aaron.ballman, klimek, o.gyorgy, xazax.hun, cfe-commits
Differential Revision: http://reviews.llvm.org/D19357
llvm-svn: 268490
Summary:
Prevent hasAncestor from comparing nodes that are not supported.
hasDescendant was fixed some time ago to avoid this problem.
I'm applying the same fix to hasAncestor: if any object in the Builder map is
not comparable, skip the cache.
Reviewers: alexfh
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D19231
llvm-svn: 266748
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
Eric Liu