• Home
  • History
  • Annotate
  • only in /external/clang/test/Analysis/inlining/
History log of /external/clang/test/Analysis/inlining/
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
ef8225444452a1486bd721f3285301fe84643b00 21-Jul-2014 Stephen Hines <srhines@google.com> Update Clang for rebase to r212749.

This also fixes a small issue with arm_neon.h not being generated always.

Includes a cherry-pick of:
r213450 - fixes mac-specific header issue
r213126 - removes a default -Bsymbolic on Android

Change-Id: I2a790a0f5d3b2aab11de596fc3a74e7cbc99081d
651f13cea278ec967336033dd032faef0e9fc2ec 24-Apr-2014 Stephen Hines <srhines@google.com> Updated to Clang 3.5a.

Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
fda9dbf1f4d15baaedffdd4b4bb529e06172f73d 15-Nov-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Silence warnings coming from allocators used by std::basic_string.

This is similar to r194004: because we can't reason about the data structure
invariants of std::basic_string, the analyzer decides it's possible for an
allocator to be used to deallocate the string's inline storage. Just ignore
this by walking up the stack, skipping past methods in classes with
"allocator" in the name, and seeing if we reach std::basic_string that way.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194764 91177308-0d34-0410-b5e6-96231b3b80d8
bdc0bf3f84b8771572d8401c66903c56a2e1318e 04-Nov-2013 Anna Zaks <ganna@apple.com> [analyzer] Suppress warnings coming out of std::basic_string.

The analyzer cannot reason about the internal invariances of the data structure (radar://15194597).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194004 91177308-0d34-0410-b5e6-96231b3b80d8
2a648169f9ad854536814515cba1780fd02586d2 31-Oct-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Don't crash when a path goes through a 'delete' destructor call.

This was just left unimplemnted from r191381; the fix is to report this call
location as the location of the 'delete' expr.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193783 91177308-0d34-0410-b5e6-96231b3b80d8
9b072b31ee2f41b8e30d1d22142c9ab72ac5ff1f 28-Sep-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Make inlining decisions based on the callee being variadic.

...rather than trying to figure it out from the call site, and having
people complain that we guessed wrong and that a prototype-less call is
the same as a variadic call on their system. More importantly, fix a
crash when there's no decl at the call site (though we could have just
returned a default value).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191599 91177308-0d34-0410-b5e6-96231b3b80d8
d8188f8ad5d584b5f6e1f58e5a4882586cc630d4 02-Aug-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Don't process autorelease counts in synthesized function bodies.

We process autorelease counts when we exit functions, but if there's an
issue in a synthesized body the report will get dropped. Just skip the
processing for now and let it get handled when the caller gets around to
processing autoreleases.

(This is still suboptimal: objects autoreleased in the caller context
should never be warned about when exiting a callee context, synthesized
or not.)

Second half of <rdar://problem/14611722>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187625 91177308-0d34-0410-b5e6-96231b3b80d8
cd007b18ba218925923a82ad4462fecf903f4a93 02-Aug-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Silently drop all reports within synthesized bodies.

Much of our diagnostic machinery is set up to assume that the report
end path location is valid. Moreover, the user may be quite confused
when something goes wrong in our BodyFarm-synthesized function bodies,
which may be simplified or modified from the real implementations.
Rather than try to make this all work somehow, just drop the report so
that we don't try to go on with an invalid source location.

Note that we still handle reports whose /paths/ go through invalid
locations, just not those that are reported in one.

We do have to be careful not to lose warnings because of this.
The impetus for this change was an autorelease being processed within
the synthesized body, and there may be other possible issues that are
worth reporting in some way. We'll take these as they come, however.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187624 91177308-0d34-0410-b5e6-96231b3b80d8
8b625a3f7764959d0a2ac3cd860ce1e168e0fc9b 04-Jul-2013 Anna Zaks <ganna@apple.com> [analyzer] Suppress reports reported in std::list

The motivation is to suppresses false use-after-free reports that occur when calling
std::list::pop_front() or std::list::pop_back() twice. The analyzer does not
reason about the internal invariants of the list implementation, so just do not report
any of warnings in std::list.

Fixes radar://14317928.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185609 91177308-0d34-0410-b5e6-96231b3b80d8
7f79b78351af03a392ee16d8ec557d47746c33c6 04-Jul-2013 Anna Zaks <ganna@apple.com> [analyzer] Make sure that inlined defensive checks work on div by zero.

This suppresses a false positive in std::hash_map.
Fixes radar://14255587.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185608 91177308-0d34-0410-b5e6-96231b3b80d8
053c88bd93e6b2f4e498fd835155f955127d3489 21-Jun-2013 Jordan Rose <jordan_rose@apple.com> Revert "[analyzer] Handle zeroing CXXConstructExprs."

Per review from Anna, this really should have been two commits, and besides
it's causing problems on our internal buildbot. Reverting until these have
been worked out.

This reverts r184511 / 98123284826bb4ce422775563ff1a01580ec5766.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184561 91177308-0d34-0410-b5e6-96231b3b80d8
98123284826bb4ce422775563ff1a01580ec5766 21-Jun-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Handle zeroing CXXConstructExprs.

Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.

As a bonus, trivial default constructors are now no longer inlined; they
are instead processed explicitly by ExprEngine. This has a (positive)
effect on the generated path edges: they no longer stop at a default
constructor call unless there's a user-provided implementation.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184511 91177308-0d34-0410-b5e6-96231b3b80d8
048eeea6852043990c87e52938b53b5337bd098e 04-Jun-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Enable the new edge algorithm by default.

...but don't yet migrate over the existing plist tests. Some of these
would be trivial to migrate; others could use a bit of inspection first.
In any case, though, the new edge algorithm seems to have proven itself,
and we'd like more coverage (and more usage) of it going forwards.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183165 91177308-0d34-0410-b5e6-96231b3b80d8
b9814c867e69d542ea6b90c756814dab462019c7 24-May-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Fix test for r182677.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182678 91177308-0d34-0410-b5e6-96231b3b80d8
d474da062565596015558856333423199aed5eb1 24-May-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Treat analyzer-synthesized function bodies like implicit bodies.

When generating path notes, implicit function bodies are shown at the call
site, so that, say, copying a POD type in C++ doesn't jump you to a header
file. This is especially important when the synthesized function itself
calls another function (or block), in which case we should try to jump the
user around as little as possible.

