| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 651f13cea278ec967336033dd032faef0e9fc2ec |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Updated to Clang 3.5a.
Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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.
PR17746
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193783 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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.
<rdar://problem/14212563>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184511 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 7be2245487f9cd7d04f013db92280d9ccd323586 |
|
12-Apr-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Show "Returning from ..." note at caller's depth, not callee's.
Before:
1. Calling 'foo'
2. Doing something interesting
3. Returning from 'foo'
4. Some kind of error here
After:
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.
<rdar://problem/13634363>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179351 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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.
<rdar://problem/13326040>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179350 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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.
<rdar://problem/13364378>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176601 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
recordGroupMap[group]->Checkers
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.
<rdar://problem/13239854>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176371 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 187f8bd88bfc92cf3fea62b7d8db5f92edce410a |
|
21-Jan-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Show notes inside implicit calls at the last explicit call site.
Before:
struct Wrapper { <-- 2. Calling default constructor for 'NonTrivial'.
NonTrivial m;
};
Wrapper w; <-- 1. Calling implicit default constructor for 'Wrapper'.
After:
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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| 2b9de0bc05e3e1092a9d1880e62aeaa54dc343e3 |
|
19-Jan-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Don't show "Entered 'foo'" if 'foo' is implicit.
Before:
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)
After:
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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| e02be97811c785f91ac43a0feed2db862de1867f |
|
18-Jan-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Special path notes for C++ special member functions.
Examples:
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
/external/clang/test/Analysis/inlining/path-notes.cpp
|
| dc47c9a71c99ce2e5b9d84f1cd3487b6852b3543 |
|
18-Jan-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Do a better job describing C++ member functions in the call stack.
Examples:
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
/external/clang/test/Analysis/inlining/path-notes.cpp
|