| df70700f5aa5744d7f70fb3e6610ff434f643a71 |
|
17-Jul-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Handle C string default values for const char * arguments.
Previously, SValBuilder knew how to evaluate StringLiterals, but couldn't
handle an array-to-pointer decay for constant values. Additionally,
RegionStore was being too strict about loading from an array, refusing to
return a 'char' value from a 'const char' array. Both of these have been
fixed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186520 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 37926da411d5a0047240b3ffd4dad0c4838aac57 |
|
19-Jun-2013 |
Pavel Labath <labath@google.com> |
Fix a crash in the static analyzer (bug #16307)
Summary:
When processing a call to a function, which got passed less arguments than it
expects, the analyzer would crash.
I've also added a test for that and a analyzer warning which detects these
cases.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D994
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184288 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 4b75085f5669efc6407c662b5686361624c3ff2f |
|
02-May-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Don't try to evaluate MaterializeTemporaryExpr as a constant.
...and don't consider '0' to be a null pointer constant if it's the
initializer for a float!
Apparently null pointer constant evaluation looks through both
MaterializeTemporaryExpr and ImplicitCastExpr, so we have to be more
careful about types in the callers. For RegionStore this just means giving
up a little more; for ExprEngine this means handling the
MaterializeTemporaryExpr case explicitly.
Follow-up to r180894.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180944 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 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
/external/clang/test/Analysis/inline.cpp
|
| 2de19edab6001d2c17720d02fe0760b9b452192a |
|
25-Mar-2013 |
Anton Yartsev <anton.yartsev@gmail.com> |
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177849 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| fbdbed3bde8577815826b9d15790e5effb913f7b |
|
25-Feb-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Handle reference parameters with default values.
r175026 added support for default values, but didn't take reference
parameters into account, which expect the default argument to be an
lvalue. Use createTemporaryRegionIfNeeded if we can evaluate the default
expr as an rvalue but the expected result is an lvalue.
Fixes the most recent report of PR12915. The original report predates
default argument support, so that can't be it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176042 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 38f68ef19cb51d5876e9025b5fceb44b33ec9ed7 |
|
13-Feb-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Use Clang's evaluation for global constants and default arguments.
Previously, we were handling only simple integer constants for globals and
the smattering of implicitly-valued expressions handled by Environment for
default arguments. Now, we can use any integer constant expression that
Clang can evaluate, in addition to everything we handled before.
PR15094 / <rdar://problem/12830437>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175026 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 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
/external/clang/test/Analysis/inline.cpp
|
| 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.
<rdar://problem/12409977>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165079 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 00b4f64ecb26b031c1f4888f39be6c706156356a |
|
11-Sep-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Member function calls that use qualified names are non-virtual.
C++11 [expr.call]p1: ...If the selected function is non-virtual, or if the
id-expression in the class member access expression is a qualified-id,
that function is called. Otherwise, its final overrider in the dynamic type
of the object expression is called.
<rdar://problem/12255556>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163577 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 9874f597ef5d5748695c88daaa9a3208f95c2032 |
|
08-Sep-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Cast the result of a placement new-expression to the correct type.
This is necessary because further analysis will assume that the SVal's
type matches the AST type. This caused a crash when trying to perform
a derived-to-base cast on a C++ object that had been new'd to be another
object type.
Yet another crash in PR13763.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163442 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 8f0d0fef5f90b16600cdb802d5d7344417c34aad |
|
07-Sep-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Fail gracefully when the dynamic type is outside the hierarchy.
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163367 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| de5277fc555551857602bd7a7e5e616274e2d4a6 |
|
31-Aug-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Though C++ inlining is enabled, don't inline ctors and dtors.
More generally, this adds a new configuration option 'c++-inlining', which
controls which C++ member functions can be considered for inlining. This
uses the new -analyzer-config table, so the cc1 arguments will look like this:
... -analyzer-config c++-inlining=[none|methods|constructors|destructors]
Note that each mode implies that all the previous member function kinds
will be inlined as well; it doesn't make sense to inline destructors
without inlining constructors, for example.
The default mode is 'methods'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163004 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 827eeb63614309bafac9d77a5a3a7ca81f1e4751 |
|
28-Aug-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Teach CallEventManager that CXXTemporaryObjectExpr is also a ctor.
Specifically, CallEventManager::getCaller was looking at the call site for
an inlined call and trying to see what kind of call it was, but it only
checked for CXXConstructExprClass. (It's not using an isa<> here to avoid
doing three more checks on the the statement class.)
This caused an unreachable when we actually did inline the constructor of a
temporary object.
PR13717
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162792 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 6fe4dfbc9e5a7018763b1d898876d9b2b8ec3425 |
|
27-Aug-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Don't inline constructors for objects allocated with operator new.
Because the CXXNewExpr appears after the CXXConstructExpr in the CFG, we don't
actually have the correct region to construct into at the time we decide
whether or not to inline. The long-term fix (discussed in PR12014) might be to
introduce a new CFG node (CFGAllocator) that appears before the constructor.
Tracking the short-term fix in <rdar://problem/12180598>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162689 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| b66529d04727dc686b97ea3d937fc9785792f505 |
|
23-Aug-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Support C++ default arguments if they are literal values.
A CXXDefaultArgExpr wraps an Expr owned by a ParmVarDecl belonging to the
called function. In general, ExprEngine and Environment ought to treat this
like a ParenExpr or other transparent wrapper expression, with the inside
expression evaluated first.
However, if we call the same function twice, we'd produce a CFG that contains
the same wrapped expression twice, and we're not set up to handle that. I've
added a FIXME to the CFG builder to come back to that, but meanwhile we can
at least handle expressions that don't need to be explicitly evaluated:
literals. This probably handles many common uses of default parameters:
true/false, null, etc.
Part of PR13385 / <rdar://problem/12156507>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162453 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| da29ac527063fc9714547088bf841bfa30557bf0 |
|
15-Aug-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Even if we are not inlining a virtual call, still invalidate!
Fixes a mistake introduced in r161916.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161987 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 8ec104b9fffb917924c495ce3dd25694e4e3087a |
|
14-Aug-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Be more careful when downcasting for devirtualization.
Virtual base regions are never layered, so simply stripping them off won't
necessarily get you to the correct casted class. Instead, what we want is
the same logic for evaluating dynamic_cast: strip off base regions if possible,
but add new base regions if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161808 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| b6d2bea04801cb66263de2f3fe99ef8e1dcd9f53 |
|
11-Aug-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Strip CXXBaseObjectRegions when devirtualizing method calls.
This was causing a crash when we tried to re-apply a base object region to
itself. It probably also caused incorrect offset calculations in RegionStore.
PR13569 / <rdar://problem/12076683>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161710 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| 9584f67b6da17283a31dedf0a1cab2d83a3d121c |
|
11-Aug-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Try to devirtualize even if the static callee has no definition.
This mostly affects pure virtual methods, but would also affect parent
methods defined inline in the header when analyzing the child's source file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161709 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|
| c36b30c92c78b95fd29fb5d9d6214d737b3bcb02 |
|
12-Jul-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Don't inline virtual calls unless we can devirtualize properly.
Previously we were using the static type of the base object to inline
methods, whether virtual or non-virtual. Now, we try to see if the base
object has a known type, and if so ask for its implementation of the method.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160094 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inline.cpp
|