summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Fix infinite recursion in printing macrosKristof Umann2019-02-251-1/+11
| | | | | | | | | | | | | | | | #define f(y) x #define x f(x) int main() { x; } This example results a compilation error since "x" in the first line was not defined earlier. However, the macro expression printer goes to an infinite recursion on this example. Patch by Tibor Brunner! Differential Revision: https://reviews.llvm.org/D57892 llvm-svn: 354806
* [Analyzer] Crash fix for FindLastStoreBRVisitorAdam Balogh2019-02-131-1/+28
| | | | | | | | | | | | | | | | | | | | | | | FindLastStoreBRVisitor tries to find the first node in the exploded graph where the current value was assigned to a region. This node is called the "store site". It is identified by a pair of Pred and Succ nodes where Succ already has the binding for the value while Pred does not have it. However the visitor mistakenly identifies a node pair as the store site where the value is a `LazyCompoundVal` and `Pred` does not have a store yet but `Succ` has it. In this case the `LazyCompoundVal` is different in the `Pred` node because it also contains the store which is different in the two nodes. This error may lead to crashes (a declaration is cast to a parameter declaration without check) or misleading bug path notes. In this patch we fix this problem by checking for unequal `LazyCompoundVals`: if their region is equal, and their store is the same as the store of their nodes we consider them as equal when looking for the "store site". This is an approximation because we do not check for differences of the subvalues (structure members or array elements) in the stores. Differential Revision: https://reviews.llvm.org/D58067 llvm-svn: 353943
* Use llvm::is_contained. NFCFangrui Song2019-02-101-1/+1
| | | | llvm-svn: 353635
* [analyzer] Add a comment that FunctionCodeRegions may also need canonicalizationArtem Dergachev2019-02-091-0/+1
| | | | llvm-svn: 353592
* This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.Mikhail R. Gadelha2019-02-094-21/+852
| | | | | | | | and commit a1853e834c65751f92521f7481b15cf0365e796b. They broke arm and aarch64 llvm-svn: 353590
* 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] 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] Port RetainSummaryManager to the new AnyCall interface, decouple ↵George Karpenkov2019-01-252-1252/+0
| | | | | | | | | | ARCMT from the analyzer rdar://19694750 Differential Revision: https://reviews.llvm.org/D57127 llvm-svn: 352149
* [analyzer] Model another special-case kind of cast for OSObject ↵George Karpenkov2019-01-221-5/+14
| | | | | | | | RetainCountChecker Differential Revision: https://reviews.llvm.org/D56951 llvm-svn: 351864
* 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-1948-192/+144
| | | | | | | | | | | | | | | | | 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
* Revert "Fix failing MSan bots"George Karpenkov2019-01-184-26/+36
| | | | | | | | This reverts commit 2cedaaef383d8d6142046074ffebc2bb5a914778. Revert with a fix. llvm-svn: 351575
* Fix failing MSan botsVlad Tsyrklevich2019-01-184-36/+26
| | | | | | | Revert r351508-351514, this block of changes introduced a consistent MSan failure on the sanitizer bots. llvm-svn: 351528
* [analyzer] Extend the PathDiagnosticLocation constructor to handle CallExitEndGeorge Karpenkov2019-01-182-21/+17
| | | | | | Differential Revision: https://reviews.llvm.org/D56890 llvm-svn: 351513
* [analyzer] const-ify reference to bug type used in BugReporterGeorge Karpenkov2019-01-181-4/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D56885 llvm-svn: 351511
* [analyzer] [RetainCountChecker] Smart pointer support.George Karpenkov2019-01-181-1/+15
| | | | | | | | rdar://47323216 Differential Revision: https://reviews.llvm.org/D56817 llvm-svn: 351508
* [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] 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-111-13/+73
| | | | | | | | | 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
* Fix header issues.Richard Trieu2019-01-111-0/+4
| | | | | | | | | | | | | Several headers would fail to compile if other headers were not previously included. The usual issue is that a class is forward declared, but the full definition is needed. The requirement for the definition is use of isa/dyn_cast or calling functions of pointer-packed data types such as DenseMap or PointerIntPair. Add missing includes to these headers. SVals.h required an out-of-line method definition in the .cpp file to avoid circular inclusion of headers with BasicValueFactory.h llvm-svn: 350913
* [analyzer] pr38838, pr39976: Fix crash on diagnosing before implicit destructor.Artem Dergachev2019-01-101-0/+2
| | | | | | | | | | | | | | | | | | | We need to be able to emit the diagnostic at PreImplicitCall, and the patch implements this functionality. However, for now the need for emitting such diagnostics is not all that great: it is only necessary to not crash when emitting a false positive due to an unrelated issue of having dead symbol collection not working properly. Coming up with a non-false-positive test seems impossible with the current set of checkers, though it is likely to be needed for good things as well in the future. Differential Revision: https://reviews.llvm.org/D56042 rdar://problem/46911462 llvm-svn: 350907
* [analyzer] Update the category name for RetainCountChecker reportsGeorge Karpenkov2019-01-101-2/+2
| | | | | | | | | | ..now that it includes OSObjects rdar://46509986 Differential Revision: https://reviews.llvm.org/D56404 llvm-svn: 350869
* [analyzer] [NFC] Reduce redundancy in RetainSummaryManager by using a functionGeorge Karpenkov2019-01-101-20/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D56282 llvm-svn: 350865
* [analyzer] [RetainCountChecker] [NFC] Another minor cleanupGeorge Karpenkov2019-01-101-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D56224 llvm-svn: 350863
* [analyzer] [RetainCountChecker] [NFC] Refactor the way attributes are handledGeorge Karpenkov2019-01-101-83/+103
| | | | | | | | | | | | | Make sure all checks for attributes go through a centralized function, which checks whether attribute handling is enabled, and performs validation. The type of the attribute is returned. Sadly, metaprogramming is required as attributes have no sensible static getters. Differential Revision: https://reviews.llvm.org/D56222 llvm-svn: 350862
* [analyzer] [RetainCountChecker] Remove redundant enum UnarySummaryKindGeorge Karpenkov2019-01-101-16/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D56072 llvm-svn: 350861
* [analyzer] [RetainCountChecker] Remove obsolete "MakeCollectable" enum valueGeorge Karpenkov2019-01-101-2/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D56071 llvm-svn: 350860
* [analyzer] [RetainCountChecker] [NFC] Remove redundant enum items *Msg, as ↵George Karpenkov2019-01-101-19/+19
| | | | | | | | the object type is already communicated by a separate field Differential Revision: https://reviews.llvm.org/D56070 llvm-svn: 350859
* [analyzer] [NFC] Track object type with ArgEffect in RetainCountChecker.George Karpenkov2019-01-101-90/+104
| | | | | | | | This would be needed in the future. https://reviews.llvm.org/D56040 llvm-svn: 350858
* [analyzer] [NFC] Move ObjKind into a separate top-level enum in ↵George Karpenkov2019-01-101-21/+21
| | | | | | | | | | RetainSummaryManager. Allows using it in future outside of RetEffect. Differential Revision: https://reviews.llvm.org/D56039 llvm-svn: 350857
* Correct the spelling of helpURI to helpUri.Aaron Ballman2019-01-101-1/+1
| | | | | | JSON is case sensitive and the SARIF spec uses the corrected spelling. llvm-svn: 350817
* [analyzer] Pass the correct loc Expr from VisitIncDecOp to evalStoreRafael Stahl2019-01-071-2/+2
| | | | | | | | | | | | | | Summary: The LocationE parameter of evalStore is documented as "The location expression that is stored to". When storing from an increment / decrement operator this was not satisfied. In user code this causes an inconsistency between the SVal and Stmt parameters of checkLocation. Reviewers: NoQ, dcoughlin, george.karpenkov Reviewed By: NoQ Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D55701 llvm-svn: 350528
* [analyzer] [NFC] Clean up the mess of constructing argument effects in ↵George Karpenkov2018-12-241-60/+83
| | | | | | | | | | | | | | RetainCountChecker Previously, argument effects were stored in a method variable, which was effectively global. The global state was reset at each (hopefully) entrance point to the summary construction, and every function could modify it. Differential Revision: https://reviews.llvm.org/D56036 llvm-svn: 350057
* [analyzer] pr38668: Do not attempt to cast loaded integers to floats.Artem Dergachev2018-12-221-0/+11
| | | | | | | | | | | | | | | | | | | | | | 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] RetainCount: Suppress retain detection heuristic on some CM methods.Artem Dergachev2018-12-211-0/+11
| | | | | | | | | | | | If it ends with "Retain" like CFRetain and returns a CFTypeRef like CFRetain, then it is not necessarily a CFRetain. But it is indeed true that these two return something retained. Differential Revision: https://reviews.llvm.org/D55907 rdar://problem/39390714 llvm-svn: 349862
* Allow direct navigation to static analysis checker documentation through ↵Aaron Ballman2018-12-202-3/+20
| | | | | | | | SARIF exports. This adds anchors to all of the documented checks so that you can directly link to a check by a stable name. This is useful because the SARIF file format has a field for specifying a URI to documentation for a rule and some viewers, like CodeSonar, make use of this information. These links are then exposed through the SARIF exporter. llvm-svn: 349812
* Revert "[analyzer] pr38668: Do not attempt to cast loaded values..."Artem Dergachev2018-12-201-20/+6
| | | | | | | | | | | | | | | This reverts commit r349701. The patch was incorrect. The whole point of CastRetrievedVal() is to handle the case in which the type from which the cast is made (i.e., the "type" of value `V`) has nothing to do with the type of the region it was loaded from (i.e., `R->getValueType()`). Differential Revision: https://reviews.llvm.org/D55875 rdar://problem/45062567 llvm-svn: 349798
* [analyzer] pr38668: Do not attempt to cast loaded values of non-scalar types.Artem Dergachev2018-12-191-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | 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 a float and load an integer, you won't have your float rounded to an integer; instead, you will have garbage. Admit that we cannot perform the cast as long as types we're dealing with are non-trivial (neither integers, nor pointers). Of course, if the cast is not necessary (eg, T1 == T2), we can still load the value just fine. Differential Revision: https://reviews.llvm.org/D55875 rdar://problem/45062567 llvm-svn: 349701
* [analyzer] Improve modeling for returning an object from the top frame with RVO.Artem Dergachev2018-12-191-8/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Static Analyzer processes the program function-by-function, sometimes diving into other functions ("inlining" them). When an object is returned from an inlined function, Return Value Optimization is modeled, and the returned object is constructed at its return location directly. When an object is returned from the function from which the analysis has started (the top stack frame of the analysis), the return location is unknown. Model it with a SymbolicRegion based on a conjured symbol that is specifically tagged for that purpose, because this is generally the correct way to symbolicate unknown locations in Static Analyzer. Fixes leak false positives when an object is returned from top frame in C++17: objects that are put into a SymbolicRegion-based memory region automatically "escape" and no longer get reported as leaks. This only applies to C++17 return values with destructors, because it produces a redundant CXXBindTemporaryExpr in the call site, which confuses our liveness analysis. The actual fix for liveness analysis is still pending, but it is no longer causing problems. Additionally, re-enable temporary destructor tests in C++17. Differential Revision: https://reviews.llvm.org/D55804 rdar://problem/46217550 llvm-svn: 349696
* [analyzer][NFC] Move CheckerRegistry from the Core directory to FrontendKristof Umann2018-12-152-194/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Prefer returns values to out-params in CheckerRegistry.cppKristof Umann2018-12-151-93/+50
| | | | | | | | | | | | | | | Renaming collectCheckers to getEnabledCheckers Changing the functionality to acquire all enabled checkers, rather then collect checkers for a specific CheckerOptInfo (for example, collecting all checkers for { "core", true }, which meant enabling all checkers from the core package, which was an unnecessary complication). Removing CheckerOptInfo, instead of storing whether the option was claimed via a field, we handle errors immediately, as getEnabledCheckers can now access a DiagnosticsEngine. Realize that the remaining information it stored is directly accessible through AnalyzerOptions.CheckerControlList. Fix a test with -analyzer-disable-checker -verify accidentally left in. llvm-svn: 349274
* [analyzer] Assume that we always have a SubEngine availableGabor Horvath2018-12-156-48/+35
| | | | | | | | The removed codepath was dead. Differential Revision: https://reviews.llvm.org/D55697 llvm-svn: 349266
* Move static analyzer core diagnostics to common.Richard Trieu2018-12-151-1/+0
| | | | llvm-svn: 349230
OpenPOWER on IntegriCloud