summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [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