summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Checkers/TrustNonnullChecker.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-2/+2
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [analyzer] Supply all checkers with a shouldRegister functionKristof Umann2019-01-261-1/+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] Do not crash if the assumption added in TrustNonNullChecker is ↵George Karpenkov2018-10-031-8/+14
| | | | | | | | | | enough to make the state unfeasible rdar://43541814 Differential Revision: https://reviews.llvm.org/D52848 llvm-svn: 343735
* [analyzer] [NFC] Split up RetainSummaryManager from RetainCountChecker - try #2George Karpenkov2018-08-211-1/+1
| | | | | | | | | | Turns out it can't be removed from the analyzer since it relies on CallEvent. Moving to staticAnalyzer/core Differential Revision: https://reviews.llvm.org/D51023 llvm-svn: 340247
* Revert "[analyzer] [NFC] Split up RetainSummaryManager from RetainCountChecker"Bruno Cardoso Lopes2018-08-181-1/+1
| | | | | | | | | | | | | | This reverts commit a786521fa66c72edd308baff0c08961b6d964fb1. Bots haven't caught up yet, but broke modules build with: ../tools/clang/include/clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h:18:10: fatal error: cyclic dependency in module 'Clang_StaticAnalyzer_Core': Clang_StaticAnalyzer_Core -> Clang_Analysis -> Clang_StaticAnalyzer_Checkers -> Clang_StaticAnalyzer_Core ^ llvm-svn: 340117
* [analyzer] [NFC] Split up RetainSummaryManager from RetainCountCheckerGeorge Karpenkov2018-08-181-1/+1
| | | | | | | | | | | | | ARCMigrator is using code from RetainCountChecker, which is a layering violation (and it also does it badly, by using a different header, and then relying on implementation being present in a header file). This change splits up RetainSummaryManager into a separate library in lib/Analysis, which can be used independently of a checker. Differential Revision: https://reviews.llvm.org/D50934 llvm-svn: 340114
* [analyzer] Record nullability implications on getting items from NSDictionaryGeorge Karpenkov2018-08-101-14/+173
| | | | | | | | | | | | | | | | | | | | If we get an item from a dictionary, we know that the item is non-null if and only if the key is non-null. This patch is a rather hacky way to record this implication, because some logic needs to be duplicated from the solver. And yet, it's pretty simple, performant, and works. Other possible approaches: - Record the implication, in future rely on Z3 to pick it up. - Generalize the current code and move it to the constraint manager. rdar://34990742 Differential Revision: https://reviews.llvm.org/D50124 llvm-svn: 339482
* [analyzer] Trust _Nonnull annotations, and trust analyzer knowledge about ↵George Karpenkov2018-05-311-5/+43
| | | | | | | | | | | | | | | receiver nullability Previously, the checker was using the nullability of the expression, which is nonnull IFF both receiver and method are annotated as _Nonnull. However, the receiver could be known to the analyzer to be nonnull without being explicitly marked as _Nonnull. rdar://40635584 Differential Revision: https://reviews.llvm.org/D47510 llvm-svn: 333612
* [analyzer] Trust _Nonnull annotations for system frameworkGeorge Karpenkov2018-03-231-0/+52
Changes the analyzer to believe that methods annotated with _Nonnull from system frameworks indeed return non null objects. Local methods with such annotation are still distrusted. rdar://24291919 Differential Revision: https://reviews.llvm.org/D44341 llvm-svn: 328282
OpenPOWER on IntegriCloud