By checking whether a called function has a body in the AST, we can tell
if the analyzer synthesized the body, and if we should therefore collapse
the call down to the call site like a true implicitly-defined function.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182677 91177308-0d34-0410-b5e6-96231b3b80d8
14040142a3b3c1029092bc1f7c51e347c3fa8f89 15-May-2013 Fariborz Jahanian <fjahanian@apple.com> improve of note message and minor refactoring of my last
patch (r181847).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181896 91177308-0d34-0410-b5e6-96231b3b80d8
9f00b1d3962147a2fe049b8b45f70680bc12fbc1 15-May-2013 Fariborz Jahanian <fjahanian@apple.com> Objective-C [diagnostics] [QOI], when method is not
found for a receiver, note where receiver class
is declaraed (this is most common when receiver is a forward
class). // rdar://3258331

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181847 91177308-0d34-0410-b5e6-96231b3b80d8
ef202c35b37c137e32fe30f4453915b6d3b525d7 14-May-2013 Anna Zaks <ganna@apple.com> [analyzer] Refactor: address Jordan’s code review of r181738.

(Modifying the checker to record that the values are no longer nil will be done separately.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181744 91177308-0d34-0410-b5e6-96231b3b80d8
636478e288b88396d860f6b01b48b47953e3d5e9 07-May-2013 Anna Zaks <ganna@apple.com> [analyzer] Fix a crash triggered by printing a note on a default argument

Instead, use the location of the call to print the note.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181337 91177308-0d34-0410-b5e6-96231b3b80d8
2faee99ab67105e834d11df7db80a78a3e3ed37b 03-May-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Check the stack frame when looking for a var's initialization.

FindLastStoreBRVisitor is responsible for finding where a particular region
gets its value; if the region is a VarRegion, it's possible that value was
assigned at initialization, i.e. at its DeclStmt. However, if a function is
called recursively, the same DeclStmt may be evaluated multiple times in
multiple stack frames. FindLastStoreBRVisitor was not taking this into
account and just picking the first one it saw.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180997 91177308-0d34-0410-b5e6-96231b3b80d8
dcd6224911e234ab3657b7d0b79a2add1ae4fdd8 03-May-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Fix trackNullOrUndef when tracking args that have nil receivers.

There were actually two bugs here:
- if we decided to look for an interesting lvalue or call expression, we
wouldn't go find its node if we also knew we were at a (different) call.
- if we looked through one message send with a nil receiver, we thought we
were still looking at an argument to the original call.

Put together, this kept us from being able to track the right values, which
means sub-par diagnostics and worse false-positive suppression.

Noticed by inspection.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180996 91177308-0d34-0410-b5e6-96231b3b80d8
776d3bb65c90278b9c65544b235d2ac40aea1d6e 02-May-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Don't inline the [cd]tors of C++ iterators.

This goes with r178516, which instructed the analyzer not to inline the
constructors and destructors of C++ container classes. This goes a step
further and does the same thing for iterators, so that the analyzer won't
falsely decide we're trying to construct an iterator pointing to a
nonexistent element.

The heuristic for determining whether something is an iterator is the
presence of an 'iterator_category' member. This is controlled under the
same -analyzer-config option as container constructor/destructor inlining:


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180890 91177308-0d34-0410-b5e6-96231b3b80d8
0f8579274a010f360a371b53101859d9d6052314 24-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Refactor BugReport::getLocation and PathDiagnosticLocation::createEndOfPath for greater code reuse

The 2 functions were computing the same location using different logic (each one had edge case bugs that the other
one did not). Refactor them to rely on the same logic.

The location of the warning reported in text/command line output format will now match that of the plist file.

There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the
operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and
looks better in most cases.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180165 91177308-0d34-0410-b5e6-96231b3b80d8
fbc4444eb2675934b44f3720ef9a5f368ecbeb0a 22-Apr-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Type information from C++ new expressions is perfect.

This improves our handling of dynamic_cast and devirtualization for
objects allocated by 'new'.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180051 91177308-0d34-0410-b5e6-96231b3b80d8
8ef064d53fb33b5a8f8743bcbb0a2fd5c3e97be1 20-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Ensure BugReporterTracking works on regions with pointer arithmetic

Introduce a new helper function, which computes the first symbolic region in
the base region chain. The corresponding symbol has been used for assuming that
a pointer is null. Now, it will also be used for checking if it is null.

This ensures that we are tracking a null pointer correctly in the BugReporter.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179916 91177308-0d34-0410-b5e6-96231b3b80d8
10391c2890be5309d8b166507a0ed967eb9e5586 20-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Correct the comment

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179914 91177308-0d34-0410-b5e6-96231b3b80d8
62fba4f08af16ff17b5cbe8816061349504317e4 18-Apr-2013 Ted Kremenek <kremenek@apple.com> [analyzer] Refine 'nil receiver' diagnostics to mention the name of the method not called.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179776 91177308-0d34-0410-b5e6-96231b3b80d8
86f1745be24c834175e7a8a51b12f9a0063d532e 18-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Tweak getDerefExpr more to track DeclRefExprs to references.

In the committed example, we now see a note that tells us when the pointer
was assumed to be null.

This is the only case in which getDerefExpr returned null (failed to get
the dereferenced expr) throughout our regression tests. (There were multiple
occurrences of this one.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179736 91177308-0d34-0410-b5e6-96231b3b80d8
1e1d011874340f33b807ac90609424f90f72488a 18-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Improve dereferenced expression tracking for MemberExpr with a dot and non-reference base

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179734 91177308-0d34-0410-b5e6-96231b3b80d8
441625e6c7f8bf58e62a284ae1f855dafde31ec2 18-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Gain more precision retrieving the right SVal by specifying the type of the expression.

Thanks to Jordan for suggesting the fix.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179732 91177308-0d34-0410-b5e6-96231b3b80d8
07d8470effc0b0364801adddb6ff92bd22334402 16-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Add pretty printing to CXXBaseObjectRegion.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179573 91177308-0d34-0410-b5e6-96231b3b80d8
79d0cceb8847bfe6dc9da8eb2ea2f3c6bb73b813 16-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Address code review for r179395

Mostly refactoring + handle the nested fields by printing the innermost field only.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179572 91177308-0d34-0410-b5e6-96231b3b80d8
82dd4396fcd2517d06382b7170f393d1b6351c7f 16-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Add more specialized error messages for corner cases as per Jordan's code review for r179396

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179571 91177308-0d34-0410-b5e6-96231b3b80d8
8713e1a5c3f6658d54061e176b5baa9fadf14675 12-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Print a diagnostic note even if the region cannot be printed.

There are few cases where we can track the region, but cannot print the note,
which makes the testing limited. (Though, I’ve tested this manually by making
all regions non-printable.) Even though the applicability is limited now, the enhancement
will be more relevant as we start tracking more regions.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179396 91177308-0d34-0410-b5e6-96231b3b80d8
9e2f5977a180ae927d05e844c65b8a7873be48a4 12-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer]Print field region even when the base region is not printable

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179395 91177308-0d34-0410-b5e6-96231b3b80d8
7be2245487f9cd7d04f013db92280d9ccd323586 12-Apr-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Show "Returning from ..." note at caller's depth, not callee's.

1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here

1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here

The location of the note is already in the caller, not the callee, so this
just brings the "depth" attribute in line with that.

This only affects plist diagnostic consumers (i.e. Xcode). It's necessary
for Xcode to associate the control flow arrows with the right stack frame.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179351 91177308-0d34-0410-b5e6-96231b3b80d8
3ea09a802f973c2726b2a489ae08a4bded93410b 12-Apr-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Don't emit extra context arrow after returning from an inlined call.

In this code

int getZero() {
return 0;

void test() {
int problem = 1 / getZero(); // expected-warning {{Division by zero}}

we generate these arrows:

| v
int problem = 1 / getZero();
^ |

where the top one represents the control flow up to the first call, and the
bottom one represents the flow to the division.* It turns out, however, that
we were generating the top arrow twice, as if attempting to "set up context"
after we had already returned from the call. This resulted in poor
highlighting in Xcode.

* Arguably the best location for the division is the '/', but that's a
different problem.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179350 91177308-0d34-0410-b5e6-96231b3b80d8
4b69feb6d90eb120d04f5d54f6b28cc295a46098 06-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Fix null tracking for the given test case, by using the proper state and removing redundant code.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178933 91177308-0d34-0410-b5e6-96231b3b80d8
610f79cbab4d752349b5c81a94682a6a82b102e7 05-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Show path diagnostic for C++ initializers

Also had to modify the PostInitializer ProgramLocation to contain the field region.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178826 91177308-0d34-0410-b5e6-96231b3b80d8
702077f14100f2d7acdb12ad49b53e64efc37d72 03-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Allow tracknullOrUndef look through the ternary operator even when condition is unknown

Improvement of r178684 and r178685.

Jordan has pointed out that I should not rely on the value of the condition to know which expression branch
has been taken. It will not work in cases the branch condition is an unknown value (ex: we do not track the constraints for floats).
The better way of doing this would be to find out if the current node is the right or left successor of the node
that has the ternary operator as a terminator (which is how this is done in other places, like ConditionBRVisitor).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178701 91177308-0d34-0410-b5e6-96231b3b80d8
cabc3fddae63f5eb3bd44bdecce7a3fbd69421a9 03-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] make peelOffOuterExpr in BugReporterVisitors recursively peel off select Exprs

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178685 91177308-0d34-0410-b5e6-96231b3b80d8
c1bef5671e682de5a573c7c6b66871b36de0ec61 03-Apr-2013 Anna Zaks <ganna@apple.com> [analyzer] Properly handle the ternary operator in trackNullOrUndefValue

1) Look for the node where the condition expression is live when checking if
it is constrained to true or false.

2) Fix a bug in ProgramState::isNull, which was masking the problem. When
the expression is not a symbol (,which is the case when it is Unknown) return
unconstrained value, instead of value constrained to “false”!
(Thankfully other callers of isNull have not been effected by the bug.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178684 91177308-0d34-0410-b5e6-96231b3b80d8
c63a460d78a7625ff38d2b3580f78030c44f07db 02-Apr-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] For now, don't inline [cd]tors of C++ containers.

