summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Checkers/IvarInvalidationChecker.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer][NFC] Fix inconsistent references to checkers as "checks"Kristof Umann2019-09-121-8/+6
| | | | | | | | | | | | | | Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, and code originating from the early 2010's still incorrectly refer to checkers as checks. This patch attempts to hunt down most of these, aiming to refer to checkers as checkers, but preserve references to callback functions (like checkPreCall) as checks. Differential Revision: https://reviews.llvm.org/D67140 llvm-svn: 371760
* [analyzer] Add CheckerManager::getChecker, make sure that a registry ↵Kristof Umann2019-01-261-1/+1
| | | | | | | | | | | | | function registers no more than 1 checker This patch effectively fixes the almost decade old checker naming issue. The solution is to assert when CheckerManager::getChecker is called on an unregistered checker, and assert when CheckerManager::registerChecker is called on a checker that is already registered. Differential Revision: https://reviews.llvm.org/D55429 llvm-svn: 352292
* [analyzer] Reimplement dependencies between checkersKristof Umann2019-01-261-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, up until now, the fact that certain checkers depended on one another was known, but how these actually unfolded was hidden deep within the implementation. For example, many checkers (like RetainCount, Malloc or CString) modelled a certain functionality, and exposed certain reportable bug types to the user. For example, while MallocChecker models many many different types of memory handling, the actual "unix.MallocChecker" checker the user was exposed to was merely and option to this modeling part. Other than this being an ugly mess, this issue made resolving the checker naming issue almost impossible. (The checker naming issue being that if a checker registered more than one checker within its registry function, both checker object recieved the same name) Also, if the user explicitly disabled a checker that was a dependency of another that _was_ explicitly enabled, it implicitly, without "telling" the user, reenabled it. Clearly, changing this to a well structured, declarative form, where the handling of dependencies are done on a higher level is very much preferred. This patch, among the detailed things later, makes checkers declare their dependencies within the TableGen file Checkers.td, and exposes the same functionality to plugins and statically linked non-generated checkers through CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies, makes sure that checkers are added to CheckerManager in the correct order, and makes sure that if a dependency is disabled, so will be every checker that depends on it. In detail: * Add a new field to the Checker class in CheckerBase.td called Dependencies, which is a list of Checkers. * Move unix checkers before cplusplus, as there is no forward declaration in tblgen :/ * Add the following new checkers: - StackAddrEscapeBase - StackAddrEscapeBase - CStringModeling - DynamicMemoryModeling (base of the MallocChecker family) - IteratorModeling (base of the IteratorChecker family) - ValistBase - SecuritySyntaxChecker (base of bcmp, bcopy, etc...) - NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker) - IvarInvalidationModeling (base of IvarInvalidation checker family) - RetainCountBase (base of RetainCount and OSObjectRetainCount) * Clear up and registry functions in MallocChecker, happily remove old FIXMEs. * Add a new addDependency function to CheckerRegistry. * Neatly format RUN lines in files I looked at while debugging. Big thanks to Artem Degrachev for all the guidance through this project! Differential Revision: https://reviews.llvm.org/D54438 llvm-svn: 352287
* [analyzer] Supply all checkers with a shouldRegister functionKristof Umann2019-01-261-0/+4
| | | | | | | | | | | | | | | | | | Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. This will force every checker to implement this function, but maybe it isn't that bad: I saw a lot of ObjC or C++ specific checkers that should probably not register themselves based on some LangOptions (mine too), but they do anyways. A big benefit of this is that all registry functions now register their checker, once it is called, registration is guaranteed. This patch is a part of a greater effort to reinvent checker registration, more info here: D54438#1315953 Differential Revision: https://reviews.llvm.org/D55424 llvm-svn: 352277
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [analyzer][NFC] Move CheckerRegistry from the Core directory to FrontendKristof Umann2018-12-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept. It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend, whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can imagine, used to circumvent the problem that the registry functions of the checkers are located in the clangStaticAnalyzerCheckers library, but that library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend depends on both of those libraries. One can make the observation however, that CheckerRegistry has no place in Core, it isn't used there at all! The only place where it is used is Frontend, which is where it ultimately belongs. This move implies that since include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function: class CheckerRegistry; void registerBuiltinCheckers(CheckerRegistry &registry); it had to re purposed, as CheckerRegistry is no longer available to clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h, which actually describes it a lot better -- it does not contain the registration functions for checkers, but only those generated by the tblgen files. Differential Revision: https://reviews.llvm.org/D54436 llvm-svn: 349275
* Fix typos in clangAlexander Kornienko2018-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* Remove redundant casts. NFCGeorge Burgess IV2018-03-011-5/+5
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
* Remove redundant conditions of the form (A || (!A && B)) -> (A || B)Benjamin Kramer2016-04-111-2/+1
| | | | | | Found by cppcheck! PR27286 PR27287 PR27288 PR27289 llvm-svn: 265918
* Fix some Clang-tidy readability-redundant-control-flow warnings; other minor ↵Eugene Zelenko2016-02-101-11/+5
| | | | | | | | fixes. Differential revision: http://reviews.llvm.org/D17060 llvm-svn: 260414
* Class Property: change PropertyMap to include isClassProperty.Manman Ren2016-01-281-0/+2
| | | | | | | | | | | | | | PropertyMap used to map IdentifierInfo (name of the property) to ObjcPropertyDecl *. Now that a class property can have the same name as an instance property, we change PropertyMap to map a pair <IdentifierInfo *, unsigned> to ObjcPropertyDecl *. Also update a few places from iterating over instance_properties to iterating over all properties. rdar://23891898 llvm-svn: 259119
* [analyzer] Apply whitespace cleanups by Honggyu Kim.Ted Kremenek2015-09-081-3/+3
| | | | llvm-svn: 246978
* Switch users of the 'for (StmtRange range = stmt->children(); range; ↵Benjamin Kramer2015-07-021-3/+3
| | | | | | | | | ++range)‘ pattern to range for loops. The pattern was born out of the lack of range-based for loops in C++98 and is somewhat obscure. No functionality change intended. llvm-svn: 241300
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-2/+2
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-2/+2
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Remove many superfluous SmallString::str() calls.Yaron Keren2015-03-181-1/+1
| | | | | | | | | | | | | | | Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more. There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity. llvm-svn: 232622
* [C++11] Use 'nullptr'. StaticAnalyzer edition.Craig Topper2014-05-271-6/+6
| | | | llvm-svn: 209642
* [C++11] Replacing ObjCProtocolDecl iterators protocol_begin() and ↵Aaron Ballman2014-03-131-4/+2
| | | | | | protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203863
* [C++11] Replacing ObjCInterfaceDecl iterators visible_extensions_begin() and ↵Aaron Ballman2014-03-131-6/+2
| | | | | | visible_extensions_end() with iterator_range visible_extensions(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203855
* [C++11] Replacing ObjCInterfaceDecl iterators protocol_begin() and ↵Aaron Ballman2014-03-131-8/+5
| | | | | | | | protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops. Drive-by fixing some incorrect types where a for loop would be improperly using ObjCInterfaceDecl::protocol_iterator. No functional changes in these cases. llvm-svn: 203842
* [C++11] Replacing ObjCContainerDecl iterators meth_begin() and meth_end() ↵Aaron Ballman2014-03-131-8/+4
| | | | | | with iterator_range methods(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203832
* [C++11] Replacing DeclBase iterators specific_attr_begin() and ↵Aaron Ballman2014-03-101-4/+1
| | | | | | specific_attr_end() with iterator_range specific_attrs(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203474
* Expose the name of the checker producing each diagnostic message.Alexander Kornienko2014-02-111-19/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer] IvarInvalidation: correctly handle cases where only partial ↵Anna Zaks2013-04-241-13/+34
| | | | | | | | | | | | invalidators exist - If only partial invalidators exist and there are no full invalidators in @implementation, report every ivar that has not been invalidated. (Previously, we reported the first Ivar in the list, which could actually have been invalidated by a partial invalidator. The code assumed you cannot have only partial invalidators.) - Do not report missing invalidation method declaration if a partial invalidation method declaration exists. llvm-svn: 180170
* objective-C: synthesize properties in order of theirFariborz Jahanian2013-02-141-1/+2
| | | | | | | | declarations to synthesize their ivars in similar determinstic order so they are laid out in a determinstic order. // rdar://13192366 llvm-svn: 175214
* [analyzer] Invalidation checker: move the "missing implementation" checkAnna Zaks2013-02-091-12/+13
| | | | | | | | | | | | The missing definition check should be in the same category as the missing ivar validation - in this case, the intent is to invalidate in the given class, as described in the declaration, but the implementation does not perform the invalidation. Whereas the MissingInvalidationMethod checker checks the cases where the method intention is not to invalidate. The second checker has potential to have a much higher false positive rate. llvm-svn: 174787
* [analyzer] Move DefaultBool so that all checkers can share it.Anna Zaks2013-02-081-7/+0
| | | | llvm-svn: 174782
* [analyzer] Split IvarInvalidation into two checkersAnna Zaks2013-02-081-44/+86
| | | | | | | Separate the checking for the missing invalidation methods into a separate checker so that it can be turned on/off independently. llvm-svn: 174781
* [analyzer] IvarInvalidation: refactor, pull out the diagnostic printingAnna Zaks2013-02-081-49/+69
| | | | llvm-svn: 174780
* [analyzer] IvarInvalidation: add annotation for partial invalidationAnna Zaks2013-02-081-39/+78
| | | | | | | | | | | The new annotation allows having methods that only partially invalidate IVars and might not be called from the invalidation methods directly (instead, are guaranteed to be called before the invalidation occurs). The checker is going to trust the programmer to call the partial invalidation method before the invalidator.This is common in cases when partial object tear down happens before the death of the object. llvm-svn: 174779
* Rework the traversal of Objective-C categories and extensions toDouglas Gregor2013-01-161-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | consider (sub)module visibility. The bulk of this change replaces myriad hand-rolled loops over the linked list of Objective-C categories/extensions attached to an interface declaration with loops using one of the four new category iterator kinds: visible_categories_iterator: Iterates over all visible categories and extensions, hiding any that have their "hidden" bit set. This is by far the most commonly used iterator. known_categories_iterator: Iterates over all categories and extensions, ignoring the "hidden" bit. This tends to be used for redeclaration-like traversals. visible_extensions_iterator: Iterates over all visible extensions, hiding any that have their "hidden" bit set. known_extensions_iterator: Iterates over all extensions, whether they are visible to normal name lookup or not. The effect of this change is that any uses of the visible_ iterators will respect module-import visibility. See the new tests for examples. Note that the old accessors for categories and extensions are gone; there are *Raw() forms for some of them, for those (few) areas of the compiler that have to manipulate the linked list of categories directly. This is generally discouraged. Part two of <rdar://problem/10634711>. llvm-svn: 172665
* [analyzer] Fix warning typo.Anna Zaks2013-01-161-2/+2
| | | | llvm-svn: 172596
* [analyzer] Rename the warning: state the issue before the hint of how itAnna Zaks2013-01-111-6/+5
| | | | | | can be fixed llvm-svn: 172170
* [analyzer]Recognize ivar invalidation protocol even if it was redeclaredAnna Zaks2013-01-111-2/+2
| | | | | | This will get rid of some false positives as well as false negatives. llvm-svn: 172169
* [analyzer] Ivar invalidation: track ivars declared in categories.Anna Zaks2013-01-111-7/+15
| | | | llvm-svn: 172168
* [analyzer] Allow IvarInvalidation checker to suppress warnings viaAnna Zaks2013-01-101-6/+14
| | | | | | | | | | | | assertions. To ensure that custom assertions/conditional would also be supported, just check if the ivar that needs to be invalidated or set to nil is compared against 0. Unfortunately, this will not work for code containing 'assert(IvarName)' llvm-svn: 172147
* [analyzer] Fix non-determinizm introduced in r172104.Anna Zaks2013-01-101-17/+29
| | | | | | | | In some cases, we just pick any ivar that needs invalidation and attach the warning to it. Picking the first from DenseMap of pointer keys was triggering non-deterministic output. llvm-svn: 172134
* [analyzer] Add more checks to the ObjC Ivar Invalidation checker.Anna Zaks2013-01-101-57/+118
| | | | | | | | | | | | | | Restructured the checker so that it could easily find two new classes of issues: - when a class contains an invalidatable ivar, but no declaration of an invalidation method - when a class contains an invalidatable ivar, but no definition of an invalidation method in the @implementation. The second case might trigger some false positives, for example, when the method is defined in a category. llvm-svn: 172104
* [analyzer] Fix a false positive in the ivar invalidation checker.Anna Zaks2013-01-071-1/+3
| | | | | | | | | When a property is "inherited" through both a parent class and directly through a protocol, we should not require the child to invalidate it since the backing ivar belongs to the parent class. (Fixes radar://12913734) llvm-svn: 171769
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-3/+3
| | | | | | | | | | | | | uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
* Pull the Attr iteration parts out of Attr.h, so including DeclBase.h doesn't ↵Benjamin Kramer2012-12-011-0/+1
| | | | | | | | | pull in all the generated Attr code. Required to pull some functions out of line, but this shouldn't have a perf impact. No functionality change. llvm-svn: 169092
* [analyzer] Ivar invalidation: identify properties declared in protocols.Anna Zaks2012-10-181-5/+9
| | | | llvm-svn: 166211
* [analyzer] Ivar Invalidation: track ivars in continuations andAnna Zaks2012-10-161-5/+5
| | | | | | @implementation. llvm-svn: 166047
* [analyzer] Enhance the error message.Anna Zaks2012-10-151-1/+1
| | | | llvm-svn: 165993
* Move isObjCSelf into Expr.Anna Zaks2012-10-011-13/+6
| | | | llvm-svn: 164966
* [analyzer] Address Jordan's review for r164868.Anna Zaks2012-10-011-16/+14
| | | | llvm-svn: 164965
* [analyzer] Re-implement IvarInvalidationChecker so that it verifies thatAnna Zaks2012-09-291-62/+259
| | | | | | | | | | | the validation occurred. The original implementation was pessimistic - we assumed that ivars which escape are invalidated. This version is optimistic, it assumes that the ivars will always be explicitly invalidated: either set to nil or sent an invalidation message. llvm-svn: 164868
* [analyzer] IvarInvalidation: track synthesized ivars and allow escapeAnna Zaks2012-09-271-31/+69
| | | | | | through property getters. llvm-svn: 164802
* [analyzer] Address Jordan's code review comments for r164716.Anna Zaks2012-09-271-14/+16
| | | | llvm-svn: 164788
* IvarInvalidationChecker.cpp: Remove an unused member, InterfD. ↵NAKAMURA Takumi2012-09-271-2/+1
| | | | | | [-Wunused-private-field] llvm-svn: 164745
OpenPOWER on IntegriCloud