summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer][NFC] Fix inconsistent references to checkers as "checks"Kristof Umann2019-09-121-1/+1
| | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | 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] NFC: Change evalCall() to provide a CallEvent.Artem Dergachev2019-06-191-2/+7
| | | | | | | | | | | | This changes the checker callback signature to use the modern, easy to use interface. Additionally, this unblocks future work on allowing checkers to implement evalCall() for calls that don't correspond to any call-expression or require additional information that's only available as part of the CallEvent, such as C++ constructors and destructors. Differential Revision: https://reviews.llvm.org/D62440 llvm-svn: 363893
* [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] pr38668: Do not attempt to cast loaded integers to floats.Artem Dergachev2018-12-221-9/+20
| | | | | | | | | | | | | | | | | | | | | | This patch is a different approach to landing the reverted r349701. It is expected to have the same object (memory region) treated as if it has different types in different program points. The correct behavior for RegionStore when an object is stored as an object of type T1 but loaded as an object of type T2 is to store the object as if it has type T1 but cast it to T2 during load. Note that the cast here is some sort of a "reinterpret_cast" (even in C). For instance, if you store an integer and load a float, you won't get your integer represented as a float; instead, you will get garbage. Admit that we cannot perform the cast and return an unknown value. Differential Revision: https://reviews.llvm.org/D55875 rdar://problem/45062567 llvm-svn: 349984
* [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
* Move some helpers from the global namespace into anonymous ones.Benjamin Kramer2018-10-131-0/+2
| | | | llvm-svn: 344468
* [analyzer] Add a testing facility for testing relationships between symbols.Artem Dergachev2018-09-251-0/+98
| | | | | | | | | | | | | | | | | | Tests introduced in r329780 was disabled in r342317 because these tests were accidentally testing dump infrastructure, when all they cared about was how symbols relate to each other. So when dump infrastructure changed, tests became annoying to maintain. Add a new feature to ExprInspection: clang_analyzer_denote() and clang_analyzer_explain(). The former adds a notation to a symbol, the latter expresses another symbol in terms of previously denoted symbols. It's currently a bit wonky - doesn't print parentheses and only supports denoting atomic symbols. But it's even more readable that way. Differential Revision: https://reviews.llvm.org/D52133 llvm-svn: 343048
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-1/+1
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* [analyzer] [NFC] A convenient getter for getting a current stack frameGeorge Karpenkov2018-06-271-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D44756 llvm-svn: 335701
* [analyzer] Make issue hash related tests more conciseGabor Horvath2017-10-301-2/+16
| | | | | | | | | | Extend ExprInspection checker to make it possible to dump the issue hash of arbitrary expressions. This change makes it possible to make issue hash related tests more concise and also makes debugging issue hash related problems easier. Differential Revision: https://reviews.llvm.org/D38844 llvm-svn: 316899
* [StaticAnalyzer] Completely unrolling specific loops with known bound optionPeter Szecsi2017-07-251-0/+1
| | | | | | | | | | | | | | | | | This feature allows the analyzer to consider loops to completely unroll. New requirements/rules (for unrolling) can be added easily via ASTMatchers. Right now it is hidden behind a flag, the aim is to find the correct heuristic and create a solution which results higher coverage % and more precise analysis, thus can be enabled by default. Right now the blocks which belong to an unrolled loop are marked by the LoopVisitor which adds them to the ProgramState. Then whenever we encounter a CFGBlock in the processCFGBlockEntrance which is marked then we skip its investigating. That means, it won't be considered to be visited more than the maximal bound for visiting since it won't be checked. llvm-svn: 309006
* Revert "[StaticAnalyzer] Completely unrolling specific loops with known ↵Peter Szecsi2017-07-201-1/+0
| | | | | | | | | | bound option" Revert r308561 and r308558. Clang-ppc64be-linux seems to crash while running the test cases. llvm-svn: 308592
* This feature allows the analyzer to consider loops to completely unroll. NewPeter Szecsi2017-07-191-0/+1
| | | | | | | | | | | | | | | | requirements/rules (for unrolling) can be added easily via ASTMatchers. The current implementation is hidden behind a flag. Right now the blocks which belong to an unrolled loop are marked by the LoopVisitor which adds them to the ProgramState. Then whenever we encounter a CFGBlock in the processCFGBlockEntrance which is marked then we skip its investigating. That means, it won't be considered to be visited more than the maximal bound for visiting since it won't be checked. Differential Revision: https://reviews.llvm.org/D34260 llvm-svn: 308558
* [analyzer] Improve usability of ExprInspectionCheckerAnna Zaks2017-03-091-2/+2
| | | | | | | | | | | | | | | | Some of the magic functions take arguments of arbitrary type. However, for semantic correctness, the compiler still requires a declaration of these functions with the correct type. Since C does not have argument-type-overloaded function, this made those functions hard to use in C code. Improve this situation by allowing arbitrary suffixes in the affected magic functions' names, thus allowing the user to create different declarations for different types. A patch by Keno Fischer! Differential Revision: https://reviews.llvm.org/D30589 llvm-svn: 297325
* [StaticAnalyzer] Fix android buildPavel Labath2017-01-161-1/+2
| | | | | | | | std::to_string is not available in the android NDK. Use llvm::to_string instead. Committing as obvious. llvm-svn: 292141
* [analyzer] Minor fixes and improvements to debug.ExprInspectionArtem Dergachev2016-11-301-14/+91
| | | | | | | | | | | | | | | | | | - Fix the bug with transition handling in ExprInspectionChecker's checkDeadSymbols implementation. - Test this bug by adding a new function clang_analyzer_numTimesReached() to catch number of passes through the code, which should be handy for testing against unintended state splits. - Add two more functions should help debugging issues quickly without running the debugger or dumping exploded graphs - clang_analyzer_dump() which dump()s an SVal argument to a warning message, and clang_analyzer_printState(), which dump()s the current program state to stderr. Differential Revision: https://reviews.llvm.org/D26835 llvm-svn: 288257
* [analyzer] Provide .def-files and visitors for SVal/SymExpr/MemRegion, v2.Artem Dergachev2016-01-151-34/+51
| | | | | | | | | | | | | | | | Provide separate visitor templates for the three hierarchies, and also the `FullSValVisitor' class, which is a union of all three visitors. Additionally, add a particular example visitor, `SValExplainer', in order to test the visitor templates. This visitor is capable of explaining the SVal, SymExpr, or MemRegion in a natural language. Compared to the reverted r257605, this fixes the test that used to fail on some triples, and fixes build failure under -fmodules. Differential Revision: http://reviews.llvm.org/D15448 llvm-svn: 257893
* Revert "[analyzer] Provide .def-files and visitors for SVal/SymExpr/MemRegion."Artem Dergachev2016-01-131-51/+34
| | | | | | | | | This reverts commit r257605. The test fails on architectures that use unsigned int as size_t. SymbolManager.h fails with compile errors on some platforms. llvm-svn: 257608
* [analyzer] Provide .def-files and visitors for SVal/SymExpr/MemRegion.Artem Dergachev2016-01-131-34/+51
| | | | | | | | | | | | | Provide separate visitor templates for the three hierarchies, and also the `FullSValVisitor' class, which is a union of all three visitors. Additionally, add a particular example visitor, `SValExplainer', in order to test the visitor templates. This visitor is capable of explaining the SVal, SymExpr, or MemRegion in a natural language. Differential Revision: http://reviews.llvm.org/D15448 llvm-svn: 257605
* [analyzer] Fix symbolic element index lifetime.Artem Dergachev2015-12-101-2/+44
| | | | | | | | | | | | SymbolReaper was destroying the symbol too early when it was referenced only from an index SVal of a live ElementRegion. In order to test certain aspects of this patch, extend the debug.ExprInspection checker to allow testing SymbolReaper in a direct manner. Differential Revision: http://reviews.llvm.org/D12726 llvm-svn: 255236
* [analyzer] Add generateErrorNode() APIs to CheckerContext.Devin Coughlin2015-09-161-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Clarify pointer ownership semantics by hoisting the std::unique_ptr creation ↵Aaron Ballman2015-06-231-6/+5
| | | | | | to the caller instead of hiding it in emitReport. NFC. llvm-svn: 240400
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-1/+1
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-1/+1
| | | | | | | | | | | | 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
* [C++11] Use 'nullptr'. StaticAnalyzer edition.Craig Topper2014-05-271-3/+3
| | | | llvm-svn: 209642
* Replace OwningPtr with std::unique_ptr.Ahmed Charles2014-03-071-1/+1
| | | | | | 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-1/+1
| | | | llvm-svn: 202639
* Expose the name of the checker producing each diagnostic message.Alexander Kornienko2014-02-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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] Add new debug helper clang_analyzer_warnIfReached.Jordan Rose2013-10-031-0/+13
| | | | | | | | | | | | | This will emit a warning if a call to clang_analyzer_warnIfReached is executed, printing REACHABLE. This is a more explicit way to declare expected reachability than using clang_analyzer_eval or triggering a bug (divide-by-zero or null dereference), and unlike the former will work the same in inlined functions and top-level functions. Like the other debug helpers, it is part of the debug.ExprInspection checker. Patch by Jared Grubb! llvm-svn: 191909
* [analyzer] Include analysis stack in crash traces.Jordan Rose2013-07-191-0/+7
| | | | | | | | | | | | | Sample output: 0. Program arguments: ... 1. <eof> parser at end of file 2. While analyzing stack: #0 void inlined() #1 void test() 3. crash-trace.c:6:3: Error evaluating statement llvm-svn: 186639
* Replace SVal llvm::cast support to be well-defined.David Blaikie2013-02-201-1/+1
| | | | | | See r175462 for another example/more details. llvm-svn: 175594
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-1/+1
| | | | | | | | | | | | | 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
* Don't include Type.h in DeclarationName.h.Benjamin Kramer2012-12-011-0/+1
| | | | | | Recursively prune some includes. llvm-svn: 169094
* [analyzer] Rename 'EmitReport' to 'emitReport'.Jordan Rose2012-11-021-2/+2
| | | | | | No functionality change. llvm-svn: 167275
* [analyzer] Add clang_analyzer_checkInlined for debugging purposes.Jordan Rose2012-08-101-38/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | This check is also accessible through the debug.ExprInspection checker. Like clang_analyzer_eval, you can use it to test the analyzer engine's current state; the argument should be true or false to indicate whether or not you expect the function to be inlined. When used in the positive case (clang_analyzer_checkInlined(true)), the analyzer prints the message "TRUE" if the function is ever inlined. However, clang_analyzer_checkInlined(false) should never print a message; this asserts that there should be no paths on which the current function is inlined, but then there are no paths on which to print a message! (If the assertion is violated, the message "FALSE" will be printed.) This asymmetry comes from the fact that the only other chance to print a message is when the function is analyzed as a top-level function. However, when we do that, we can't be sure it isn't also inlined elsewhere (such as in a recursive function, or if we want to analyze in both general or specialized cases). Rather than have all checkInlined calls have an appended, meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed. void clang_analyzer_checkInlined(int); For debugging purposes only! llvm-svn: 161708
* [analyzer] Introduce clang_analyzer_eval for regression test constraint checks.Jordy Rose2012-05-161-0/+85
The new debug.ExprInspection checker looks for calls to clang_analyzer_eval, and emits a warning of TRUE, FALSE, or UNKNOWN (or UNDEFINED) based on the constrained value of its (boolean) argument. It does not modify the analysis state though the conditions tested can result in branches (e.g. through the use of short-circuit operators). llvm-svn: 156919
OpenPOWER on IntegriCloud