This is a heuristic to make up for the fact that the analyzer doesn't
model C++ containers very well. One example is modeling that
'std::distance(I, E) == 0' implies 'I == E'. In the future, it would be
nice to model this explicitly, but for now it just results in a lot of
false positives.

The actual heuristic checks if the base type has a member named 'begin' or
'iterator'. If so, we treat the constructors and destructors of that type
as opaque, rather than inlining them.

This is intended to drastically reduce the number of false positives
reported with experimental destructor support turned on. We can tweak the
heuristic in the future, but we'd rather err on the side of false negatives
for now.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178516 91177308-0d34-0410-b5e6-96231b3b80d8
84e8a960ad76b3c7ca550b4cc92a1b90ed16d5c1 29-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] Address Jordan’s review of r178309 - do not register an extra visitor for nil receiver

We can check if the receiver is nil in the node that corresponds to the StmtPoint of the message send.
At that point, the receiver is guaranteed to be live. We will find at least one unreclaimed node due to
my previous commit (look for StmtPoint instead of PostStmt) and the fact that the nil receiver nodes are tagged.

+ a couple of extra tests.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178381 91177308-0d34-0410-b5e6-96231b3b80d8
aabb4c5eacca6d78ef778f33ec5cd4c755d71a39 29-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] Apply the suppression rules to the nil receiver only if the value participates in the computation of the nil we warn about.

We should only suppress a bug report if the IDCed or null returned nil value is directly related to the value we are warning about. This was
not the case for nil receivers - we would suppress a bug report that had an IDCed nil receiver on the path regardless of how it’s
related to the warning.

1) Thread EnableNullFPSuppression parameter through the visitors to differentiate between tracking the value which
is directly responsible for the bug and other values that visitors are tracking (ex: general tracking of nil receivers).
2) in trackNullOrUndef specifically address the case when a value of the message send is nil due to the receiver being nil.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178309 91177308-0d34-0410-b5e6-96231b3b80d8
03af377b2755fb2ddb0621dea5dd91cd5fda631d 22-Mar-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Fix test to actually test what was intended.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177763 91177308-0d34-0410-b5e6-96231b3b80d8
f510f5cd57fa9b7ea6f6e103c65c0df95a55d986 16-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] BugReporterVisitors: handle the case where a ternary operator is wrapped in a cast.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177205 91177308-0d34-0410-b5e6-96231b3b80d8
6a15f39a6bfd7a30085c5fa8f67d0b64b74b132a 15-Mar-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Look through ExprWhenCleanups when trying to track a NULL.

Silences a few false positives in LLVM.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177186 91177308-0d34-0410-b5e6-96231b3b80d8
dc9c160dede7e2f5cc11755db6aaa57e7fccbcec 15-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] Teach trackNullOrUndef to look through ternary operators

Allows the suppression visitors trigger more often.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177137 91177308-0d34-0410-b5e6-96231b3b80d8
a4bb4f6ca8dd31ad96cb9526a5abe1273f18ff40 14-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] Change the way in which IDC Visitor decides to kick in and make sure it attaches in the given edge case

In the test case below, the value V is not constrained to 0 in ErrorNode but it is in node N.
So we used to fail to register the Suppression visitor.

We also need to change the way we determine that the Visitor should kick in because the node N belongs to
the ExplodedGraph and might not be on the BugReporter path that the visitor sees. Instead of trying to match the node,
turn on the visitor when we see the last node in which the symbol is ‘0’.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177121 91177308-0d34-0410-b5e6-96231b3b80d8
6022c4e17c0d2ad9c43ef6bc830d394b670a4705 13-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] BugReporter - more precise tracking of C++ references

