summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer
Commit message (Collapse)AuthorAgeFilesLines
* Move the SMT API to LLVMMikhail R. Gadelha2019-02-074-852/+21
| | | | | | | | Moved everything SMT-related to LLVM and updated the cmake scripts. Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 353373
* Got rid of the `Z3ConstraintManager` classMikhail R. Gadelha2019-02-071-16/+1
| | | | | | | | | | Now, instead of passing the reference to a shared_ptr, we pass the shared_ptr instead. I've also removed the check if Z3 is present in CreateZ3ConstraintManager as this function already calls CreateZ3Solver that performs the exactly same check. Differential Revision: https://reviews.llvm.org/D54976 llvm-svn: 353371
* Generalised the SMT state constraintsMikhail R. Gadelha2019-02-071-26/+36
| | | | | | | | | | | | | | This patch moves the ConstraintSMT definition to the SMTConstraintManager header to make it easier to move the Z3 backend around. We achieve this by not using shared_ptr anymore, as llvm::ImmutableSet doesn't seem to like it. The solver specific exprs and sorts are cached in the Z3Solver object now and we move pointers to those objects around. As a nice side-effect, SMTConstraintManager doesn't have to be a template anymore. Yay! Differential Revision: https://reviews.llvm.org/D54975 llvm-svn: 353370
* [analyzer] Canonicalize declarations within variable regions.Artem Dergachev2019-02-071-0/+2
| | | | | | | | | | | | | | | Memory region that correspond to a variable is identified by the variable's declaration and, in case of local variables, the stack frame it belongs to. The declaration needs to be canonical, otherwise we'd have two different memory regions that correspond to the same variable. Fix such bug for global variables with forward declarations and assert that no other problems of this kind happen. Differential Revision: https://reviews.llvm.org/D57619 llvm-svn: 353353
* Revert "[analyzer] Remove the "postponed" hack, deal with derived symbols..."Artem Dergachev2019-02-061-40/+20
| | | | | | | | | | | | | | This reverts commit r341722. The "postponed" mechanism turns out to be necessary in order to handle situations when a symbolic region is only kept alive by implicit bindings in the Store. Otherwise the region is never scanned by the Store's worklist and the binding gets dropped despite being live, as demonstrated by the newly added tests. Differential Revision: https://reviews.llvm.org/D57554 llvm-svn: 353350
* [analyzer][UninitializedObjectChecker] New flag to ignore guarded ↵Kristof Umann2019-02-022-13/+110
| | | | | | | | | | | | | | | | | | | uninitialized fields This patch is an implementation of the ideas discussed on the mailing list[1]. The idea is to somewhat heuristically guess whether the field that was confirmed to be uninitialized is actually guarded with ifs, asserts, switch/cases and so on. Since this is a syntactic check, it is very much prone to drastically reduce the amount of reports the checker emits. The reports however that do not get filtered out though have greater likelihood of them manifesting into actual runtime errors. [1] http://lists.llvm.org/pipermail/cfe-dev/2018-September/059255.html Differential Revision: https://reviews.llvm.org/D51866 llvm-svn: 352959
* [analyzer] Hotfix for RetainCountChecker: assert was too strong.George Karpenkov2019-02-011-4/+3
| | | | | | Bridged casts can happen to non-CF objects as well. llvm-svn: 352938
* [analyzer] [RetainCountChecker] Fix object type for CF/Obj-C bridged castsGeorge Karpenkov2019-02-011-1/+10
| | | | | | | | | | | | Having an incorrect type for a cast causes the checker to incorrectly dismiss the operation under ARC, leading to a false positive use-after-release on the test. rdar://47709885 Differential Revision: https://reviews.llvm.org/D57557 llvm-svn: 352824
* Add a new builtin: __builtin_dynamic_object_sizeErik Pilkington2019-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This builtin has the same UI as __builtin_object_size, but has the potential to be evaluated dynamically. It is meant to be used as a drop-in replacement for libraries that use __builtin_object_size when a dynamic checking mode is enabled. For instance, __builtin_object_size fails to provide any extra checking in the following function: void f(size_t alloc) { char* p = malloc(alloc); strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0)) } This is an overflow if alloc < 7, but because LLVM can't fold the object size intrinsic statically, it folds __builtin_object_size to -1. With __builtin_dynamic_object_size, alloc is passed through to __builtin___strcpy_chk. rdar://32212419 Differential revision: https://reviews.llvm.org/D56760 llvm-svn: 352665
* [analyzer] [RetainCountChecker] Bugfix for tracking top-level parameters of ↵George Karpenkov2019-01-302-7/+7
| | | | | | | | Objective-C methods Differential Revision: https://reviews.llvm.org/D57433 llvm-svn: 352588
* [analyzer] NFC: GenericTaintChecker: Revise rule specification mechanisms.Artem Dergachev2019-01-301-112/+103
| | | | | | | | | | | | | | | | Provide a more powerful and at the same time more readable way of specifying taint propagation rules for known functions within the checker. Now it should be possible to specify an unlimited amount of source and destination parameters for taint propagation. No functional change intended just yet. Patch by Gábor Borsik! Differential Revision: https://reviews.llvm.org/D55734 llvm-svn: 352572
* [analyzer] [RetainCountChecker] Track input parameters to the top-level functionGeorge Karpenkov2019-01-293-28/+80
| | | | | | | | | | Track them for ISL/OS objects by default, and for NS/CF under a flag. rdar://47536377 Differential Revision: https://reviews.llvm.org/D57356 llvm-svn: 352534
* [analyzer] [ARCMT] [NFC] Unify entry point into RetainSummaryManagerGeorge Karpenkov2019-01-291-3/+3
| | | | | | | | Just use one single entry point, since we have AnyCall utility now. Differential Revision: https://reviews.llvm.org/D57346 llvm-svn: 352532
* Extend AnyCall to handle callable declarations without the call expressionsGeorge Karpenkov2019-01-291-1/+1
| | | | | | | | | | That weakens inner invariants, but allows the class to be more generic, allowing usage in situations where the call expression is not known (or should not matter). Differential Revision: https://reviews.llvm.org/D57344 llvm-svn: 352531
* [analyzer] Toning down invalidation a bitGabor Horvath2019-01-291-5/+17
| | | | | | | | | When a function takes the address of a field the analyzer will no longer assume that the function will change other fields of the enclosing structs. Differential Revision: https://reviews.llvm.org/D57230 llvm-svn: 352473
* [analyzer] Fix a typo in docsGabor Horvath2019-01-291-1/+1
| | | | llvm-svn: 352468
* [analyzer] Add CheckerManager::getChecker, make sure that a registry ↵Kristof Umann2019-01-2613-33/+26
| | | | | | | | | | | | | 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-2613-59/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Fix an bug where statically linked, but not registered checkers ↵Kristof Umann2019-01-262-8/+14
| | | | | | | | | | | | | | weren't recognized My last patch, D56989, moved the validation of whether a checker exists into its constructor, but we do support statically linked (and non-plugin) checkers that were do not have an entry in Checkers.td. However, the handling of this happens after the creation of the CheckerRegistry object. This patch fixes this bug by moving even this functionality into CheckerRegistry's constructor. llvm-svn: 352284
* [analyzer][NFC] Keep track of whether enabling a checker was explictly ↵Kristof Umann2019-01-261-67/+77
| | | | | | | | | | | | | | | specified in command line arguments I added a new enum to CheckerInfo, so we can easily track whether the check is explicitly enabled, explicitly disabled, or isn't specified in this regard. Checkers belonging in the latter category may be implicitly enabled through dependencies in the followup patch. I also made sure that this is done within CheckerRegisty's constructor, leading to very significant simplifications in its query-like methods. Differential Revision: https://reviews.llvm.org/D56989 llvm-svn: 352282
* [analyzer][NFC] Supply CheckerRegistry with AnalyzerOptionsKristof Umann2019-01-262-19/+17
| | | | | | | | | Since pretty much all methods of CheckerRegistry has AnalyzerOptions as an argument, it makes sense to just simply require it in it's constructor. Differential Revision: https://reviews.llvm.org/D56988 llvm-svn: 352279
* [analyzer] Split unix.API up to UnixAPIMisuseChecker and ↵Kristof Umann2019-01-261-101/+128
| | | | | | | | | | | | | | | | UnixAPIPortabilityChecker The actual implementation of unix.API features a dual-checker: two checkers in one, even though they don't even interact at all. Split them up, as this is a problem for establishing dependencies. I added no new code at all, just merely moved it around. Since the plist files change (and that's a benefit!) this patch isn't NFC. Differential Revision: https://reviews.llvm.org/D55425 llvm-svn: 352278
* [analyzer] Supply all checkers with a shouldRegister functionKristof Umann2019-01-2695-40/+496
| | | | | | | | | | | | | | | | | | 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
* [analyzer] Port RetainSummaryManager to the new AnyCall interface, decouple ↵George Karpenkov2019-01-255-1264/+33
| | | | | | | | | | ARCMT from the analyzer rdar://19694750 Differential Revision: https://reviews.llvm.org/D57127 llvm-svn: 352149
* [analyzer] Insert notes in RetainCountChecker where our dynamic cast ↵George Karpenkov2019-01-224-7/+27
| | | | | | | | | | modeling assumes 'null' output rdar://47397214 Differential Revision: https://reviews.llvm.org/D56952 llvm-svn: 351865
* [analyzer] Model another special-case kind of cast for OSObject ↵George Karpenkov2019-01-222-8/+25
| | | | | | | | RetainCountChecker Differential Revision: https://reviews.llvm.org/D56951 llvm-svn: 351864
* [Analyzer] Remove extra blank line from Iterator Checker (test commit)Adam Balogh2019-01-211-1/+0
| | | | llvm-svn: 351746
* Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>Serge Guelton2019-01-201-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for isPodLike<std::pair<...>> did not match the expectation of std::is_trivially_copyable which makes the memcpy optimization invalid. This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable. Unfortunately std::is_trivially_copyable is not portable across compiler / STL versions. So a portable version is provided too. Note that the following specialization were invalid: std::pair<T0, T1> llvm::Optional<T> Tests have been added to assert that former specialization are respected by the standard usage of llvm::is_trivially_copyable, and that when a decent version of std::is_trivially_copyable is available, llvm::is_trivially_copyable is compared to std::is_trivially_copyable. As of this patch, llvm::Optional is no longer considered trivially copyable, even if T is. This is to be fixed in a later patch, as it has impact on a long-running bug (see r347004) Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296. Differential Revision: https://reviews.llvm.org/D54472 llvm-svn: 351701
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-19161-644/+483
| | | | | | | | | | | | | | | | | 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] pr37688: Fix a crash upon evaluating a deleted destructor of a union.Artem Dergachev2019-01-181-1/+14
| | | | | | | | | | | | | | | Add a defensive check against an invalid destructor in the CFG. Unions with fields with destructors have their own destructor implicitly deleted. Due to a bug in the CFG we're still trying to evaluate them at the end of the object's lifetime and crash because we are unable to find the destructor's declaration. rdar://problem/47362608 Differential Revision: https://reviews.llvm.org/D56899 llvm-svn: 351610
* Fix MSVC "not all control paths return a value" warning. NFCI.Simon Pilgrim2019-01-181-0/+2
| | | | llvm-svn: 351588
* Revert "Fix failing MSan bots"George Karpenkov2019-01-1812-204/+231
| | | | | | | | This reverts commit 2cedaaef383d8d6142046074ffebc2bb5a914778. Revert with a fix. llvm-svn: 351575
* Fix failing MSan botsVlad Tsyrklevich2019-01-1812-231/+204
| | | | | | | Revert r351508-351514, this block of changes introduced a consistent MSan failure on the sanitizer bots. llvm-svn: 351528
* [analyzer] Introduce proper diagnostic for freeing unowned objectGeorge Karpenkov2019-01-184-9/+32
| | | | | | | | Insert a note when the object becomes not (exclusively) owned. Differential Revision: https://reviews.llvm.org/D56891 llvm-svn: 351514
* [analyzer] Extend the PathDiagnosticLocation constructor to handle CallExitEndGeorge Karpenkov2019-01-183-30/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D56890 llvm-svn: 351513
* [analyzer] [NFC] Clean up messy handling of bug categories in RetainCountCheckerGeorge Karpenkov2019-01-184-150/+112
| | | | | | https://reviews.llvm.org/D56887 llvm-svn: 351512
* [analyzer] const-ify reference to bug type used in BugReporterGeorge Karpenkov2019-01-182-5/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D56885 llvm-svn: 351511
* [analyzer] Extend BugType constructor to accept "SuppressOnSink" as a parameterGeorge Karpenkov2019-01-186-20/+22
| | | | | | Differential Revision: https://reviews.llvm.org/D56884 llvm-svn: 351510
* [analyzer] [RetainCountChecker] Produce a correct message when OSTypeAlloc ↵George Karpenkov2019-01-181-1/+27
| | | | | | | | is used Differential Revision: https://reviews.llvm.org/D56820 llvm-svn: 351509
* [analyzer] [RetainCountChecker] Smart pointer support.George Karpenkov2019-01-182-2/+28
| | | | | | | | rdar://47323216 Differential Revision: https://reviews.llvm.org/D56817 llvm-svn: 351508
* [analyzer] MoveChecker: Add one more common resetting method, "append".Artem Dergachev2019-01-181-3/+3
| | | | | | | | | | | This is especially crucial for reports related to use-after-move of standard library objects. rdar://problem/47338505 Differential Revision: https://reviews.llvm.org/D56824 llvm-svn: 351500
* [analyzer] Make sure base-region and its sub-regions are either all alive or ↵Artem Dergachev2019-01-182-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | all dead. SymbolReaper now realizes that our liveness analysis isn't sharp enough to discriminate between liveness of, say, variables and their fields. Surprisingly, this didn't quite work before: having a variable live only through Environment (eg., calling a C++ method on a local variable as the last action ever performed on that variable) would not keep the region value symbol of a field of that variable alive. It would have been broken in the opposite direction as well, but both Environment and RegionStore use the scanReachableSymbols mechanism for finding live symbols regions within their values, and due to that they accidentally end up marking the whole chain of super-regions as live when at least one sub-region is known to be live. It is now a direct responsibility of SymbolReaper to maintain this invariant, and a unit test was added in order to make sure it stays that way. Differential Revision: https://reviews.llvm.org/D56632 rdar://problem/46914108 llvm-svn: 351499
* [analyzer] Another RetainCountChecker cleanupGeorge Karpenkov2019-01-161-45/+33
| | | | | | | | | This is not NFC strictly speaking, since it unifies CleanupAttr handling, so that out parameters now also understand it. Differential Revision: https://reviews.llvm.org/D56759 llvm-svn: 351394
* [analyzer] [NFC] Yet another minor cleanup of RetainCountCheckerGeorge Karpenkov2019-01-162-33/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D56744 llvm-svn: 351393
* [analyzer] [PR39792] false positive on strcpy targeting struct membersGeorge Karpenkov2019-01-141-7/+7
| | | | | | | | Patch by Pierre van Houtryve. Differential Revision: https://reviews.llvm.org/D55226 llvm-svn: 351097
* [analyzer] [NFC] Remove unused undefined method.George Karpenkov2019-01-141-2/+0
| | | | | | Wow, at no point the linker or compiler complaints about that! llvm-svn: 351096
* [analyzer] Fix unused variable warnings in Release buildsBenjamin Kramer2019-01-121-5/+2
| | | | | | This was just an inlined version of isa<CXXConstructExpr>. NFC. llvm-svn: 351007
* [analyzer] Support for OSObjects out parameters in RetainCountCheckerGeorge Karpenkov2019-01-113-72/+217
| | | | | | | | | rdar://46357478 rdar://47121327 Differential Revision: https://reviews.llvm.org/D56240 llvm-svn: 350982
* [analyzer] Introduce a convenience method for getting a CallEvent from an ↵George Karpenkov2019-01-111-22/+30
| | | | | | | | arbitrary Stmt Differential Revision: https://reviews.llvm.org/D56300 llvm-svn: 350981
* [AST] Remove ASTContext from getThisType (NFC)Brian Gesiak2019-01-113-8/+6
| | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D54862 removed the usages of `ASTContext&` from within the `CXXMethodDecl::getThisType` method. Remove the parameter altogether, as well as all usages of it. This does not result in any functional change because the parameter was unused since https://reviews.llvm.org/D54862. Test Plan: check-clang Reviewers: akyrtzi, mikael Reviewed By: mikael Subscribers: mehdi_amini, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D56509 llvm-svn: 350914
OpenPOWER on IntegriCloud