summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Checkers/CallAndMessageChecker.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer][NFC] Fix inconsistent references to checkers as "checks"Kristof Umann2019-09-121-4/+4
| | | | | | | | | | | | | | 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] NFC: Introduce sub-classes for path-sensitive and basic reports.Artem Dergachev2019-09-091-9/+10
| | | | | | | | | | | | | Checkers are now required to specify whether they're creating a path-sensitive report or a path-insensitive report by constructing an object of the respective type. This makes BugReporter more independent from the rest of the Static Analyzer because all Analyzer-specific code is now in sub-classes. Differential Revision: https://reviews.llvm.org/D66572 llvm-svn: 371450
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-8/+8
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* [analyzer] Add CheckerManager::getChecker, make sure that a registry ↵Kristof Umann2019-01-261-2/+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-23/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [analyzer] Rename trackNullOrUndefValue to trackExpressionValueGeorge Karpenkov2018-10-231-9/+9
| | | | | | | | | | | | trackNullOrUndefValue is a long and confusing name, and it does not actually reflect what the function is doing. Give a function a new name, with a relatively clear semantics. Also remove some dead code. Differential Revision: https://reviews.llvm.org/D52758 llvm-svn: 345064
* Move some helpers from the global namespace into anonymous ones.Benjamin Kramer2018-10-131-0/+2
| | | | llvm-svn: 344468
* [analyzer] Improve tracing for uninitialized struct fieldsGeorge Karpenkov2018-08-291-0/+2
| | | | | | | | rdar://13729267 Differential Revision: https://reviews.llvm.org/D51323 llvm-svn: 340986
* [analyzer] [NFC] Move class definition out of the functionGeorge Karpenkov2018-08-291-41/+40
| | | | | | Differential Revision: https://reviews.llvm.org/D51322 llvm-svn: 340964
* [analyzer] In getSVal() API, disable auto-detection of void type as char type.Artem Dergachev2017-12-121-1/+1
| | | | | | | | | | | | | | | | | | This is a follow-up from r314910. When a checker developer attempts to dereference a location in memory through ProgramState::getSVal(Loc) or ProgramState::getSVal(const MemRegion *), without specifying the second optional QualType parameter for the type of the value he tries to find at this location, the type is auto-detected from location type. If the location represents a value beyond a void pointer, we thought that auto-detecting the type as 'char' is a good idea. However, in most practical cases, the correct behavior would be to specify the type explicitly, as it is available from other sources, and the few cases where we actually need to take a 'char' are workarounds rather than an intended behavior. Therefore, try to fail with an easy-to-understand assertion when asked to read from a void pointer location. Differential Revision: https://reviews.llvm.org/D38801 llvm-svn: 320451
* [analyzer] Clarify 'uninitialized function argument' messagesDaniel Marjamaki2017-03-081-31/+45
| | | | | | Differential Revision: https://reviews.llvm.org/D30341 llvm-svn: 297283
* [analyzer] Add check for when block is called with too few arguments.Devin Coughlin2016-11-151-8/+13
| | | | | | | | | 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] Fix typo s/initalize/initialize/Chih-Hung Hsieh2016-03-231-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D18363 llvm-svn: 264164
* Support watchOS and tvOS driver optionsTim Northover2015-10-301-1/+2
| | | | | | | | This patch should add support for almost all command-line options and driver tinkering necessary to produce a correct "clang -cc1" invocation for watchOS and tvOS. llvm-svn: 251706
* SourceRanges are small and trivially copyable, don't them by reference.Craig Topper2015-10-041-2/+2
| | | | llvm-svn: 249259
* [analyzer] Add generateErrorNode() APIs to CheckerContext.Devin Coughlin2015-09-161-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The analyzer trims unnecessary nodes from the exploded graph before reporting path diagnostics. However, in some cases it can trim all nodes (including the error node), leading to an assertion failure (see https://llvm.org/bugs/show_bug.cgi?id=24184). This commit addresses the issue by adding two new APIs to CheckerContext to explicitly create error nodes. Unless the client provides a custom tag, these APIs tag the node with the checker's tag -- preventing it from being trimmed. The generateErrorNode() method creates a sink error node, while generateNonFatalErrorNode() creates an error node for a path that should continue being explored. The intent is that one of these two methods should be used whenever a checker creates an error node. This commit updates the checkers to use these APIs. These APIs (unlike addTransition() and generateSink()) do not take an explicit Pred node. This is because there are not any error nodes in the checkers that were created with an explicit different than the default (the CheckerContext's Pred node). It also changes generateSink() to require state and pred nodes (previously these were optional) to reduce confusion. Additionally, there were several cases where checkers did check whether a generated node could be null; we now explicitly check for null in these places. This commit also includes a test case written by Ying Yi as part of http://reviews.llvm.org/D12163 (that patch originally addressed this issue but was reverted because it introduced false positive regressions). Differential Revision: http://reviews.llvm.org/D12780 llvm-svn: 247859
* [analyzer] Skip Pre/Post handlers for ObjC calls when receiver is nil.Devin Coughlin2015-09-151-13/+12
| | | | | | | | | | | | | | | | | | | | | | | | | In Objective-C, method calls with nil receivers are essentially no-ops. They do not fault (although the returned value may be garbage depending on the declared return type and architecture). Programmers are aware of this behavior and will complain about a false alarm when the analyzer diagnoses API violations for method calls when the receiver is known to be nil. Rather than require each individual checker to be aware of this behavior and suppress a warning when the receiver is nil, this commit changes ExprEngineObjC so that VisitObjCMessage skips calling checker pre/post handlers when the receiver is definitely nil. Instead, it adds a new event, ObjCMessageNil, that is only called in that case. The CallAndMessageChecker explicitly cares about this case, so I've changed it to add a callback for ObjCMessageNil and moved the logic in PreObjCMessage that handles nil receivers to the new callback. rdar://problem/18092611 Differential Revision: http://reviews.llvm.org/D12123 llvm-svn: 247653
* Clarify pointer ownership semantics by hoisting the std::unique_ptr creation ↵Aaron Ballman2015-06-231-16/+16
| | | | | | to the caller instead of hiding it in emitReport. NFC. llvm-svn: 240400
* [C++11] Use 'nullptr'. StaticAnalyzer edition.Craig Topper2014-05-271-3/+3
| | | | llvm-svn: 209642
* [analyzer] Warn when passing pointers to const but uninitialized memory.Jordan Rose2014-03-131-23/+109
| | | | | | | | | | | | | | | | | Passing a pointer to an uninitialized memory buffer is normally okay, but if the function is declared to take a pointer-to-const then it's very unlikely it will be modifying the buffer. In this case the analyzer should warn that there will likely be a read of uninitialized memory. This doesn't check all elements of an array, only the first one. It also doesn't yet check Objective-C methods, only C functions and C++ methods. This is controlled by a new check: alpha.core.CallAndMessageUnInitRefArg. Patch by Per Viberg! llvm-svn: 203822
* [C++11] Replacing RecordDecl iterators field_begin() and field_end() with ↵Aaron Ballman2014-03-081-4/+3
| | | | | | iterator_range fields(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203355
* Replace OwningPtr with std::unique_ptr.Ahmed Charles2014-03-071-22/+20
| | | | | | This compiles cleanly with lldb/lld/clang-tools-extra/llvm. llvm-svn: 203279
* [C++11] Replace llvm::tie with std::tie.Benjamin Kramer2014-03-021-4/+3
| | | | llvm-svn: 202639
* [analyzer] Improved checker naming in CFG dump.Anton Yartsev2014-02-171-1/+1
| | | | | | 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-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fixed a FIXME; created a print method for Selectors that accepts a ↵Aaron Ballman2014-01-031-2/+3
| | | | | | | | raw_ostream, and started using it in places it made sense. No functional changes intended, just API cleanliness. llvm-svn: 198428
* [analyzer] Add missing return after function pointer null check.Jordan Rose2013-10-021-0/+1
| | | | | | | | | | | | | | | | | Also add some tests that there is actually a message and that the bug is actually a hard error. This actually behaved correctly before, because: - addTransition() doesn't actually add a transition if the new state is null; it assumes you want to propagate the predecessor forward and does nothing. - generateSink() is called in order to emit a bug report. - If at least one new node has been generated, the predecessor node is /not/ propagated forward. But now it's spelled out explicitly. Found by Richard Mazorodze, who's working on a patch that may require this. llvm-svn: 191805
* Clean up some Triple usage in clang.Cameron Esfahani2013-09-141-2/+1
| | | | llvm-svn: 190737
* [analyzer] Warn when using 'delete' on an uninitialized variable.Jordan Rose2013-08-091-1/+29
| | | | | | Patch by Karthik Bhat, modified slightly by me. llvm-svn: 188043
* Fix a crash in the static analyzer (bug #16307)Pavel Labath2013-06-191-1/+24
| | | | | | | | | | | | | | | 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] Warn when nil receiver results in forming null referenceAnna Zaks2013-04-031-12/+19
| | | | | | This also allows us to ensure IDC/return null suppression gets triggered in such cases. llvm-svn: 178686
* [analyzer] Ensure that the node NilReceiverBRVisitor is looking for is not ↵Anna Zaks2013-03-271-3/+4
| | | | | | | | | reclaimed The visitor should look for the PreStmt node as the receiver is nil in the PreStmt and this is the node. Also, tag the nil receiver nodes with a special tag for consistency. llvm-svn: 178152
* Include llvm::Optional in clang/Basic/LLVM.hDavid Blaikie2013-02-201-1/+1
| | | | | | Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
* Replace SVal llvm::cast support to be well-defined.David Blaikie2013-02-201-6/+8
| | | | | | See r175462 for another example/more details. llvm-svn: 175594
* [analyzer] Track null object lvalues back through C++ method calls.Jordan Rose2013-01-261-0/+2
| | | | | | | | | | The expression 'a->b.c()' contains a call to the 'c' method of 'a->b'. We emit an error if 'a' is NULL, but previously didn't actually track the null value back through the 'a->b' expression, which caused us to miss important false-positive-suppression cases, including <rdar://problem/12676053>. llvm-svn: 173547
* 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
* Include pruning and general cleanup.Benjamin Kramer2012-12-011-0/+1
| | | | llvm-svn: 169095
* [analyzer] Rename 'EmitReport' to 'emitReport'.Jordan Rose2012-11-021-5/+5
| | | | | | No functionality change. llvm-svn: 167275
* Make helper functions static.Benjamin Kramer2012-09-101-2/+2
| | | | llvm-svn: 163505
* [analyzer] Rename addTrackNullOrUndefValueVisitor to trackNullOrUndefValue.Jordan Rose2012-08-281-4/+4
| | | | | | | | | | | This helper function (in the clang::ento::bugreporter namespace) may add more than one visitor, but conceptually it's tracking a single use of a null or undefined value and should do so as best it can. Also, the BugReport parameter has been made a reference to underscore that it is non-optional. llvm-svn: 162720
* [analyzer] If we call a C++ method on an object, assume it's non-null.Jordan Rose2012-08-151-3/+9
| | | | | | | | | | | | | | | | | | | | This is analogous to our handling of pointer dereferences: if we dereference a pointer that may or may not be null, we assume it's non-null from then on. While some implementations of C++ (including ours) allow you to call a non-virtual method through a null pointer of object type, it is technically disallowed by the C++ standard, and should not prune out any real paths in practice. [class.mfct.non-static]p1: A non-static member function may be called for an object of its class type, or for an object of a class derived from its class type... (a null pointer value does not refer to an object) We can also make the same assumption about function pointers. llvm-svn: 161992
* [analyzer] Use a more robust check for null in CallAndMessageChecker.Jordan Rose2012-08-041-2/+12
| | | | | | This should fix the failing test on the buildbot as well. llvm-svn: 161290
* [analyzer] When a symbol is null, we should track its constraints.Jordan Rose2012-08-031-9/+4
| | | | | | | | Because of this, we would previously emit NO path notes when a parameter is constrained to null (because there are no stores). Now we show where we made the assumption, which is much more useful. llvm-svn: 161280
* [analyzer] Track null/uninitialized C++ objects used in method calls.Jordan Rose2012-08-031-12/+12
| | | | llvm-svn: 161278
* [analyzer] Rename Calls.{h,cpp} to CallEvent.{h,cpp}. No functionality change.Jordan Rose2012-07-261-1/+1
| | | | llvm-svn: 160815
* Add static analyzer check for calling a C++ instance method with a ↵Ted Kremenek2012-07-261-2/+25
| | | | | | null/uninitialized pointer. llvm-svn: 160767
* [analyzer] Combine all ObjC message CallEvents into ObjCMethodCall.Jordan Rose2012-07-181-39/+67
| | | | | | | | | | | | As pointed out by Anna, we only differentiate between explicit message sends This also adds support for ObjCSubscriptExprs, which are basically the same as properties in many ways. We were already checking these, but not emitting nice messages for them. This depends on the llvm::PointerIntPair change in r160456. llvm-svn: 160461
OpenPOWER on IntegriCloud