When BugReporter tracks C++ references involved in a null pointer violation, we
want to differentiate between a null reference and a reference to a null pointer. In the
first case, we want to track the region for the reference location; in the second, we want
to track the null pointer.

In addition, the core creates CXXTempObjectRegion to represent the location of the
C++ reference, so teach FindLastStoreBRVisitor about it.

This helps null pointer suppression to kick in.

(Patch by Anna and Jordan.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176969 91177308-0d34-0410-b5e6-96231b3b80d8
0415998dd77986630efe8f1aed633519cc41e1f3 09-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] Make Suppress IDC checker aware that it might not start from the same node it was registered at

The visitor used to assume that the value it’s tracking is null in the first node it examines. This is not true.
If we are registering the Suppress Inlined Defensive checks visitor while traversing in another visitor
(such as FindlastStoreVisitor). When we restart with the IDC visitor, the invariance of the visitor does
not hold since the symbol we are tracking no longer exists at that point.

I had to pass the ErrorNode when creating the IDC visitor, because, in some cases, node N is
neither the error node nor will be visible along the path (we had not finalized the path at that point
and are dealing with ExplodedGraph.)

We should revisit the other visitors which might not be aware that they might get nodes, which are
later in path than the trigger point.

This suppresses a number of inline defensive checks in JavaScriptCore.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176756 91177308-0d34-0410-b5e6-96231b3b80d8
0183768813658d419e3124b576744b03ec8e9b55 09-Mar-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Look for lvalue nodes when tracking a null pointer.

r176010 introduced the notion of "interesting" lvalue expressions, whose
nodes are guaranteed never to be reclaimed by the ExplodedGraph. This was
used in bugreporter::trackNullOrUndefValue to find the region that contains
the null or undef value being tracked.

However, the /rvalue/ nodes (i.e. the loads from these lvalues that produce
a null or undef value) /are/ still being reclaimed, and if we couldn't
find the node for the rvalue, we just give up. This patch changes that so
that we look for the node for either the rvalue or the lvalue -- preferring
the former, since it lets us fall back to value-only tracking in cases
where we can't get a region, but allowing the latter as well.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176737 91177308-0d34-0410-b5e6-96231b3b80d8
c236b7327f989c1e7fe6b08a188bfef86727513d 07-Mar-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Check for returning null references in ReturnUndefChecker.

Officially in the C++ standard, a null reference cannot exist. However,
it's still very easy to create one:

int &getNullRef() {
int *p = 0;
return *p;

We already check that binds to reference regions don't create null references.
This patch checks that we don't create null references by returning, either.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176601 91177308-0d34-0410-b5e6-96231b3b80d8
42773d64f98db0dd5cc80181c3b2d561851668f7 06-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] Pass the correct Expr to the bug reporter visitors when dealing with CompoundLiteralExpr

This allows us to trigger the IDC visitor in the added test case.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176577 91177308-0d34-0410-b5e6-96231b3b80d8
713e07591995d761f65c7132289dce003a29870f 06-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] IDC: Add config option; perform the idc check on first “null node” rather than last “non-null”.

The second modification does not lead to any visible result, but, theoretically, is what we should
have been looking at to begin with since we are checking if the node was assumed to be null in
an inlined function.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176576 91177308-0d34-0410-b5e6-96231b3b80d8
cc5dbdae70c6eb2423921f52a35ba4686d2969cf 02-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] Simple inline defensive checks suppression

Inlining brought a few "null pointer use" false positives, which occur because
the callee defensively checks if a pointer is NULL, whereas the caller knows
that the pointer cannot be NULL in the context of the given call.

This is a first attempt to silence these warnings by tracking the symbolic value
along the execution path in the BugReporter. The new visitor finds the node
in which the symbol was first constrained to NULL. If the node belongs to
a function on the active stack, the warning is reported, otherwise, it is

There are several areas for follow up work, for example:
- How do we differentiate the cases where the first check is followed by
another one, which does happen on the active stack?

Also, this only silences a fraction of null pointer use warnings. For example, it
does not do anything for the cases where NULL was assigned inside a callee.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176402 91177308-0d34-0410-b5e6-96231b3b80d8
9abf1b4577b75ffcc46afbdfb55de334f68f05c0 01-Mar-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Suppress paths involving a reference whose rvalue is null.

Most map types have an operator[] that inserts a new element if the key
isn't found, then returns a reference to the value slot so that you can
assign into it. However, if the value type is a pointer, it will be
initialized to null. This is usually no problem.

However, if the user /knows/ the map contains a value for a particular key,
they may just use it immediately:

// From ClangSACheckersEmitter.cpp

In this case the analyzer reports a null dereference on the path where the
key is not in the map, even though the user knows that path is impossible
here. They could silence the warning by adding an assertion, but that means
splitting up the expression and introducing a local variable. (Note that
the analyzer has no way of knowing that recordGroupMap[group] will return
the same reference if called twice in a row!)

We already have logic that says a null dereference has a high chance of
being a false positive if the null came from an inlined function. This
patch simply extends that to references whose rvalues are null as well,
silencing several false positives in LLVM.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176371 91177308-0d34-0410-b5e6-96231b3b80d8
6f4160828db75f36b22a204da202723c592644f3 27-Feb-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value.

Consider this case:

int *p = 0;
p = getPointerThatMayBeNull();
*p = 1;

If we inline 'getPointerThatMayBeNull', we might know that the value of 'p'
is NULL, and thus emit a null pointer dereference report. However, we
usually want to suppress such warnings as error paths, and we do so by using
FindLastStoreBRVisitor to see where the NULL came from. In this case, though,
because 'p' was NULL both before and after the assignment, the visitor
would decide that the "last store" was the initialization, not the

