summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis/inline.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] operator new: Use the correct region for the constructor.Artem Dergachev2018-01-171-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The -analyzer-config c++-allocator-inlining experimental option allows the analyzer to reason about C++ operator new() similarly to how it reasons about regular functions. In this mode, operator new() is correctly called before the construction of an object, with the help of a special CFG element. However, the subsequent construction of the object was still not performed into the region of memory returned by operator new(). The patch fixes it. Passing the value from operator new() to the constructor and then to the new-expression itself was tricky because operator new() has no call site of its own in the AST. The new expression itself is not a good call site because it has an incorrect type (operator new() returns 'void *', while the new expression is a pointer to the allocated object type). Additionally, lifetime of the new expression in the environment makes it unsuitable for passing the value. For that reason, an additional program state trait is introduced to keep track of the return value. Finally this patch relaxes restrictions on the memory region class that are required for inlining the constructor. This change affects the old mode as well (c++-allocator-inlining=false) and seems safe because these restrictions were an overkill compared to the actual problems observed. Differential Revision: https://reviews.llvm.org/D40560 rdar://problem/12180598 llvm-svn: 322774
* Reland 4: [analyzer] NFC: Update test infrastructure to support multiple ↵Dominic Chen2017-03-031-1/+1
| | | | | | | | | | | | | | constraint managers Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 llvm-svn: 296895
* Revert "Reland 3: [analyzer] NFC: Update test infrastructure to support ↵Dominic Chen2017-03-021-1/+1
| | | | | | | | multiple constraint managers" This reverts commit ea36f1406e1f36bf456c3f3929839b024128e468. llvm-svn: 296841
* Reland 3: [analyzer] NFC: Update test infrastructure to support multiple ↵Dominic Chen2017-03-021-1/+1
| | | | | | | | | | | | | | constraint managers Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 llvm-svn: 296837
* Revert "Reland 2: [analyzer] NFC: Update test infrastructure to support ↵Dominic Chen2017-03-021-1/+1
| | | | | | | | multiple constraint managers" This reverts commit f93343c099fff646a2314cc7f4925833708298b1. llvm-svn: 296836
* Reland 2: [analyzer] NFC: Update test infrastructure to support multiple ↵Dominic Chen2017-03-021-1/+1
| | | | | | | | | | | | | | constraint managers Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 llvm-svn: 296835
* Revert "Reland: [analyzer] NFC: Update test infrastructure to support ↵Dominic Chen2017-02-281-1/+1
| | | | | | | | multiple constraint managers" This reverts commit 1b28d0b10e1c8feccb971abb6ef7a18bee589830. llvm-svn: 296422
* Reland: [analyzer] NFC: Update test infrastructure to support multiple ↵Dominic Chen2017-02-281-1/+1
| | | | | | | | | | | | | | constraint managers Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 llvm-svn: 296414
* Revert "[analyzer] NFC: Update test infrastructure to support multiple ↵Dominic Chen2017-02-271-1/+1
| | | | | | | | constraint managers" This reverts commit 8e7780b9e59ddaad1800baf533058d2c064d4787. llvm-svn: 296317
* [analyzer] NFC: Update test infrastructure to support multiple constraint ↵Dominic Chen2017-02-271-1/+1
| | | | | | | | | | | | | | managers Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 llvm-svn: 296312
* [analyzer] Add check for when block is called with too few arguments.Devin Coughlin2016-11-151-1/+1
| | | | | | | | | The CallAndMessageChecker has an existing check for when a function pointer is called with too few arguments. Extend this logic to handle the block case, as well. While we're at it, do a drive-by grammar correction ("less" --> "fewer") on the diagnostic text. llvm-svn: 287001
* [analyzer] Improve modeling of static initializers.Anna Zaks2015-11-191-1/+8
| | | | | | | | | | | | Conversions between unrelated pointer types (e.g. char * and void *) involve bitcasts which were not properly modeled in case of static initializers. The patch fixes this problem. The problem was originally spotted by Artem Dergachev. Patched by Yuri Gribov! Differential Revision: http://reviews.llvm.org/D14652 llvm-svn: 253532
* [analyzer] Inline C++ operator new when c++-inline-allocators is turned on.Jordan Rose2014-02-111-1/+2
| | | | | | | | | This will let us stage in the modeling of operator new. The -analyzer-config opton 'c++-inline-allocators' is currently off by default. Patch by Karthik Bhat! llvm-svn: 201122
* [analyzer] Handle C string default values for const char * arguments.Jordan Rose2013-07-171-0/+9
| | | | | | | | | | 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. llvm-svn: 186520
* Fix a crash in the static analyzer (bug #16307)Pavel Labath2013-06-191-0/+7
| | | | | | | | | | | | | | | 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 llvm-svn: 184288
* [analyzer] Don't try to evaluate MaterializeTemporaryExpr as a constant.Jordan Rose2013-05-021-3/+24
| | | | | | | | | | | | | | | ...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. llvm-svn: 180944
* [analyzer] Type information from C++ new expressions is perfect.Jordan Rose2013-04-221-3/+1
| | | | | | | This improves our handling of dynamic_cast and devirtualization for objects allocated by 'new'. llvm-svn: 180051
* [analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, ↵Anton Yartsev2013-03-251-0/+1
| | | | | | double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
* [analyzer] Handle reference parameters with default values.Jordan Rose2013-02-251-0/+9
| | | | | | | | | | | | 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. llvm-svn: 176042
* [analyzer] Use Clang's evaluation for global constants and default arguments.Jordan Rose2013-02-131-9/+33
| | | | | | | | | | | 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> llvm-svn: 175026
* [analyzer] Replace "-analyzer-ipa" with "-analyzer-config ipa".Anna Zaks2013-01-241-2/+2
| | | | | | | | | 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. llvm-svn: 173385
* [analyzer] Adjust the return type of an inlined devirtualized method call.Jordan Rose2012-10-031-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | 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> llvm-svn: 165079
* [analyzer] Member function calls that use qualified names are non-virtual.Jordan Rose2012-09-111-0/+15
| | | | | | | | | | | 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> llvm-svn: 163577
* [analyzer] Cast the result of a placement new-expression to the correct type.Jordan Rose2012-09-081-0/+26
| | | | | | | | | | | 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. llvm-svn: 163442
* [analyzer] Fail gracefully when the dynamic type is outside the hierarchy.Jordan Rose2012-09-071-0/+32
| | | | | | | | | | | | | | | | | | | With some particularly evil casts, we can get an object whose dynamic type is not actually a subclass of its static type. In this case, we won't even find the statically-resolved method as a devirtualization candidate. Rather than assert that this situation cannot occur, we now simply check that the dynamic type is not an ancestor or descendent of the static type, and leave it at that. This error actually occurred analyzing LLVM: CallEventManager uses a BumpPtrAllocator to allocate a concrete subclass of CallEvent (FunctionCall), but then casts it to the actual subclass requested (such as ObjCMethodCall) to perform the constructor. Yet another crash in PR13763. llvm-svn: 163367
* [analyzer] Though C++ inlining is enabled, don't inline ctors and dtors.Jordan Rose2012-08-311-17/+0
| | | | | | | | | | | | | | | | 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'. llvm-svn: 163004
* [analyzer] Teach CallEventManager that CXXTemporaryObjectExpr is also a ctor.Jordan Rose2012-08-281-0/+17
| | | | | | | | | | | | | | 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 llvm-svn: 162792
* [analyzer] Don't inline constructors for objects allocated with operator new.Jordan Rose2012-08-271-1/+41
| | | | | | | | | | | 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>. llvm-svn: 162689
* [analyzer] Support C++ default arguments if they are literal values.Jordan Rose2012-08-231-0/+34
| | | | | | | | | | | | | | | | | | 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> llvm-svn: 162453
* [analyzer] Even if we are not inlining a virtual call, still invalidate!Jordan Rose2012-08-151-0/+27
| | | | | | Fixes a mistake introduced in r161916. llvm-svn: 161987
* [analyzer] Be more careful when downcasting for devirtualization.Jordan Rose2012-08-131-0/+57
| | | | | | | | | 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. llvm-svn: 161808
* [analyzer] Strip CXXBaseObjectRegions when devirtualizing method calls.Jordan Rose2012-08-101-0/+38
| | | | | | | | | 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> llvm-svn: 161710
* [analyzer] Try to devirtualize even if the static callee has no definition.Jordan Rose2012-08-101-0/+28
| | | | | | | This mostly affects pure virtual methods, but would also affect parent methods defined inline in the header when analyzing the child's source file. llvm-svn: 161709
* [analyzer] Don't inline virtual calls unless we can devirtualize properly.Jordan Rose2012-07-121-0/+45
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. llvm-svn: 160094
OpenPOWER on IntegriCloud