651f13cea278ec967336033dd032faef0e9fc2ec |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Updated to Clang 3.5a. Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/test/Analysis/inline.cpp
|
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
|