This commit changes FindLastStoreBRVisitor to consider all PostStore nodes
that assign to this region. This still won't catches changes made directly
by checkers if they re-assign the same value, but it does handle the common
case in user-written code and will trigger ReturnVisitor's suppression
machinery as expected.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176201 91177308-0d34-0410-b5e6-96231b3b80d8
4238f41d484729aca260140fbbc53a68769bf60a 26-Feb-2013 Ted Kremenek <kremenek@apple.com> [analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion.

Fixes PR15358 and <rdar://problem/13295437>.

Along the way, shorten path diagnostics that say "Variable 'x'" to just
be "'x'". By the context, it is obvious that we have a variable,
and so this just consumes text space.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176115 91177308-0d34-0410-b5e6-96231b3b80d8
db061e40d639da0d938f915f0eef9e9772019c22 25-Feb-2013 Anna Zaks <ganna@apple.com> [analyzer] Restrict ObjC type inference to methods that have related result type.

This addresses a case when we inline a wrong method due to incorrect
dynamic type inference. Specifically, when user code contains a method from init
family, which creates an instance of another class.

Use hasRelatedResultType() to find out if our inference rules should be triggered.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176054 91177308-0d34-0410-b5e6-96231b3b80d8
44ec3f00e64199667edf9f12c0f31f66916c95fe 26-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Track null object lvalues back through C++ method calls.

The expression 'a->b.c()' contains a call to the 'c' method of 'a->b'.
We emit an error if 'a' is NULL, but previously didn't actually track
the null value back through the 'a->b' expression, which caused us to
miss important false-positive-suppression cases, including

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173547 91177308-0d34-0410-b5e6-96231b3b80d8
bfa9ab8183e2fdc74f8633d758cb0c6201314320 25-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Replace "-analyzer-ipa" with "-analyzer-config ipa".

The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173385 91177308-0d34-0410-b5e6-96231b3b80d8
141b90cd3d095b638045d9bc2a070af37d32e1e1 21-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Fix test for r173067.

Note to self: don't remove comments /after/ updating the line-sensitive
part of a test.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173070 91177308-0d34-0410-b5e6-96231b3b80d8
187f8bd88bfc92cf3fea62b7d8db5f92edce410a 21-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Show notes inside implicit calls at the last explicit call site.

struct Wrapper { <-- 2. Calling default constructor for 'NonTrivial'.
NonTrivial m;

Wrapper w; <-- 1. Calling implicit default constructor for 'Wrapper'.

struct Wrapper {
NonTrivial m;

Wrapper w; <-- 1. Calling implicit default constructor for 'Wrapper'.
^-- 2. Calling default constructor for 'NonTrivial'.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173067 91177308-0d34-0410-b5e6-96231b3b80d8
2b9de0bc05e3e1092a9d1880e62aeaa54dc343e3 19-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Don't show "Entered 'foo'" if 'foo' is implicit.

Calling implicit default constructor for 'Foo' (where Foo is constructed)
Entered call from 'test' (at "=default" or 'Foo' declaration)
Calling default constructor for 'Bar' (at "=default" or 'Foo' declaration)

Calling implicit default constructor for 'Foo' (where Foo is constructed)
Calling default constructor for 'Bar' (at "=default" or 'Foo' declaration)

This only affects the plist diagnostics; this note is never shown in the
other diagnostics.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172915 91177308-0d34-0410-b5e6-96231b3b80d8
e02be97811c785f91ac43a0feed2db862de1867f 18-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Special path notes for C++ special member functions.

Calling implicit default constructor for Foo
Calling defaulted move constructor for Foo
Calling copy constructor for Foo
Calling implicit destructor for Foo
Calling defaulted move assignment operator for Foo
Calling copy assignment operator for Foo

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172833 91177308-0d34-0410-b5e6-96231b3b80d8
dc47c9a71c99ce2e5b9d84f1cd3487b6852b3543 18-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Do a better job describing C++ member functions in the call stack.

Calling constructor for 'Foo'
Entered call from 'Foo::create'

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172832 91177308-0d34-0410-b5e6-96231b3b80d8
c1c6a4981a4b50476d71c88f8dac81a1430885ed 08-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Plist: change the type of issue_hash from int to string.

This gives more flexibility to what could be stored as issue_hash.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171824 91177308-0d34-0410-b5e6-96231b3b80d8
afa7cae15b117c4b75794c6c32424953d94b4359 07-Dec-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Fix r168019 to work with unpruned paths as well.

This is the case where the analyzer tries to print out source locations
for code within a synthesized function body, which of course does not have
a valid source location. The previous fix attempted to do this during
diagnostic path pruning, but some diagnostics have pruning disabled, and
so any diagnostic with a path that goes through a synthesized body will
either hit an assertion or emit invalid output.

<rdar://problem/12657843> (again)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169631 91177308-0d34-0410-b5e6-96231b3b80d8
368f3b070e8cb657a65bfa443d60256676d269e7 15-Nov-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Make sure calls in synthesized functions have valid path locations.

We do this by using the "most recent" good location: if a synthesized
function 'A' calls another function 'B', the path notes for the call to 'B'
will be placed at the same location as the path note for calling 'A'.

Similarly, the call to 'A' will have a note saying "Entered call from...",
and now we just don't emit that (since the user doesn't have a body to look
at anyway).

Previously, we were doing this for the "Calling..." notes, but not for the
"Entered call from..." or "Returning to caller". This caused a crash when
the path entered and then exiting a call within a synthesized body.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168019 91177308-0d34-0410-b5e6-96231b3b80d8
d51db4935736fd943bfd46dfa74d41e9a3c2d41f 13-Nov-2012 Anna Zaks <ganna@apple.com> [analyzer] Follow up to r167762 - precisely determine the adjustment

The adjustment is needed only in case of dynamic dispatch performed by
the analyzer - when the runtime declaration is different from the static

Document this explicitly in the code (by adding a helper). Also, use
canonical Decls to avoid matching against the case where the definition
is different from found declaration.

This fix suppresses the testcase I added in r167762, so add another
testcase to make sure we do test commit r167762.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167780 91177308-0d34-0410-b5e6-96231b3b80d8
6a329ee7567cf3267ffab2bc755ea8c773d967e7 29-Oct-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] New option to not suppress null return paths if an argument is null.

Our one basic suppression heuristic is to assume that functions do not
usually return NULL. However, when one of the arguments is NULL it is
suddenly much more likely that NULL is a valid return value. In this case,
we don't suppress the report here, but we do attach /another/ visitor to
go find out if this NULL argument also comes from an inlined function's
error path.

This new behavior, controlled by the 'avoid-suppressing-null-argument-paths'
analyzer-config option, is turned off by default. Turning it on produced
two false positives and no new true positives when running over LLVM/Clang.

This is one of the possible refinements to our suppression heuristics.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166941 91177308-0d34-0410-b5e6-96231b3b80d8
09f7bf14d25bdc55cb715bc8d40600906848a409 29-Oct-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Use the CallEnter node to get a value for tracked null arguments.

Additionally, don't collect PostStore nodes -- they are often used in
path diagnostics.

Previously, we tried to track null arguments in the same way as any other
null values, but in many cases the necessary nodes had already been
collected (a memory optimization in ExplodedGraph). Now, we fall back to
using the value of the argument at the time of the call, which may not
always match the actual contents of the region, but often will.

This is a precursor to improving our suppression heuristic.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166940 91177308-0d34-0410-b5e6-96231b3b80d8
b85cce094887ab5cf1c47acfe306e2fb1d3cfbb1 26-Oct-2012 Ted Kremenek <kremenek@apple.com> TrackConstraintBRVisitor and ConditionBRVisitor can emit similar
path notes for cases where a value may be assumed to be null, etc.
Instead of having redundant diagnostics, do a pass over the generated
PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor
that are already covered by ConditionBRVisitor, whose notes tend
to be better.

Fixes <rdar://problem/12252783>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166728 91177308-0d34-0410-b5e6-96231b3b80d8
8e8fb3be5bd78f0564444eca02b404566a5f3b5d 19-Oct-2012 Andy Gibbs <andyg1001@hotmail.co.uk> Prior to adding the new "expected-no-diagnostics" directive to VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166280 91177308-0d34-0410-b5e6-96231b3b80d8
ff63227817217cd33c587e054d4892285b8e00c6 03-Oct-2012 Jordan Rose <jordan_rose@apple.com> Revert "InlineObjCInstanceMethod.m: Remove lines introduced in r165079."

...and fix the run line so that the expected warnings are the same on
all platforms.

This reverts r165088 / d09074f0ca06626914108f1c0d4e70adeb851e01.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165124 91177308-0d34-0410-b5e6-96231b3b80d8
d09074f0ca06626914108f1c0d4e70adeb851e01 03-Oct-2012 NAKAMURA Takumi <geek4civic@gmail.com> InlineObjCInstanceMethod.m: Remove lines introduced in r165079. It broke some builds, on FreeBSD, Linux and Windows.

error: 'warning' diagnostics expected but not seen:
Line 94: types are incompatible
1 error generated.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165088 91177308-0d34-0410-b5e6-96231b3b80d8
48314cf6a289bc5a082d8c769c58a38f924c93b7 03-Oct-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Adjust the return type of an inlined devirtualized method call.

In C++, overriding virtual methods are allowed to specify a covariant
return type -- that is, if the return type of the base method is an
object pointer type (or reference type), the overriding method's return
type can be a pointer to a subclass of the original type. The analyzer
was failing to take this into account when devirtualizing a method call,
and anything that relied on the return value having the proper type later
would crash.

In Objective-C, overriding methods are allowed to specify ANY return type,
meaning we can NEVER be sure that devirtualizing will give us a "safe"
return value. Of course, a program that does this will most likely crash
at runtime, but the analyzer at least shouldn't crash.

The solution is to check and see if the function/method being inlined is
the function that static binding would have picked. If not, check that
the return value has the same type. If the types don't match, see if we
can fix it with a derived-to-base cast (the C++ case). If we can't,
return UnknownVal to avoid crashing later.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165079 91177308-0d34-0410-b5e6-96231b3b80d8
0be2638cc5809bbf8645a2721e80507abd076790 26-Sep-2012 Anna Zaks <ganna@apple.com> [analyzer] Commit a test case for r164579.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164715 91177308-0d34-0410-b5e6-96231b3b80d8
70e5b575e187beb10f4a10667d9f4f5227131c40 24-Sep-2012 Anna Zaks <ganna@apple.com> [analyzer] Really turn on dynamic-bifurcation on by default.

Thanks to Byoungyoung for realizing taht we are not passing the default
option correctly.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164543 91177308-0d34-0410-b5e6-96231b3b80d8
b9d4e5e3bb235f1149e99d3c833ff7cb3474c9f1 22-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Suppress bugs whose paths go through the return of a null pointer.

This is a heuristic intended to greatly reduce the number of false
positives resulting from inlining, particularly inlining of generic,
defensive C++ methods that live in header files. The suppression is
triggered in the cases where we ask to track where a null pointer came
from, and it turns out that the source of the null pointer was an inlined
function call.

This change brings the number of bug reports in LLVM from ~1500 down to
around ~300, a much more manageable number. Yes, some true positives may
be hidden as well, but from what I looked at the vast majority of silenced
reports are false positives, and many of the true issues found by the
analyzer are still reported.

I'm hoping to improve this heuristic further by adding some exceptions
next week (cases in which a bug should still be reported).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164449 91177308-0d34-0410-b5e6-96231b3b80d8
53221da865144db0ba6bd89ab30bcf81de0fe5d2 22-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Track a null value back through FindLastStoreBRVisitor.

Also, tidy up the other tracking visitors so that they mark the right
things as interesting and don't do extra work.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164448 91177308-0d34-0410-b5e6-96231b3b80d8
6686b6694a7998623550ff6529f2f53bfee94328 22-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Look through OpaqueValueExprs when tracking a nil value.

This allows us to show /why/ a particular object is nil, even when it is
wrapped in an OpaqueValueExpr.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164445 91177308-0d34-0410-b5e6-96231b3b80d8
3225d072a348658cb67c45cdb46a981b09d1f562 12-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Re-add reinterpret_cast virtual call test case from r163644.

We mostly just don't want to crash analyzing this test case; it's likely
the code found here will actually crash if compiled and run.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163746 91177308-0d34-0410-b5e6-96231b3b80d8
fe3769dbb448edf8e5ece13b14017608558d4763 12-Sep-2012 Jordan Rose <jordan_rose@apple.com> Revert "[analyzer] Use the static type for a virtual call if the dynamic type is worse."

Using the static type may be inconsistent with later calls. We should just
report that there is no inlining definition available if the static type is
better than the dynamic type. See next commit.

This reverts r163644 / 19d5886d1704e24282c86217b09d5c6d35ba604d.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163744 91177308-0d34-0410-b5e6-96231b3b80d8
1b22cec353bc6112653d50b060a1d78d70c51527 12-Sep-2012 Chandler Carruth <chandlerc@gmail.com> Adjust some analyzer tests to place widely shared inputs inside of an
'Inputs' subdirectory.

The general desire has been to have essentially all of the non-test
input files live in such directories, with some exceptions for obvious
and common patterns like 'foo.c' using 'foo.h'.

This came up because our distributed test runner couldn't find some of
the headers, for example with stl.cpp.

No functionality changed, just shuffling around here.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163674 91177308-0d34-0410-b5e6-96231b3b80d8
19d5886d1704e24282c86217b09d5c6d35ba604d 11-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Use the static type for a virtual call if the dynamic type is worse.

reinterpret_cast does not provide any of the usual type information that
static_cast or dynamic_cast provide -- only the new type. This can get us
in a situation where the dynamic type info for an object is actually a
superclass of the static type, which does not match what CodeGen does at all.
In these cases, just fall back to the static type as the best possible type
for devirtualization.

Should fix the crashes on our internal buildbot.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163644 91177308-0d34-0410-b5e6-96231b3b80d8
e08dcbe75eb9b3ffe6f1f60ac2b216b4c878606a 11-Sep-2012 Anna Zaks <ganna@apple.com> [analyzer] Turn stl inlining back on.

The one reported bug, which was exposed by stl inlining, is addressed in

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163574 91177308-0d34-0410-b5e6-96231b3b80d8
4ea9b89ff6dc50d5404eb56cad5e5870bce49ef2 11-Sep-2012 Anna Zaks <ganna@apple.com> [analyzer] Do not count calls to small functions when computing stack

We only want to count how many substantial functions we inlined. This
is an improvement to r163558.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163571 91177308-0d34-0410-b5e6-96231b3b80d8
57330eed3fbe530cb05996e4a346cc5fc217c0d9 11-Sep-2012 Anna Zaks <ganna@apple.com> [analyzer] Add an option to enable/disable objc inlining.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163562 91177308-0d34-0410-b5e6-96231b3b80d8
7229d0011766c174beffe6a846d78f448f845b39 11-Sep-2012 Anna Zaks <ganna@apple.com> [analyzer] Add ipa-always-inline-size option (with 3 as the default).

The option allows to always inline very small functions, whose size (in
number of basic blocks) is set using -analyzer-config
ipa-always-inline-size option.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163558 91177308-0d34-0410-b5e6-96231b3b80d8
81fb50e8b120fc95dc0245b4112972d4d7cca3b5 10-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] For now, don't inline C++ standard library functions.

