summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Self-debug: Dump environment frame-by-frame.Artem Dergachev2018-02-082-4/+6
| | | | | | | | | | | It makes it easier to discriminate between values of similar expressions in different stack frames. It also makes the separate backtrace section in ExplodedGraph dumps redundant. Differential Revision: https://reviews.llvm.org/D42552 llvm-svn: 324660
* Revert r324166 "[analyzer] Add a checker for mmap()...".Artem Dergachev2018-02-031-27/+0
| | | | | | | | Due to Buildbot failures - most likely that's because target triples were not specified in the tests, even though the checker behaves differently with different target triples. llvm-svn: 324167
* [analyzer] Add a checker for mmap()s which are both writable and executable.Artem Dergachev2018-02-031-0/+27
| | | | | | | | | | | | | | This is a security check which is disabled by default but will be enabled whenever the user consciously enables the security package. If mmap()ed memory is both writable and executable, it makes it easier for the attacker to execute arbitrary code when contents of this memory are compromised. Some applications require such mmap()s though, such as different sorts of JIT. Patch by David Carlier! Differential Revision: https://reviews.llvm.org/D42645 llvm-svn: 324166
* [analyzer] Do not infer nullability inside function-like macros, even when ↵George Karpenkov2018-02-031-0/+45
| | | | | | | | | | | | | | | | | | | | | macro is explicitly returning NULL We already suppress such reports for inlined functions, we should then get the same behavior for macros. The underlying reason is that the same macro, can be called from many different contexts, and nullability can only be expected in _some_ of them. Assuming that the macro can return null in _all_ of them sometimes leads to a large number of false positives. E.g. consider the test case for the dynamic cast implementation in macro: in such cases, the bug report is unwanted. Tracked in rdar://36304776 Differential Revision: https://reviews.llvm.org/D42404 llvm-svn: 324161
* [analyzer] Expose return statement from CallExit program pointGeorge Karpenkov2018-02-021-0/+37
| | | | | | | | | | | | | | | | If the return statement is stored, we might as well allow querying against it. Also fix the bug where the return statement is not stored if there is no return value. This change un-merges two ExplodedNodes during call exit when the state is otherwise identical - the CallExitBegin node itself and the "Bind Return Value"-tagged node. And expose the return statement through getStatement helper function. Differential Revision: https://reviews.llvm.org/D42130 llvm-svn: 324052
* [analyzer] Expose exploration strategy through analyzer options.George Karpenkov2018-02-022-2/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D42774 llvm-svn: 324049
* [analyzer] Fix yet-another-crash in body-farming std::call_onceGeorge Karpenkov2018-02-021-1/+44
| | | | | | | | | | | | | | Crash occurs when parameters to the callback and to std::call_once mismatch, and C++ is supposed to auto-construct an argument. Filed by Alexander Kornienko in https://bugs.llvm.org/show_bug.cgi?id=36149 rdar://37034403 Differential Revision: https://reviews.llvm.org/D42777 llvm-svn: 324046
* [analyzer] Don't communicate evaluation failures through memregion hierarchy.Artem Dergachev2018-02-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | We use CXXTempObjectRegion exclusively as a bailout value for construction targets when we are unable to find the correct construction region. Sometimes it works correctly, but rather accidentally than intentionally. Now that we want to increase the amount of situations where it works correctly, the first step is to introduce a different way of communicating our failure to find the correct construction region. EvalCallOptions are introduced for this purpose. For now EvalCallOptions are communicating two kinds of problems: - We have been completely unable to find the correct construction site. - We have found the construction site correctly, and there's more than one of them (i.e. array construction which we currently don't support). Accidentally find and fix a test in which the new approach to communicating failures produces better results. Differential Revision: https://reviews.llvm.org/D42457 llvm-svn: 324018
* [analyzer] Extend SuppressInlineDefensiveChecksVisitor to all macros, ↵George Karpenkov2018-01-302-46/+113
| | | | | | | | | | | | including non-function-like ones No reason to treat function-like macros differently here. Tracked in rdar://29907377 Differential Revision: https://reviews.llvm.org/D42444 llvm-svn: 323827
* [NFC] fix trivial typos in comments and documentsHiroshi Inoue2018-01-261-1/+1
| | | | | | "in in" -> "in", "on on" -> "on" etc. llvm-svn: 323509
* [analyzer] Do not attempt to get the pointee of void*Alexander Shaposhnikov2018-01-241-0/+12
| | | | | | | | | | | | Do not attempt to get the pointee of void* while generating a bug report (otherwise it will trigger an assert inside RegionStoreManager::getBinding assert(!T->isVoidType() && "Attempting to dereference a void pointer!")). Test plan: make check-all Differential revision: https://reviews.llvm.org/D42396 llvm-svn: 323382
* [analyzer] NFC: Run many existing C++ tests with a custom operator new().Artem Dergachev2018-01-2411-3/+40
| | | | | | | | | | | In order to provide more test coverage for inlined operator new(), add more run-lines to existing test cases, which would trigger our fake header to provide a body for operator new(). Most of the code should still behave reasonably. When behavior intentionally changes, #ifs are provided. Differential Revision: https://reviews.llvm.org/D42221 llvm-svn: 323376
* [analyzer] Enable c++-allocator-inlining by default.Artem Dergachev2018-01-244-12/+12
| | | | | | | | | | | | | | | | | | | | | | This allows the analyzer to analyze ("inline") custom operator new() calls and, even more importantly, inline constructors of objects that were allocated by any operator new() - not necessarily a custom one. All changes in the tests in the current commit are intended improvements, even if they didn't carry any explicit FIXME flag. It is possible to restore the old behavior via -analyzer-config c++-allocator-inlining=false (this flag is supported by scan-build as well, and it can be into a clang --analyze invocation via -Xclang .. -Xclang ..). There is no intention to remove the old behavior for now. Differential Revision: https://reviews.llvm.org/D42219 rdar://problem/12180598 llvm-svn: 323373
* [analyzer] Assume that the allocated value is non-null before construction.Artem Dergachev2018-01-243-2/+58
| | | | | | | | | | | | | | | | | | I.e. not after. In the c++-allocator-inlining=true mode, we need to make the assumption that the conservatively evaluated operator new() has returned a non-null value. Previously we did this on CXXNewExpr, but now we have to do that before calling the constructor, because some clever constructors are sometimes assuming that their "this" is null and doing weird stuff. We would also crash upon evaluating CXXNewExpr when the allocator was inlined and returned null and had a throw specification; this is UB even for custom allocators, but we still need not to crash. Added more FIXME tests to ensure that eventually we fix calling the constructor for null return values. Differential Revision: https://reviews.llvm.org/D42192 llvm-svn: 323370
* [analyzer] Mark lines as relevant even if they weren't executed but have a ↵George Karpenkov2018-01-231-0/+12
| | | | | | | | label attached Differential Revision: https://reviews.llvm.org/D42320 llvm-svn: 323251
* [analyzer] Model and check unrepresentable left shiftsGabor Horvath2018-01-221-0/+6
| | | | | | | | Patch by: Reka Nikolett Kovacs Differential Revision: https://reviews.llvm.org/D41816 llvm-svn: 323115
* [NFC] fix trivial typos in commentsHiroshi Inoue2018-01-222-2/+2
| | | | | | "the the" -> "the" llvm-svn: 323078
* [analyzer] Provide a check name when MallocChecker enables CStringCheckerDevin Coughlin2018-01-202-0/+10
| | | | | | | | | Fix an assertion failure caused by a missing CheckName. The malloc checker enables "basic" support in the CStringChecker, which causes some CString bounds checks to be enabled. In this case, make sure that we have a valid CheckName for the BugType. llvm-svn: 323052
* [analyzer] operator new: Fix callback order for CXXNewExpr.Artem Dergachev2018-01-182-0/+61
| | | | | | | | | | | | | | | | PreStmt<CXXNewExpr> was never called. Additionally, under c++-allocator-inlining=true, PostStmt<CXXNewExpr> was called twice when the allocator was inlined: once after evaluating the new-expression itself, once after evaluating the allocator call which, for the lack of better options, uses the new-expression as the call site. This patch fixes both problems. Differential Revision: https://reviews.llvm.org/D41934 rdar://problem/12180598 llvm-svn: 322797
* [analyzer] operator new: Add a new ProgramPoint for check::NewAllocator.Artem Dergachev2018-01-181-48/+49
| | | | | | | | | | | | | | Add PostAllocatorCall program point to represent the moment in the analysis between the operator new() call and the constructor call. Pointer cast from "void *" to the correct object pointer type has already happened by this point. The new program point, unlike the previously used PostImplicitCall, contains a reference to the new-expression, which allows adding path diagnostics over it. Differential Revision: https://reviews.llvm.org/D41800 rdar://problem/12180598 llvm-svn: 322796
* [analyzer] Suppress "this" pointer escape during construction.Artem Dergachev2018-01-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Pointer escape event notifies checkers that a pointer can no longer be reliably tracked by the analyzer. For example, if a pointer is passed into a function that has no body available, or written into a global, MallocChecker would no longer report memory leaks for such pointer. In case of operator new() under -analyzer-config c++-allocator-inlining=true, MallocChecker would start tracking the pointer allocated by operator new() only to immediately meet a pointer escape event notifying the checker that the pointer has escaped into a constructor (assuming that the body of the constructor is not available) and immediately stop tracking it. Even though it is theoretically possible for such constructor to put "this" into a global container that would later be freed, we prefer to preserve the old behavior of MallocChecker, i.e. a memory leak warning, in order to be able to find any memory leaks in C++ at all. In fact, c++-allocator-inlining *reduces* the amount of false positives coming from this-pointers escaping in constructors, because it'd be able to inline constructors in some cases. With other checkers working similarly, we simply suppress the escape event for this-value of the constructor, regardless of analyzer options. Differential Revision: https://reviews.llvm.org/D41797 rdar://problem/12180598 llvm-svn: 322795
* [analyzer] operator new: Fix path diagnostics around the operator call.Artem Dergachev2018-01-181-4/+7
| | | | | | | | | | | | Implements finding appropriate source locations for intermediate diagnostic pieces in path-sensitive bug reports that need to descend into an inlined operator new() call that was called via new-expression. The diagnostics have worked correctly when operator new() was called "directly". Differential Revision: https://reviews.llvm.org/D41409 rdar://problem/12180598 llvm-svn: 322791
* [analyzer] NFC: operator new: Fix new(nothrow) definition in tests.Artem Dergachev2018-01-181-7/+4
| | | | | | | | | Fix the const qualifier so that the operator defined in the tests indeed does override the default global nothrow version of new. Differential Revision: https://reviews.llvm.org/D41408 llvm-svn: 322790
* [analyzer] operator new: Add a new checker callback, check::NewAllocator.Artem Dergachev2018-01-172-8/+28
| | | | | | | | | | | | | | | The callback runs after operator new() and before the construction and allows the checker to access the casted return value of operator new() (in the sense of r322780) which is not available in the PostCall callback for the allocator call. Update MallocChecker to use the new callback instead of PostStmt<CXXNewExpr>, which gets called after the constructor. Differential Revision: https://reviews.llvm.org/D41406 rdar://problem/12180598 llvm-svn: 322787
* [analyzer] operator new: Fix memory space for the returned region.Artem Dergachev2018-01-172-0/+25
| | | | | | | | | | | | | | | Make sure that with c++-allocator-inlining=true we have the return value of conservatively evaluated operator new() in the correct memory space (heap). This is a regression/omission that worked well in c++-allocator-inlining=false. Heap regions are superior to regular symbolic regions because they have stricter aliasing constraints: heap regions do not alias each other or global variables. Differential Revision: https://reviews.llvm.org/D41266 rdar://problem/12180598 llvm-svn: 322780
* [analyzer] operator new: Model the cast of returned pointer into object type.Artem Dergachev2018-01-172-0/+30
| | | | | | | | | | | | | | | | | | | | | | | According to [basic.stc.dynamic.allocation], the return type of any C++ overloaded operator new() is "void *". However, type of the new-expression "new T()" and the type of "this" during construction of "T" are both "T *". Hence an implicit cast, which is not present in the AST, needs to be performed before the construction. This patch adds such cast in the case when the allocator was indeed inlined. For now, in the case where the allocator was *not* inlined we still use the same symbolic value (which is a pure SymbolicRegion of type "T *") because it is consistent with how we represent the casts and causes less surprise in the checkers after switching to the new behavior. The better approach would be to represent that value as a cast over a SymbolicRegion of type "void *", however we have technical difficulties conjuring such region without any actual expression of type "void *" present in the AST. Differential Revision: https://reviews.llvm.org/D41250 rdar://problem/12180598 llvm-svn: 322777
* [analyzer] operator new: Use the correct region for the constructor.Artem Dergachev2018-01-175-8/+210
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The -analyzer-config c++-allocator-inlining experimental option allows the analyzer to reason about C++ operator new() similarly to how it reasons about regular functions. In this mode, operator new() is correctly called before the construction of an object, with the help of a special CFG element. However, the subsequent construction of the object was still not performed into the region of memory returned by operator new(). The patch fixes it. Passing the value from operator new() to the constructor and then to the new-expression itself was tricky because operator new() has no call site of its own in the AST. The new expression itself is not a good call site because it has an incorrect type (operator new() returns 'void *', while the new expression is a pointer to the allocated object type). Additionally, lifetime of the new expression in the environment makes it unsuitable for passing the value. For that reason, an additional program state trait is introduced to keep track of the return value. Finally this patch relaxes restrictions on the memory region class that are required for inlining the constructor. This change affects the old mode as well (c++-allocator-inlining=false) and seems safe because these restrictions were an overkill compared to the actual problems observed. Differential Revision: https://reviews.llvm.org/D40560 rdar://problem/12180598 llvm-svn: 322774
* [analyzer] support a mode to only show relevant lines in HTML diagnosticsGeorge Karpenkov2018-01-177-0/+108
| | | | | | | | | | | | | | HTML diagnostics can be an overwhelming blob of pages of code. This patch adds a checkbox which filters this list down to only the lines *relevant* to the counterexample by e.g. skipping branches which analyzer has assumed to be infeasible at a time. The resulting amount of output is much smaller, and often fits on one screen, and also provides a much more readable diagnostics. Differential Revision: https://reviews.llvm.org/D41378 llvm-svn: 322612
* [analyzer] Don't flag strcpy of string literals into sufficiently large buffers.Artem Dergachev2018-01-121-0/+10
| | | | | | | | | | | | | | | In the security package, we have a simple syntactic check that warns about strcpy() being insecure, due to potential buffer overflows. Suppress that check's warning in the trivial situation when the source is an immediate null-terminated string literal and the target is an immediate sufficiently large buffer. Patch by András Leitereg! Differential Revision: https://reviews.llvm.org/D41384 llvm-svn: 322410
* [analyzer] suppress nullability inference from a macro when result is used ↵George Karpenkov2018-01-101-0/+10
| | | | | | | | | | | | | | | | | | in another macro The current code used to not suppress the report, if the dereference was performed in a macro, assuming it is that same macro. However, the assumption might not be correct, and XNU has quite a bit of code where dereference is actually performed in a different macro. As the code uses macro name and not a unique identifier it might be fragile, but in a worst-case scenario we would simply emit an extra diagnostic. rdar://36160245 Differential Revision: https://reviews.llvm.org/D41749 llvm-svn: 322149
* [analyzer] Fix some check's output plist not containing the check nameGabor Horvath2018-01-061-7/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D41538 llvm-svn: 321933
* [analyzer] do not crash with assertion on processing locations of bodyfarmed ↵George Karpenkov2018-01-021-4/+5
| | | | | | | | | | | | | | | functions This addresses an issue introduced in r183451: since `removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`, it is not necessary, and in fact harmful, to have this assertion in adjustCallLocations. Addresses rdar://36170689 Differential Revision: https://reviews.llvm.org/D41680 llvm-svn: 321682
* [analyzer] Fix zero-initialization of stack VLAs under ObjC ARC.Artem Dergachev2017-12-211-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using ARC, strong, weak, and autoreleasing stack variables are implicitly initialized with nil. This includes variable-length arrays of Objective-C object pointers. However, in the analyzer we don't zero-initialize them. We used to, but it accidentally regressed after r289618. Under ARC, the array variable's initializer within DeclStmt is an ImplicitValueInitExpr. Environment doesn't maintain any bindings for this expression kind - instead it always knows that it's a known constant (0 in our case), so it just returns the known value by calling SValBuilder::makeZeroVal() (see EnvironmentManager::getSVal(). Commit r289618 had introduced reasonable behavior of SValBuilder::makeZeroVal() for the arrays, which produces a zero-length compoundVal{}. When such value is bound to arrays, in RegionStoreManager::bindArray() "remaining" items in the array are default-initialized with zero, as in RegionStoreManager::setImplicitDefaultValue(). The similar mechanism works when an array is initialized by an initializer list that is too short, eg. int a[3] = { 1, 2 }; would result in a[2] initialized with 0. However, in case of variable-length arrays it didn't know if any more items need to be added, because, well, the length is variable. Add the default binding anyway, regardless of how many actually need to be added. We don't really care how many, because the default binding covers the whole array anyway. Differential Revision: https://reviews.llvm.org/D41478 rdar://problem/35477763 llvm-svn: 321290
* [analyzer] De-duplicate path diagnostics for each exploded graph node.Artem Dergachev2017-12-201-261/+230
| | | | | | | | | | | | | | | | | | | | | | | | | | The bugreporter::trackNullOrUndefValue() mechanism contains a system of bug reporter visitors that recursively call each other in order to track where a null or undefined value came from, where each visitor represents a particular tracking mechanism (track how the value was stored, track how the value was returned from a function, track how the value was constrained to null, etc.). Each visitor is only added once per value it needs to track. Almost. One exception from this rule would be FindLastStoreBRVisitor that has two operation modes: it contains a flag that indicates whether null stored values should be suppressed. Two instances of FindLastStoreBRVisitor with different values of this flag are considered to be different visitors, so they can be added twice and produce the same diagnostic twice. This was indeed the case in the affected test. With the current logic of this whole machinery, such duplication seems unavoidable. We should be able to safely add visitors with different flag values without constructing duplicate diagnostic pieces. Hence the effort in this commit to de-duplicate diagnostics regardless of what visitors have produced them. Differential Revision: https://reviews.llvm.org/D41258 llvm-svn: 321135
* [analyzer] trackNullOrUndefValue: always track through parentheses and casts.Artem Dergachev2017-12-205-329/+594
| | | | | | | | | | | | | | | When trying to figure out where a null or undefined value came from, parentheses and cast expressions are either completely irrelevant, or, in the case of lvalue-to-rvale cast, straightforwardly lead us in the right direction when we remove them. There is a regression that causes a certain diagnostic to appear twice in the path-notes.cpp test (changed to FIXME). It would be addressed in the next commit. Differential revision: https://reviews.llvm.org/D41254 llvm-svn: 321133
* [analyzer] trackNullOrUndefValue: track last store to non-variables.Artem Dergachev2017-12-202-2/+21
| | | | | | | | | | | | | | | | | When reporting certain kinds of analyzer warnings, we use the bugreporter::trackNullOrUndefValue mechanism, which is part of public checker API, to understand where a zero, null-pointer, or garbage value came from, which would highlight important events with respect to that value in the diagnostic path notes, and help us suppress various false positives that result from values appearing from particular sources. Previously, we've lost track of the value when it was written into a memory region that is not a plain variable. Now try to resume tracking in this situation by finding where the last write to this region has occured. Differential revision: https://reviews.llvm.org/D41253 llvm-svn: 321130
* [analyzer] Fix a crash during C++17 aggregate construction of base objects.Artem Dergachev2017-12-201-0/+40
| | | | | | | | | | | | | | | | | | | | | | | Since C++17, classes that have base classes can potentially be initialized as aggregates. Trying to construct such objects through brace initialization was causing the analyzer to crash when the base class has a non-trivial constructor, while figuring target region for the base class constructor, because the parent stack frame didn't contain the constructor of the subclass, because there is no constructor for subclass, merely aggregate initialization. This patch avoids the crash, but doesn't provide the actually correct region for the constructor, which still remains to be fixed. Instead, construction goes into a fake temporary region which would be immediately discarded. Similar extremely conservative approach is used for other cases in which the logic for finding the target region is not yet implemented, including aggregate initialization with fields instead of base-regions (which is not C++17-specific but also never worked, just didn't crash). Differential revision: https://reviews.llvm.org/D40841 rdar://problem/35441058 llvm-svn: 321128
* [analyzer] StackAddrEscape: For now, disable the new async escape checks.Artem Dergachev2017-12-122-2/+16
| | | | | | | | | | | | | | | | | The new check introduced in r318705 is useful, but suffers from a particular class of false positives, namely, it does not account for dispatch_barrier_sync() API which allows one to ensure that the asyncronously executed block that captures a pointer to a local variable does not actually outlive that variable. The new check is split into a separate checker, under the name of alpha.core.StackAddressAsyncEscape, which is likely to get enabled by default again once these positives are fixed. The rest of the StackAddressEscapeChecker is still enabled by default. Differential Revision: https://reviews.llvm.org/D41042 llvm-svn: 320455
* [analyzer] do not crash on cases where an array subscript is an rvalueGeorge Karpenkov2017-12-051-0/+33
| | | | | | | | | | | | | Array subscript is almost always an lvalue, except for a few cases where it is not, such as a subscript into an Objective-C property, or a return from the function. This commit prevents crashing in such cases. Fixes rdar://34829842 Differential Revision: https://reviews.llvm.org/D40584 llvm-svn: 319834
* [analyzer] Don't treat lambda-captures float constexprs as undefinedDevin Coughlin2017-12-041-0/+10
| | | | | | | | | | | | | | RegionStore has special logic to evaluate captured constexpr variables. However, if the constexpr initializer cannot be evaluated as an integer, the value is treated as undefined. This leads to false positives when, for example, a constexpr float is captured by a lambda. To fix this, treat a constexpr capture that cannot be evaluated as unknown rather than undefined. rdar://problem/35784662 llvm-svn: 319638
* [analyzer] Fix false negative on post-increment of uninitialized variable.Roman Lebedev2017-11-303-540/+570
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently clang static analyzer does warn on: ``` int x; x+=1; x-=1; x=x+1; x=x-1; ``` But does warn on: ``` int x; x++; x--; --x; ++x; ``` This differential should fix that. Fixes https://bugs.llvm.org/show_bug.cgi?id=35419 Reviewers: dcoughlin, NoQ Reviewed By: dcoughlin Subscribers: NoQ, xazax.hun, szepet, cfe-commits, a.sidorin Tags: #clang Differential Revision: https://reviews.llvm.org/D40463 llvm-svn: 319411
* [analyzer] Fix unreachable creating PathDiagnosticLocation with widen-loops=trueDevin Coughlin2017-11-291-0/+72
| | | | | | | | | | | | | In the original design of the analyzer, it was assumed that a BlockEntrance doesn't create a new binding on the Store, but this assumption isn't true when 'widen-loops' is set to true. Fix this by finding an appropriate location BlockEntrace program points. Patch by Henry Wong! Differential Revision: https://reviews.llvm.org/D37187 llvm-svn: 319333
* [analyzer] pr34766: Fix a crash on explicit std::initializer_list constructor.Artem Dergachev2017-11-271-1/+5
| | | | | | | | | | | | | | | | We didn't support the following syntax: (std::initializer_list<int>){12} which suddenly produces CompoundLiteralExpr that contains CXXStdInitializerListExpr. Lift the assertion and instead pass the value through CompoundLiteralExpr transparently, as it doesn't add much. Differential Revision: https://reviews.llvm.org/D39803 llvm-svn: 319058
* [analyzer] pr34404: Fix a crash on modeling pointers to indirect members.Artem Dergachev2017-11-271-0/+39
| | | | | | | | | | | | | | | | | We were crashing whenever a C++ pointer-to-member was taken, that was pointing to a member of an anonymous structure field within a class, eg. struct A { struct { int x; }; }; // ... &A::x; Differential Revision: https://reviews.llvm.org/D39800 llvm-svn: 319055
* [analyzer] Teach RetainCountChecker about CoreMedia APIsDevin Coughlin2017-11-251-0/+45
| | | | | | | | | | Teach the retain-count checker that CoreMedia reference types use CoreFoundation-style reference counting. This enables the checker to catch leaks and over releases of those types. rdar://problem/33599757 llvm-svn: 318979
* [Analyzer] Stable iteration on indirect goto LabelDecl's to avoid ↵Aleksei Sidorin2017-11-211-0/+96
| | | | | | | | | | | | | | | | | | | | non-determinism (attempt 2) CFG wass built in non-deterministic order due to the fact that indirect goto labels' declarations (LabelDecl's) are stored in the llvm::SmallSet container. LabelDecl's are pointers, whose order is not deterministic, and llvm::SmallSet sorts them by their non-deterministic addresses after "small" container is exceeded. This leads to non-deterministic processing of the elements of the container. The fix is to use llvm::SmallSetVector that was designed to have deterministic iteration order. Patch by Ilya Palachev! Differential Revision: https://reviews.llvm.org/D40073 llvm-svn: 318754
* [Analyzer] Revert r318750 because incorrect files were added for commit.Aleksei Sidorin2017-11-211-96/+0
| | | | | | Sorry for the noise. llvm-svn: 318753
* [Analyzer] Non-determinism: stable iteration on indirect goto LabelDecl'sAleksei Sidorin2017-11-211-0/+96
| | | | | | | | | | | | | | | | | | CFG wass built in non-deterministic order due to the fact that indirect goto labels' declarations (LabelDecl's) are stored in the llvm::SmallSet container. LabelDecl's are pointers, whose order is not deterministic, and llvm::SmallSet sorts them by their non-deterministic addresses after "small" container is exceeded. This leads to non-deterministic processing of the elements of the container. The fix is to use llvm::SmallSetVector that was designed to have deterministic iteration order. Patch by Ilya Palachev! Differential Revision: https://reviews.llvm.org/D40073 llvm-svn: 318750
* [analyzer] Diagnose stack leaks via block capturesAlexander Shaposhnikov2017-11-202-0/+212
| | | | | | | | | | | This diff extends StackAddrEscapeChecker to catch stack addresses leaks via block captures if the block is executed asynchronously or returned from a function. Differential revision: https://reviews.llvm.org/D39438 llvm-svn: 318705
* [analyzer] ObjCGenerics: Don't warn on cast conversions involving explicit castDevin Coughlin2017-11-131-597/+564
| | | | | | | | | | | | | | | | | | | | | | The ObjCGenerics checker warns on a cast when there is no subtyping relationship between the tracked type of the value and the destination type of the cast. It does this even if the cast was explicitly written. This means the user can't write an explicit cast to silence the diagnostic. This commit treats explicit casts involving generic types as an indication from the programmer that the Objective-C type system is not rich enough to express the needed invariant. On explicit casts, the checker now removes any existing information inferred about the type arguments. Further, it no longer assumes the casted-to specialized type because the invariant the programmer specifies in the cast may only hold at a particular program point and not later ones. This prevents a suppressing cast from requiring a cascade of casts down the line. rdar://problem/33603303 Differential Revision: https://reviews.llvm.org/D39711 llvm-svn: 318054
OpenPOWER on IntegriCloud