| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
within part of a particular method.
llvm-svn: 163397
|
| |
|
|
| |
llvm-svn: 163394
|
| |
|
|
| |
llvm-svn: 163389
|
| |
|
|
| |
llvm-svn: 163388
|
| |
|
|
| |
llvm-svn: 163387
|
| |
|
|
|
|
|
|
| |
This allows linking to LibASTMatchersRefernce.html#<matcher><N>Anchor to
link to the N'the declaration of a matcher and automatically expand
its documentation.
llvm-svn: 163386
|
| |
|
|
|
|
|
|
|
|
|
|
| |
class itself. This caused some confusion (intuitively, a class is not
derived from itself) and makes it hard to write certain matchers, e.g.
"match and bind any pair of base and subclass".
The original behavior can be achieved with a new isA-matcher. Similar
to all other matchers, this matcher has the same behavior and name as
the corresponding AST-entity - in this case the isa<>() function.
llvm-svn: 163385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements the hasAncestor matcher. This builds
on the previous patch that introduced DynTypedNode to build up
a parent map for an additional degree of freedom in the AST traversal.
The map is only built once we hit an hasAncestor matcher, in order
to not slow down matching for cases where this is not needed.
We could implement some speed-ups for special cases, like building up
the parent map as we go and only building up the full map if we break
out of the already visited part of the tree, but that is probably
not going to be worth it, and would make the code significantly more
complex.
Major TODOs are:
- implement hasParent
- implement type traversal
- implement memoization in hasAncestor
llvm-svn: 163382
|
| |
|
|
|
|
| |
Apparently the output of this test is not deterministic. Needs investigation.
llvm-svn: 163377
|
| |
|
|
|
|
|
|
|
| |
While the check itself should count 0-based for the parameter index,
the diagnostic should be 1-based (first, second, third, not start at 0).
Fixes <rdar://problem/12249569>.
llvm-svn: 163375
|
| |
|
|
|
|
|
|
| |
(as this previously was the case before this was refactored). We also shouldn't
need to specially handle BinaryOperators since the eagerly-assume heuristic tags
such nodes.
llvm-svn: 163374
|
| |
|
|
|
|
|
|
|
|
| |
of the analyzer, as the RetainReleaseChecker has many fine-grain
path diagnostic events that were not being checked. This uncovered
an inconsistency between the path diagnostics between Objective-C
and Objective-C++ code in ConditionBRVisitor that was fixed in a recent
patch.
llvm-svn: 163373
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implicit pointer-to-boolean conversions in condition expressions. This would
result in inconsistent diagnostic emission between C and C++.
A consequence of this is now ConditionBRVisitor and TrackConstraintBRVisitor may
emit redundant diagnostics, for example:
"Assuming pointer value is null" (TrackConstraintBRVisitor)
"Assuming 'p' is null" (ConditionBRVisitor)
We need to reconcile the two, and perhaps prefer one over the other in some
cases.
llvm-svn: 163372
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
unexpanded parameter pack is a pack expansion. Thus, as with a non-type template
parameter which is a pack expansion, it needs to be expanded early into a fixed
list of template parameters.
Since the expanded list of template parameters is not itself a parameter pack,
it is permitted to appear before the end of the template parameter list, so also
remove that restriction (for both template template parameter pack expansions and
non-type template parameter pack expansions).
llvm-svn: 163369
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With some particularly evil casts, we can get an object whose dynamic type
is not actually a subclass of its static type. In this case, we won't even
find the statically-resolved method as a devirtualization candidate.
Rather than assert that this situation cannot occur, we now simply check
that the dynamic type is not an ancestor or descendent of the static type,
and leave it at that.
This error actually occurred analyzing LLVM: CallEventManager uses a
BumpPtrAllocator to allocate a concrete subclass of CallEvent
(FunctionCall), but then casts it to the actual subclass requested
(such as ObjCMethodCall) to perform the constructor.
Yet another crash in PR13763.
llvm-svn: 163367
|
| |
|
|
|
|
|
|
| |
return a CF object at all.
Fixes <rdar://problem/9566345>
llvm-svn: 163362
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A bizarre series of coincidences led us to generate a previously-seen
node in the middle of processing an Objective-C message, where we assume
the receiver is non-nil. We were assuming that such an assumption would
never "cache out" like this, and blithely went on using a null ExplodedNode
as the predecessor for the next step in evaluation.
Although the test case committed here is complicated, this could in theory
happen in other ways as well, so the correct fix is just to test if the
non-nil assumption results in an ExplodedNode we've seen before.
<rdar://problem/12243648>
llvm-svn: 163361
|
| |
|
|
| |
llvm-svn: 163358
|
| |
|
|
| |
llvm-svn: 163357
|
| |
|
|
|
|
|
|
| |
via function/method with [CF,NS]_RETURNS_NOT_RETAINED.
Fixes <rdar://problem/11379000>.
llvm-svn: 163355
|
| |
|
|
|
|
|
|
|
| |
are used in EH code. Right now the CFG doesn't support exceptions well,
so we need this hack to avoid bogus dead store warnings.
Fixes <rdar://problem/12147586>
llvm-svn: 163353
|
| |
|
|
| |
llvm-svn: 163350
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CXXDestructorCall now has a flag for when it is a base destructor call.
Other kinds of destructor calls (locals, fields, temporaries, and 'delete')
all behave as "whole-object" destructors and do not behave differently
from one another (specifically, in these cases we /should/ try to
devirtualize a call to a virtual destructor).
This was causing crashes in both our internal buildbot, the crash still
being tracked in PR13765, and some of the crashes being tracked in PR13763,
due to a assertion failure. (The behavior under -Asserts happened to be
correct anyway.)
Adding this knowledge also allows our DynamicTypePropagation checker to do
a bit less work; the special rules about virtual method calls during a
destructor only require extra handling during base destructors.
llvm-svn: 163348
|
| |
|
|
|
|
|
| |
handle. Otherwise, the AsmParser will explode if we try to generate an
object files.
llvm-svn: 163345
|
| |
|
|
|
|
|
| |
and output expressions much like that in GNU-style inline assembly. Output
expressions are first. Do this for MS-style inline asms.
llvm-svn: 163342
|
| |
|
|
|
|
| |
// rdar://12233989
llvm-svn: 163338
|
| |
|
|
|
|
| |
crash in a corner case. Patch by Olivier Goffart!
llvm-svn: 163337
|
| |
|
|
|
|
|
|
|
| |
This patch uses a new ABIInfo implementation specific to the le32
target, rather than falling back to DefaultABIInfo. Its behavior is
basically the same, but it also allows the regparm argument attribute.
It also includes basic tests for argument codegen and attributes.
llvm-svn: 163333
|
| |
|
|
|
|
| |
ifdef'ed out. This change is required to support enhancements in the LLDB data formatters
llvm-svn: 163331
|
| |
|
|
|
|
| |
Patch thanks to Joe Ranieri!
llvm-svn: 163330
|
| |
|
|
|
|
|
| |
Don't warn if annotated decl is used inside another
unused. // rdar://12233989
llvm-svn: 163329
|
| |
|
|
|
|
|
| |
These tests were failing for me because the .* was greedily matching up
to the /libexec/ld-elf.so.1" later on the same line.
llvm-svn: 163328
|
| |
|
|
| |
llvm-svn: 163327
|
| |
|
|
| |
llvm-svn: 163325
|
| |
|
|
| |
llvm-svn: 163303
|
| |
|
|
|
|
| |
Caught by Kurt Arnlund!
llvm-svn: 163286
|
| |
|
|
|
|
| |
don't trample over the caller's LookupResult in the case where the check fails.
llvm-svn: 163281
|
| |
|
|
|
|
| |
As per Jordan's suggestion. (Came out of code review for r163261.)
llvm-svn: 163269
|
| |
|
|
|
|
| |
...and hopefully unbreak buildbots. My apologies!
llvm-svn: 163267
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These types are defined differently on 32-bit and 64-bit platforms, and
trying to offer a fixit for one platform would only mess up the format
string for the other. The Apple-recommended solution is to cast to a type
that is known to be large enough and always use that to print the value.
This should only have an impact on compile time if the format string is
incorrect; in cases where the format string matches the definition on the
current platform, no warning will be emitted.
<rdar://problem/9135072&12164284>
llvm-svn: 163266
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 163265
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While destructors will continue to not be inlined (unless the analyzer
config option 'c++-inlining' is set to 'destructors'), leaving them out
of the CFG is an incomplete model of the behavior of an object, and
can cause false positive warnings (like PR13751, now working).
Destructors for temporaries are still not on by default, since
(a) we haven't actually checked this code to be sure it's fully correct
(in particular, we probably need to be very careful with regard to
lifetime-extension when a temporary is bound to a reference,
C++11 [class.temporary]p5), and
(b) ExprEngine doesn't actually do anything when it sees a temporary
destructor in the CFG -- not even invalidate the object region.
To enable temporary destructors, set the 'cfg-temporary-dtors' analyzer
config option to '1'. The old -cfg-add-implicit-dtors cc1 option, which
controlled all implicit destructors, has been removed.
llvm-svn: 163264
|
| |
|
|
| |
llvm-svn: 163262
|
| |
|
|
|
|
|
|
|
| |
If a region is binded to a symbolic value, we should track the symbol.
(The code I changed was not previously exercised by the regression
tests.)
llvm-svn: 163261
|
| |
|
|
|
|
|
| |
This region is set as interesting as part of trackNullOrUndefValue call,
no need to mark it as interesting twice.
llvm-svn: 163260
|
| |
|
|
| |
llvm-svn: 163253
|
| |
|
|
| |
llvm-svn: 163252
|
| |
|
|
|
|
| |
Patch by Brooks Davis.
llvm-svn: 163249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment, we implictly check compatibility between the python
bindings and libclang, as the python bindings will fail to load in
case a method we use in libclang is not available.
This patch makes the use of this compatibility check explicit and introduces a
flag to optionally disable the check. This will allow us to further harden the
compatibility check, but it also gives the user the possibility to disable the
compatibility check to evaluate compatibility with older libclang versions.
I added documentation that makes clear the python bindings are only tested
with the libclang version they have been shipped with.
llvm-svn: 163238
|
| |
|
|
|
|
| |
expression involving temporaries.
llvm-svn: 163237
|