This is a (heavy-handed) solution to PR13724 -- until we know we can do
a good job inlining the STL, it's best to be consistent and not generate
more false positives than we did before. We can selectively whitelist
certain parts of the 'std' namespace that are known to be safe.

This is controlled by analyzer config option 'c++-stdlib-inlining', which
can be set to "true" or "false".

This commit also adds control for whether or not to inline any templated
functions (member or non-member), under the config option
'c++-template-inlining'. This option is currently on by default.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163548 91177308-0d34-0410-b5e6-96231b3b80d8
0187a1b8b9b2b7657de0ba8b0d4f67d30bec83e8 08-Sep-2012 Ted Kremenek <kremenek@apple.com> Attempt (again) to stabilize the order of the emission of diagnostics
of the analyzer by using the FullProfile() of a PathDiagnostic
for ordering them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163455 91177308-0d34-0410-b5e6-96231b3b80d8
dc601f4a9f69315521abddbca04d4652deee5fdb 31-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Fixup for r162935 as per Jordan's review.

Thanks for catching this!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162949 91177308-0d34-0410-b5e6-96231b3b80d8
05fcbd3dc28f4cba4a6d33e7aeaabb5f6f7837e3 30-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Do not propagate the [super init] could be nil assumption
from callee to caller.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162935 91177308-0d34-0410-b5e6-96231b3b80d8
554067f290282f366ccf65a27e0b914aa67a52c6 30-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Stop tracking symbols based on a retain count summary of
inlined function.

