summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Don't special-case ivars backing +0 properties.Jordan Rose2015-03-301-82/+1
| | | | | | | | | Give up this checking in order to continue tracking that these values came from direct ivar access, which will be important in the next commit. Part of rdar://problem/20335433 llvm-svn: 233591
* [analyzer] RetainCountChecker: Don't assume +0 for ivars backing readonly ↵Jordan Rose2015-03-201-12/+52
| | | | | | | | | | | | properties. Similarly, don't assume +0 if the property's setter is manually implemented. In both cases, if the property's ownership is explicitly written, then we /do/ assume the ivar has the same ownership. rdar://problem/20218183 llvm-svn: 232849
* [analyzer] RetainCountChecker: CF properties are always manually retain-counted.Jordan Rose2015-03-071-8/+13
| | | | | | | | | | | In theory we could assume a CF property is stored at +0 if there's not a custom setter, but that's not really worth the complexity. What we do know is that a CF property can't have ownership attributes, and so we shouldn't assume anything about the ownership of the ivar. rdar://problem/20076963 llvm-svn: 231553
* Sema: Parenthesized bound destructor member expressions can be calledDavid Majnemer2015-02-251-1/+1
| | | | | | | | | We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
* [analyzer] RetainCountChecker: don't try to track ivars known to be nil.Jordan Rose2015-02-191-2/+4
| | | | | | | | | | | We expect in general that any nil value has no retain count information associated with it; violating this results in unexpected state unification /later/ when we decide to throw the information away. Unexpectedly caching out can lead to an assertion failure or crash. rdar://problem/19862648 llvm-svn: 229934
* Update APIs that return a pair of iterators to return an iterator_range instead.Benjamin Kramer2015-02-061-3/+2
| | | | | | Convert uses of those APIs into ranged for loops. NFC. llvm-svn: 228404
* [analyzer] Look for allocation site in the parent frames as well as the ↵Anna Zaks2015-02-051-20/+13
| | | | | | | | | | | | | current one. Instead of handling edge cases (mostly involving blocks), where we have difficulty finding an allocation statement, allow the allocation site to be in a parent node. Previously we assumed that the allocation site can always be found in the same frame as allocation, but there are scenarios in which an element is leaked in a child frame but is allocated in the parent. llvm-svn: 228247
* [analyzer] RetainCountChecker: be forgiving when ivars are accessed directly.Jordan Rose2015-02-041-82/+216
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A refinement of r204730, itself a refinement of r198953, to better handle cases where an object is accessed both through a property getter and through direct ivar access. An object accessed through a property should always be treated as +0, i.e. not owned by the caller. However, an object accessed through an ivar may be at +0 or at +1, depending on whether the ivar is a strong reference. Outside of ARC, we don't always have that information. The previous attempt would clear out the +0 provided by a getter, but only if that +0 hadn't already participated in other retain counting operations. (That is, "self.foo" is okay, but "[[self.foo retain] autorelease]" is problematic.) This turned out to not be good enough when our synthesized getters get involved. This commit drops the notion of "overridable" reference counting and instead just tracks whether a value ever came from a (strong) ivar. If it has, we allow one more release than we otherwise would. This has the added benefit of being able to catch /some/ overreleases of instance variables, though it's not likely to come up in practice. We do still get some false negatives because we currently throw away refcount state upon assigning a value into an ivar. We should probably improve on that in the future, especially once we synthesize setters as well as getters. rdar://problem/18075108 llvm-svn: 228174
* Use nullptr to silence -Wsentinel when self-hosting on WindowsReid Kleckner2014-12-011-7/+7
| | | | | | | | | | | Richard rejected my Sema change to interpret an integer literal zero in a varargs context as a null pointer, so -Wsentinel sees an integer literal zero and fires off a warning. Only CodeGen currently knows that it promotes integer literal zeroes in this context to pointer size on Windows. I didn't want to teach -Wsentinel about that compatibility hack. Therefore, I'm migrating to C++11 nullptr. llvm-svn: 223079
* unique_ptrify BugReporter::visitorsDavid Blaikie2014-09-041-5/+5
| | | | llvm-svn: 217205
* unique_ptr-ify PathDiagnosticPiece ownershipDavid Blaikie2014-08-291-13/+11
| | | | llvm-svn: 216751
* Objective-C. Warn if user has made explicit callFariborz Jahanian2014-08-221-0/+1
| | | | | | | to +initilize as this results in an extra call to this method. rdar://16628028 llvm-svn: 216271
* Fix a crash in Retain Count checker error reportingAnna Zaks2014-06-131-5/+18
| | | | | | | | | Fixes a crash in Retain Count checker error reporting logic by handing the allocation statement retrieval from a BlockEdge program point. Also added a simple CFG dump routine for debugging. llvm-svn: 210960
* [C++11] Use 'nullptr'. StaticAnalyzer edition.Craig Topper2014-05-271-28/+28
| | | | llvm-svn: 209642
* [analyzer] When checking Foundation method calls, match the selectors exactly.Jordan Rose2014-04-091-12/+4
| | | | | | | | | | This also includes some infrastructure to make it easier to build multi-argument selectors, rather than trying to use string matching on each piece. There's a bit more setup code, but less cost at runtime. PR18908 llvm-svn: 205827
* [analyzer] Don't track retain counts of objects directly accessed through ivars.Jordan Rose2014-03-251-22/+111
| | | | | | | | | | | | | | | | | | | | | A refinement of r198953 to handle cases where an object is accessed both through a property getter and through direct ivar access. An object accessed through a property should always be treated as +0, i.e. not owned by the caller. However, an object accessed through an ivar may be at +0 or at +1, depending on whether the ivar is a strong reference. Outside of ARC, we don't have that information, so we just don't track objects accessed through ivars. With this change, accessing an ivar directly will deliberately override the +0 provided by a getter, but only if the +0 hasn't participated in other retain counting yet. That isn't perfect, but it's already unusual for people to be mixing property access with direct ivar access. (The primary use case for this is in setters, init methods, and -dealloc.) Thanks to Ted for spotting a few mistakes in private review. <rdar://problem/16333368> llvm-svn: 204730
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-151-22/+22
| | | | | | class. llvm-svn: 203999
* Replace OwningPtr with std::unique_ptr.Ahmed Charles2014-03-071-7/+7
| | | | | | This compiles cleanly with lldb/lld/clang-tools-extra/llvm. llvm-svn: 203279
* [analyzer] Improved checker naming in CFG dump.Anton Yartsev2014-02-171-10/+8
| | | | | | This implements FIXME from Checker.cpp (FIXME: We want to return the package + name of the checker here.) and replaces hardcoded checker names with the new ones obtained via getCheckName().getName(). llvm-svn: 201525
* Expose the name of the checker producing each diagnostic message.Alexander Kornienko2014-02-111-27/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In clang-tidy we'd like to know the name of the checker producing each diagnostic message. PathDiagnostic has BugType and Category fields, which are both arbitrary human-readable strings, but we need to know the exact name of the checker in the form that can be used in the CheckersControlList option to enable/disable the specific checker. This patch adds the CheckName field to the CheckerBase class, and sets it in the CheckerManager::registerChecker() method, which gets them from the CheckerRegistry. Checkers that implement multiple checks have to store the names of each check in the respective registerXXXChecker method. Reviewers: jordan_rose, krememek Reviewed By: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2557 llvm-svn: 201186
* Rename getResultType() on function and method declarations to getReturnType()Alp Toker2014-01-251-6/+6
| | | | | | | | | | | | | | | A return type is the declared or deduced part of the function type specified in the declaration. A result type is the (potentially adjusted) type of the value of an expression that calls the function. Rule of thumb: * Declarations have return types and parameters. * Expressions have result types and arguments. llvm-svn: 200082
* Rename FunctionProtoType accessors from 'arguments' to 'parameters'Alp Toker2014-01-201-1/+1
| | | | | | | | | | | | | | | | | Fix a perennial source of confusion in the clang type system: Declarations and function prototypes have parameters to which arguments are supplied, so calling these 'arguments' was a stretch even in C mode, let alone C++ where default arguments, templates and overloading make the distinction important to get right. Readability win across the board, especially in the casting, ADL and overloading implementations which make a lot more sense at a glance now. Will keep an eye on the builders and update dependent projects shortly. No functional change. llvm-svn: 199686
* [analyzer] BlockCall shouldn't really be an AnyFunctionCall.Jordan Rose2014-01-151-2/+2
| | | | | | | | | | | | | | Per discussion with Anna a /long/ time ago, it was way too easy to misuse BlockCall: because it inherited from AnyFunctionCall (through SimpleCall), getDecl() was constrained to return a FunctionDecl, and you had to call getBlockDecl() instead. This goes against the whole point of CallEvent (to abstract over different ways to invoke bodies of code). Now, BlockCall just inherits directly from CallEvent. There's a bit of duplication in getting things out of the origin expression (which is still known to be a CallExpr), but nothing significant. llvm-svn: 199321
* [analyzer] Model getters of known-@synthesized Objective-C properties.Jordan Rose2014-01-101-0/+19
| | | | | | | | | | | | | | | | | | | | | ...by synthesizing their body to be "return self->_prop;", with an extra nudge to RetainCountChecker to still treat the value as +0 if we have no other information. This doesn't handle weak properties, but that's mostly correct anyway, since they can go to nil at any time. This also doesn't apply to properties whose implementations we can't see, since they may not be backed by an ivar at all. And finally, this doesn't handle properties of C++ class type, because we can't invoke the copy constructor. (Sema has actually done this work already, but the AST it synthesizes is one the analyzer doesn't quite handle -- it has an rvalue DeclRefExpr.) Modeling setters is likely to be more difficult (since it requires handling strong/copy), but not impossible. <rdar://problem/11956898> llvm-svn: 198953
* [analyzer] Remove unused ARCNotOwnedSymbol retain count return effect.Jordan Rose2014-01-071-3/+2
| | | | | | | | | | | | RetainCountChecker has to track returned object values to know if they are retained or not. Under ARC, even methods that return +1 are tracked by the system and should be treated as +0. However, this effect behaves exactly like NotOwned(ObjC), i.e. a generic Objective-C method that actually returns +0, so we don't need a special case for it. No functionality change. llvm-svn: 198709
* Sort all the #include lines with LLVM's utils/sort_includes.py whichChandler Carruth2014-01-071-3/+2
| | | | | | | encodes the canonical rules for LLVM's style. I noticed this had drifted quite a bit when cleaning up LLVM, so wanted to clean up Clang as well. llvm-svn: 198686
* [analyzer] Don't track return value of NSNull +null for retain/release tracking.Ted Kremenek2014-01-031-0/+5
| | | | | | Fixes <rdar://problem/12858915>. llvm-svn: 198388
* Replacing calls to getAttr with calls to hasAttr for clarity. No functional ↵Aaron Ballman2013-12-191-14/+14
| | | | | | change intended -- this only replaces Boolean uses of getAttr. llvm-svn: 197648
* Forgot some references to misspelled enums.Benjamin Kramer2013-10-201-4/+4
| | | | llvm-svn: 193047
* Miscellaneous speling fixes.Benjamin Kramer2013-10-201-1/+1
| | | | llvm-svn: 193046
* [analyzer] RetainCountChecker: add support for CFAutorelease.Jordan Rose2013-10-071-8/+22
| | | | | | <rdar://problems/13710586&13710643> llvm-svn: 192113
* [analyzer] Stop tracking the objects with attribute cleanup in the ↵Anna Zaks2013-09-171-0/+10
| | | | | | | | RetainCountChecker. This suppresses false positive leaks. We stop tracking a value if it is assigned to a variable declared with a cleanup attribute. llvm-svn: 190835
* Get rid of unused isPodLike definition.Eli Friedman2013-09-111-2/+0
| | | | llvm-svn: 190463
* Use the number of parameters in the actual method or function to determine ↵Ted Kremenek2013-08-161-7/+1
| | | | | | the CallEffects size. llvm-svn: 188587
* RetainCountChecker: Replace some loops with std:: algorithms.Benjamin Kramer2013-08-161-17/+5
| | | | llvm-svn: 188581
* Revert r188574. Turns out it isn't needed.Ted Kremenek2013-08-161-1/+0
| | | | llvm-svn: 188578
* Need summary info. about arguments toFariborz Jahanian2013-08-161-0/+1
| | | | | | CF functions coming from static analyzer API. llvm-svn: 188574
* [static analyzer] add a simple "CallEffects" API to query the retain count ↵Ted Kremenek2013-08-141-0/+44
| | | | | | | | | | | | | | semantics of a method. This is intended to be a simplified API, whose internals are deliberately less efficient for the purpose of a simplified interface, for use with clients that want to query the analyzer's heuristics for determining retain count semantics. There are no immediate clients, but it is intended to be used by the ObjC modernizer. llvm-svn: 188433
* [static analyzer] Factor out ArgEffect and RetEffect into public header file.Ted Kremenek2013-08-141-93/+14
| | | | | | | This is a WIP change to allow other clients to query the retain count heuristics of the static analyzer. llvm-svn: 188432
* [analyzer] Don't process autorelease counts in synthesized function bodies.Jordan Rose2013-08-011-1/+8
| | | | | | | | | | | | | | | 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> llvm-svn: 187625
* [analyzer] RetainCountChecker: don't track through xpc_connection_set_context.Jordan Rose2013-05-021-2/+4
| | | | | | | | | | | | It is unfortunate that we have to mark these exceptions in multiple places. This was already in CallEvent. I suppose it does let us be more precise about saying /which/ arguments have their retain counts invalidated -- the connection's is still valid even though the context object's isn't -- but we're not tracking the retain count of XPC objects anyway. <rdar://problem/13783514> llvm-svn: 180904
* [analyzer] Fix a crash in RetainCountChecker - we should not rely on ↵Anna Zaks2013-04-251-1/+1
| | | | | | | | | | | CallEnter::getCallExpr to return non-NULL We get a CallEnter with a null expression, when processing a destructor. All other users of CallEnter::getCallExpr work fine with null as return value. (Addresses PR15832, Thanks to Jordan for reducing the test case!) llvm-svn: 180234
* [analyzer] Set the allocation site to be the uniqueing location for retain ↵Anna Zaks2013-04-231-2/+11
| | | | | | | | | | count checker leaks. The uniqueing location is the location which is part of the hash used to determine if two reports are the same. This is used by the CmpRuns.py script to compare two analyzer runs and determine which warnings are new. llvm-svn: 180166
* [analyzer] RetainCountChecker: Clean up path notes for autorelease.Jordan Rose2013-04-231-7/+9
| | | | | | | | No functionality change. <rdar://problem/13710586> llvm-svn: 180075
* [analyzer] Add experimental option "leak-diagnostics-reference-allocation".Ted Kremenek2013-04-161-10/+25
| | | | | | | | | | | | | | This is an opt-in tweak for leak diagnostics to reference the allocation site if the diagnostic consumer only wants a pithy amount of information, and not the entire path. This is a strawman enhancement that I expect to see some experimentation with over the next week, and can go away if we don't want it. Currently it is only used by RetainCountChecker, but could be used by MallocChecker if and when we decide this should stay in. llvm-svn: 179634
* [analyzer] Address Jordan’s review of r179219Anna Zaks2013-04-101-1/+1
| | | | llvm-svn: 179235
* [analyzer] Address Jordan’s code review of r 179221Anna Zaks2013-04-101-13/+17
| | | | llvm-svn: 179234
* [analyzer] When reporting a leak in RetainCount checker due to an early exit ↵Anna Zaks2013-04-101-14/+63
| | | | | | | | | from init, step into init. The heuristic here (proposed by Jordan) is that, usually, if a leak is due to an early exit from init, the allocation site will be a call to alloc. Note that in other cases init resets self to [super init], which becomes the allocation site of the object. llvm-svn: 179221
* [analyzer] Cleanup leak warnings: do not print the names of variables from ↵Anna Zaks2013-04-101-1/+8
| | | | | | other functions. llvm-svn: 179219
* [analyzer] RetainCountChecker: refactor annotation handling.Jordan Rose2013-04-041-63/+41
| | | | | | | | | ...and add a new test case. I thought this was broken, but it isn't; refactoring and reformatting anyway so that I don't make the same mistake again. No functionality change. llvm-svn: 178799
OpenPOWER on IntegriCloud