summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Model and check unrepresentable left shiftsGabor Horvath2018-01-222-3/+25
| | | | | | | | 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-201-1/+11
| | | | | | | | | 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] a few helper methods for getting and comparing symbolic valuesGeorge Karpenkov2018-01-182-1/+21
| | | | | | | | API calls should express intent, and that's a motivation behind this patch. Differential Revision: https://reviews.llvm.org/D42218 llvm-svn: 322809
* [analyzer] NFC: RetainCount: Protect from dumping raw region to path notes.Artem Dergachev2018-01-181-2/+8
| | | | | | | | | | | | | | | | | | MemRegion::getString() is a wrapper around MemRegion::dump(), which is not user-friendly and should never be used for diagnostic messages. Actual cases where raw dumps were reaching the user were unintentionally fixed in r315736; these were noticed accidentally and shouldn't be reproducible anymore. For now RetainCountChecker only tracks pointers through variable regions, and for those dumps are "fine". However, we should still use a less dangerous method for producing our path notes. This patch replaces the dump with printing a variable name, asserting that this is indeed a variable. Differential Revision: https://reviews.llvm.org/D42015 llvm-svn: 322799
* [analyzer] operator new: Fix callback order for CXXNewExpr.Artem Dergachev2018-01-183-2/+53
| | | | | | | | | | | | | | | | 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-183-7/+5
| | | | | | | | | | | | | | 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-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+4
| | | | | | | | | | | | 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] operator new: Add a new checker callback, check::NewAllocator.Artem Dergachev2018-01-175-31/+140
| | | | | | | | | | | | | | | 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 ambigious type name.Artem Dergachev2018-01-171-2/+3
| | | | | | Hopefully fixes an MSVC buildbot failure. llvm-svn: 322781
* [analyzer] operator new: Fix memory space for the returned region.Artem Dergachev2018-01-172-18/+20
| | | | | | | | | | | | | | | 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-13/+41
| | | | | | | | | | | | | | | | | | | | | | | 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] NFC: Forbid array elements of void type.Artem Dergachev2018-01-172-3/+17
| | | | | | | | | | | | | | | Represent the symbolic value for results of pointer arithmetic on void pointers in a different way: instead of making void-typed element regions, make char-typed element regions. Add an assertion that ensures that no void-typed regions are ever constructed. This is a refactoring of internals that should not immediately affect the analyzer's (default) behavior. Differential Revision: https://reviews.llvm.org/D40939 llvm-svn: 322775
* [analyzer] operator new: Use the correct region for the constructor.Artem Dergachev2018-01-173-39/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] introduce getSVal(Stmt *) helper on ExplodedNode, make sure the ↵George Karpenkov2018-01-1736-160/+108
| | | | | | | | | | | | | | | | | | helper is used consistently In most cases using `N->getState()->getSVal(E, N->getLocationContext())` is ugly, verbose, and also opens up more surface area for bugs if an inconsistent location context is used. This patch introduces a helper on an exploded node, and ensures consistent usage of either `ExplodedNode::getSVal` or `CheckContext::getSVal` across the codebase. As a result, a large number of redundant lines is removed. Differential Revision: https://reviews.llvm.org/D42155 llvm-svn: 322753
* [analyzer] Make isSubRegionOf reflexiveGeorge Karpenkov2018-01-175-10/+7
| | | | | | | | | All usages of isSubRegionOf separately check for reflexive case, and in any case, set theory tells us that each set is a subset of itself. Differential Revision: https://reviews.llvm.org/D42140 llvm-svn: 322752
* [analyzer] Better UI in html reports for displaying shortcuts helpGeorge Karpenkov2018-01-171-3/+44
| | | | | | | Make the help window accessible, but don't show by default. Use a different CSS class from macro. llvm-svn: 322750
* [analyzer] support a mode to only show relevant lines in HTML diagnosticsGeorge Karpenkov2018-01-173-17/+174
| | | | | | | | | | | | | | 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/+11
| | | | | | | | | | | | | | | 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] [NFC] Minor refactoring of trackNullOrUndefValueGeorge Karpenkov2018-01-101-80/+97
| | | | | | | | | Simple refactoring attempt: factor out some code, remove some repetition, use auto where appropriate. Differential Revision: https://reviews.llvm.org/D41751 llvm-svn: 322151
* [analyzer] [NFC] minor FindLastStoreBRVisitor refactoringGeorge Karpenkov2018-01-101-112/+127
| | | | | | Differential Revision: https://reviews.llvm.org/D41790 llvm-svn: 322150
* [analyzer] suppress nullability inference from a macro when result is used ↵George Karpenkov2018-01-101-4/+14
| | | | | | | | | | | | | | | | | | 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-062-8/+17
| | | | | | 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-1/+0
| | | | | | | | | | | | | | | 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] Add Javascript to analyzer HTML output to allow keyboard navigation.George Karpenkov2017-12-211-2/+93
| | | | | | Differential Revision: https://reviews.llvm.org/D41414 llvm-svn: 321320
* Re-commit r321223, which adds a printing policy to the ASTDumper.Aaron Ballman2017-12-211-328/+330
| | | | | | | | This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms. Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test. llvm-svn: 321310
* [analyzer] Fix zero-initialization of stack VLAs under ObjC ARC.Artem Dergachev2017-12-211-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Reverting r321223 and its follow-up commit because of failing bots due to ↵Aaron Ballman2017-12-201-330/+328
| | | | | | Misc/ast-dump-color.cpp. llvm-svn: 321229
* Add a printing policy to the ASTDumper.Aaron Ballman2017-12-201-328/+330
| | | | | | This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms. llvm-svn: 321223
* [analyzer] De-duplicate path diagnostics for each exploded graph node.Artem Dergachev2017-12-201-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-201-6/+2
| | | | | | | | | | | | | | | 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-201-1/+4
| | | | | | | | | | | | | | | | | 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-202-2/+32
| | | | | | | | | | | | | | | | | | | | | | | 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
* [c++20] P0515R3: Parsing support and basic AST construction for operator <=>.Richard Smith2017-12-145-5/+10
| | | | | | | | | | | | | | | Adding the new enumerator forced a bunch more changes into this patch than I would have liked. The -Wtautological-compare warning was extended to properly check the new comparison operator, clang-format needed updating because it uses precedence levels as weights for determining where to break lines (and several operators increased their precedence levels with this change), thread-safety analysis needed changes to build its own IL properly for the new operator. All "real" semantic checking for this operator has been deferred to a future patch. For now, we use the relational comparison rules and arbitrarily give the builtin form of the operator a return type of 'void'. llvm-svn: 320707
* [analyzer] StackAddrEscape: For now, disable the new async escape checks.Artem Dergachev2017-12-121-3/+24
| | | | | | | | | | | | | | | | | 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] In getSVal() API, disable auto-detection of void type as char type.Artem Dergachev2017-12-123-9/+15
| | | | | | | | | | | | | | | | | | This is a follow-up from r314910. When a checker developer attempts to dereference a location in memory through ProgramState::getSVal(Loc) or ProgramState::getSVal(const MemRegion *), without specifying the second optional QualType parameter for the type of the value he tries to find at this location, the type is auto-detected from location type. If the location represents a value beyond a void pointer, we thought that auto-detecting the type as 'char' is a good idea. However, in most practical cases, the correct behavior would be to specify the type explicitly, as it is available from other sources, and the few cases where we actually need to take a 'char' are workarounds rather than an intended behavior. Therefore, try to fail with an easy-to-understand assertion when asked to read from a void pointer location. Differential Revision: https://reviews.llvm.org/D38801 llvm-svn: 320451
* [analyzer] do not crash on cases where an array subscript is an rvalueGeorge Karpenkov2017-12-051-11/+24
| | | | | | | | | | | | | 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] Mark heap-based symbolic regions in debug dumps.Artem Dergachev2017-12-051-0/+2
| | | | | | | | | | | They are now printed as HeapSymRegion{$x} in order to discriminate between that and regular SymRegion{$x}, which are two different regions, having different parent reginos (memory spaces) - HeapSpaceRegion and UnknownSpaceRegion respectively. Differential Revision: https://reviews.llvm.org/D40793 llvm-svn: 319793
* [analyzer] [NFC] remove duplicated functionGeorge Karpenkov2017-12-041-31/+12
| | | | | | | | | | | Two copies of getSymLERange in RangeConstraintManager are virtually identical, which is clearly bad. This patch uses lambdas to call one from another (assuming that we would like to avoid getting ranges from the state when necessary). Differential Revision: https://reviews.llvm.org/D39709 llvm-svn: 319697
* [analyzer] Don't treat lambda-captures float constexprs as undefinedDevin Coughlin2017-12-041-2/+9
| | | | | | | | | | | | | | 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-302-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+9
| | | | | | | | | | | | | 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/+1
| | | | | | | | | | | | | | | | 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-1/+3
| | | | | | | | | | | | | | | | | 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-4/+4
| | | | | | | | | | 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] Diagnose stack leaks via block capturesAlexander Shaposhnikov2017-11-201-99/+192
| | | | | | | | | | | 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
* Add NDEBUG checks around LLVM_DUMP_METHOD functions for Wunused-function ↵Eric Christopher2017-11-162-1/+4
| | | | | | warnings. llvm-svn: 318371
* [clang] Remove redundant return [NFC]Mandeep Singh Grang2017-11-131-2/+0
| | | | | | | | | | | | | | Reviewers: rsmith, sfantao, mcrosier Reviewed By: mcrosier Subscribers: jholewinski, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D39915 llvm-svn: 318074
* [analyzer] ObjCGenerics: Don't warn on cast conversions involving explicit castDevin Coughlin2017-11-131-16/+16
| | | | | | | | | | | | | | | | | | | | | | 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