This resolves retain count checker false positives that are caused by
inlining ObjC and other methods. Essentially, if we are passing an
object to a method with "delegate" in the selector or a function pointer
as another argument, we should stop tracking the other parameters/return
value as far as the retain count checker is concerned.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162876 91177308-0d34-0410-b5e6-96231b3b80d8
7aba1171b32265b2206f3fa8f8886953051b58f5 28-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] If the last store into a region came from a function, step into it.

Previously, if we were tracking stores to a variable 'x', and came across this:

x = foo();

...we would simply emit a note here and stop. Now, we'll step into 'foo' and
continue tracking the returned value from there.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162718 91177308-0d34-0410-b5e6-96231b3b80d8
364b9f95fa47b0ca7f1cc694195f7a9953652f81 27-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Look through casts when trying to track a null pointer dereference.

Also, add comments to addTrackNullOrUndefValueVisitor.

Thanks for the review, Anna!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162695 91177308-0d34-0410-b5e6-96231b3b80d8
23df2437a47ff129d2923ae325d42e79682a7f14 24-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] If we dereference a NULL that came from a function, show the return.

More generally, any time we try to track where a null value came from, we
should show if it came from a function. This usually isn't necessary if
the value is symbolic, but if the value is just a constant we previously
just ignored its origin entirely. Now, we'll step into the function and
recursively add a visitor to the returned expression.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162563 91177308-0d34-0410-b5e6-96231b3b80d8
5a90193ad825656d4a03099cd5e9c928d1782b5e 24-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Make analyzer less aggressive when dealing with [self init].

With inlining, retain count checker starts tracking 'self' through the
init methods. The analyser results were too noisy if the developer
did not follow 'self = [super init]' pattern (which is common
especially in older code bases) - we reported self init anti-pattern AND
possible use-after-free. This patch teaches the retain count
checker to assume that [super init] does not fail when it's not consumed
by another expression. This silences the retain count warning that warns
about possibility of use-after-free when init fails, while preserving
all the other checking on 'self'.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162508 91177308-0d34-0410-b5e6-96231b3b80d8
ee04959f88e26ed38dccf4aed2ff10cad1f703c9 21-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] -analyzer-ipa=inlining is now the default. Remove it from tests.

The actual change here is a little more complicated than the summary above.
What we want to do is have our generic inlining tests run under whatever
mode is the default. However, there are some tests that depend on the
presence of C++ inlining, which still has some rough edges. These tests have
been explicitly marked as -analyzer-ipa=inlining in preparation for a new
mode that limits inlining to C functions and blocks. This will be the
default until the false positives for C++ have been brought down to
manageable levels.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162317 91177308-0d34-0410-b5e6-96231b3b80d8
b763ede873c23c8651bd18eba0c62e929b496ba5 15-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Don't inline dynamic-dispatch methods unless -analyzer-ipa=dynamic.

Previously we were checking -analyzer-ipa=dynamic-bifurcate only, and
unconditionally inlining everything else that had an available definition,
even under -analyzer-ipa=inlining (but not under -analyzer-ipa=none).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161916 91177308-0d34-0410-b5e6-96231b3b80d8
38aee3bb4ffe14c8323785ae2fafed6f627fb577 14-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer]Assume that the properties cannot be overridden when dot
syntax is used.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161889 91177308-0d34-0410-b5e6-96231b3b80d8
95b277e38875ac06faaf8570b5f7594bb6d99e21 14-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Address Jordan's comments for r161822, r161683.

Add a TODO test case for r161822 - calling self from a class method.

Remove a TODO comment for r161683 - value2 is not a property - we just
have method names that look like they are getters/setters for a

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161884 91177308-0d34-0410-b5e6-96231b3b80d8
c739406d37b9b1dc95bc3a3d899024e5ce31e5d5 14-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Teach live variable analyzes that super uses self pointer.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161822 91177308-0d34-0410-b5e6-96231b3b80d8
5498e3a01be0446f38c102278847566176f6507f 10-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] ObjC Inlining: add tests for ivars and properties.

- Handle @syncronized properties.
- Always inline properties declared publicly (do not split the path).
This is tricky since there is no mapping from a Decl to the property in
the AST as far as I can tell.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161683 91177308-0d34-0410-b5e6-96231b3b80d8
54918ba02ba900c0e0bb4fd3d749b6b1ac4e50a9 10-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Track if a region can be a subclass in the dynamic type info.

When object is allocated with alloc or init, we assume it cannot be a
subclass (currently used only for bifurcation purposes).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161682 91177308-0d34-0410-b5e6-96231b3b80d8
3f558af01643787d209a133215b0abec81b5fe30 10-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Optimize dynamic dispatch bifurcation by detecting the cases
when we don't need to split.

In some cases we know that a method cannot have a different
implementation in a subclass:
- the class is declared in the main file (private)
- all the method declarations (including the ones coming from super
classes) are in the main file.

This can be improved further, but might be enough for the heuristic.
(When we are too aggressive splitting the state, efficiency suffers.
When we fail to split the state coverage might suffer.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161681 91177308-0d34-0410-b5e6-96231b3b80d8
e90d3f847dcce76237078b67db8895eb7a24189e 09-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Bifurcate the path with dynamic dispatch.

This is an initial (unoptimized) version. We split the path when
inlining ObjC instance methods. On one branch we always assume that the
type information for the given memory region is precise. On the other we
assume that we don't have the exact type info. It is important to check
since the class could be subclassed and the method can be overridden. If
we always inline we can loose coverage.

Had to refactor some of the call eval functions.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161552 91177308-0d34-0410-b5e6-96231b3b80d8
acac844992d9b28d30f2801711bd92f353ada084 07-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] + New line at end of file

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161392 91177308-0d34-0410-b5e6-96231b3b80d8
8ed21ef726be89ef7151b5ff397631379bd8a537 07-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Address Jordan's review of DynamicTypePropagation.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161391 91177308-0d34-0410-b5e6-96231b3b80d8
340868161576d892f0e1d8f17a044502a98d3373 07-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] DynTypes: Add a test for improper cast performed by user.

Dynamic type inference does the right thing in this case. However, as
Jordan suggested, it would be nice to add a warning here as well.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161365 91177308-0d34-0410-b5e6-96231b3b80d8
c4c647c88ced2e953f15f8987952ede9b96aa969 07-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Dynamic type info - propagate through implicit casts.

I currently have a bit of redundancy with the cast kind switch statement
inside the ImplicitCast callback, but I might be adding more casts going

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161358 91177308-0d34-0410-b5e6-96231b3b80d8
c7ecc43c33a21b82c49664910b19fcc1f555aa51 07-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] Add a checker to manage dynamic type propagation.

Instead of sprinkling dynamic type info propagation throughout
ExprEngine, the added checker would add the more precise type
information on known APIs (Ex: ObjC alloc, new) and propagate
the type info in other cases (ex: ObjC init method, casts (the second is
not implemented yet)).

Add handling of ObjC alloc, new and init to the checker.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161357 91177308-0d34-0410-b5e6-96231b3b80d8
a801acd9773cacdbe16690269ecb47bd127440c5 06-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Add plist output checks for all four "path notes" tests.

No functionality change, but from now on, any new path notes should be
tested both with plain-text output (for ease of human auditing) and with
plist output (to ensure control flow and events are being correctly
represented in Xcode).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161351 91177308-0d34-0410-b5e6-96231b3b80d8
685379965c1b105ce89cf4f6c60810932b7f4d0d 04-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] When a symbol is null, we should track its constraints.

Because of this, we would previously emit NO path notes when a parameter
is constrained to null (because there are no stores). Now we show where we
made the assumption, which is much more useful.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161280 91177308-0d34-0410-b5e6-96231b3b80d8
b0e1badc2a9b8275b48dfb15c6907a282b949b02 04-Aug-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Flatten path diagnostics for text output like we do for HTML.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161279 91177308-0d34-0410-b5e6-96231b3b80d8
148fee988e32efcad45ecf7b3bf714880c657dda 03-Aug-2012 Anna Zaks <ganna@apple.com> [analyzer] ObjC Inlining: Start tracking dynamic type info in the GDM

In the following code, find the type of the symbolic receiver by
following it and updating the dynamic type info in the state when we
cast the symbol from id to MyClass *.

MyClass *a = [[self alloc] init];
return 5/[a testSelf];

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161264 91177308-0d34-0410-b5e6-96231b3b80d8
4fe64ad383c056774087113561063429103ac9a6 31-Jul-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Don't try to inline if there's no region for a message receiver.

While usually we'd use a symbolic region rather than a straight-up Unknown,
we can still generate unknowns via array subscripts with symbolic indexes.
(And if this ever changes in the future, we still shouldn't crash.)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161059 91177308-0d34-0410-b5e6-96231b3b80d8
2d18419a7c8f9a2975d4ed74a202de6467308ad1 30-Jul-2012 Anna Zaks <ganna@apple.com> [analyzer] Very simple ObjC instance method inlining

- Retrieves the type of the object/receiver from the state.
- Binds self during stack setup.
- Only explores the path on which the method is inlined (no
bifurcation to explore the path on which the method is not inlined).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160991 91177308-0d34-0410-b5e6-96231b3b80d8
e13056a8bb532ddfdc07952a13169aa422bacd3b 30-Jul-2012 Anna Zaks <ganna@apple.com> [analyzer] Add -analyzer-ipa=dynamic option for inlining dynamically
dispatched methods.

Disabled by default for now.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160988 91177308-0d34-0410-b5e6-96231b3b80d8
bccc594946d439351174831949a6a2cf7ff04f66 27-Jul-2012 Anna Zaks <ganna@apple.com> [analyzer] Another false positive in Class method inlining.
We are currently not setting the self object to the calling class object
during inlining nor do we reason about [AAA class].

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160884 91177308-0d34-0410-b5e6-96231b3b80d8
6fbe0317aa38dbac22a29f7519c52db838aa1990 27-Jul-2012 Anna Zaks <ganna@apple.com> [analyzer] Address Jordan's and Fariborz's review of r160768.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160883 91177308-0d34-0410-b5e6-96231b3b80d8
9dc5167e4017ef4c8b327abb6f72225eec2e0f19 26-Jul-2012 Anna Zaks <ganna@apple.com> [analyzer] Inline ObjC class methods.

- Some cleanup(the TODOs) will be done after ObjC method inlining is
- Simplified CallEvent::getDefinition not to require ISDynamicDispatch
- Also addressed Jordan's comments from r160530.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160768 91177308-0d34-0410-b5e6-96231b3b80d8