summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer
Commit message (Collapse)AuthorAgeFilesLines
* [Analyzer] [HOTFIX!] SValBuilder crash when ↵Adam Balogh2018-12-051-3/+4
| | | | | | | | | | | | | `aggressive-binary-operation-simplification` enabled During the review of D41938 a condition check with an early exit accidentally slipped into a branch, leaving the other branch unprotected. This may result in an assertion later on. This hotfix moves this contition check outside of the branch. Differential Revision: https://reviews.llvm.org/D55051 llvm-svn: 348362
* Add missing semicolon.Simon Pilgrim2018-08-011-1/+1
| | | | llvm-svn: 338510
* Replace 'FALL-THROUGH' comment with LLVM_FALLTHROUGH to silence warning. NFCI.Simon Pilgrim2018-08-011-1/+1
| | | | llvm-svn: 338508
* [analyzer] CallEvent: Add helper methods for obtaining the callee stack frame.Artem Dergachev2018-08-011-0/+63
| | | | | | | | | | | | Newly added methods allow reasoning about the stack frame of the call (as opposed to the stack frame on which the call was made, which was always available) - obtain the stack frame context, obtain parameter regions - even if the call is not going to be (or was not) inlined, i.e. even if the analysis has never actually entered the stack frame. Differential Revision: https://reviews.llvm.org/D49715 llvm-svn: 338474
* [analyzer] Fix eliding the same destructor twice due to buggy default arguments.Artem Dergachev2018-07-311-1/+2
| | | | | | | | | | | Because of incomplete support for CXXDefaultArgExpr, we cannot yet commit to asserting that the same destructor won't be elided twice. Suppress the assertion failure for now. Proper support is still an open problem. Differential Revision: https://reviews.llvm.org/D49213 llvm-svn: 338441
* [CFG] [analyzer] NFC: Enumerate construction context layer kinds.Artem Dergachev2018-07-311-93/+48
| | | | | | | | | | | | | | This is a refactoring patch; no functional change intended. The common part of ConstructionContextLayer and ConstructedObjectKey is factored out into a new structure, ConstructionContextItem. Various sub-kinds of ConstructionContextItem are enumerated in order to provide richer information about construction contexts. Differential Revision: https://reviews.llvm.org/D49210. llvm-svn: 338439
* [CFG] [analyzer] Implement function argument construction contexts.Artem Dergachev2018-07-311-11/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | In r330377 and r338425 we have already identified what constitutes function argument constructors and added stubs in order to prevent confusing them with other temporary object constructors. Now we implement a ConstructionContext sub-class to carry all the necessary information about the construction site, namely call expression and argument index. On the analyzer side, the patch interacts with the recently implemented pre-C++17 copy elision support in an interesting manner. If on the CFG side we didn't find a construction context for the elidable constructor, we build the CFG as if the elidable constructor is not elided, and the non-elided constructor within it is a simple temporary. But the same problem may occur in the analyzer: if the elidable constructor has a construction context but the analyzer doesn't implement such context yet, the analyzer should also try to skip copy elision and still inline the non-elided temporary constructor. This was implemented by adding a "roll back" mechanism: when elision fails, roll back the changes and proceed as if it's a simple temporary. The approach is wonky, but i'm fine with that as long as it's merely a defensive mechanism that should eventually go away once all construction contexts become supported. Differential Revision: https://reviews.llvm.org/D48681. llvm-svn: 338436
* [analyzer] Reuse some code in simplifySVal().Artem Dergachev2018-07-311-21/+22
| | | | | | | | No functional change intended. Differential Revision: https://reviews.llvm.org/D49826 llvm-svn: 338422
* [analyzer] Don't try to simplify mixed Loc/NonLoc expressions.Artem Dergachev2018-07-311-0/+11
| | | | | | | | | | | | | | | | | | This fix is similar to r337769 and addresses a regression caused by r337167. When an operation between a nonloc::LocAsInteger and a non-pointer symbol is performed, the LocAsInteger-specific part of information is lost. When the non-pointer symbol is collapsing into a constant, we cannot easily re-evaluate the result, because we need to recover the missing LocAsInteger-specific information (eg., integer type, or the very fact that this pointer was at some point converted to an integer). Add one more defensive check to prevent crashes on trying to simplify a SymSymExpr with different Loc-ness of operands. Differential Revision: llvm-svn: 338420
* [analyzer] CStringChecker: Remember to highlight the argument expression range.Artem Dergachev2018-07-301-0/+1
| | | | | | | | | | | | | | | | | | | | | When emitting a bug report, it is important to highlight which argument of the call-expression is causing the problem. Before: warning: Null pointer argument in call to string comparison function   strcmp(a, b);   ^~~~~~~~~~~~ After: warning: Null pointer argument in call to string comparison function   strcmp(a, b);   ^      ~ Affects other output modes as well, not just text. Differential Revision: https://reviews.llvm.org/D50028 llvm-svn: 338333
* [analyzer] [NFC] Simplify some visitors by giving a convenient getter from ↵George Karpenkov2018-07-302-22/+20
| | | | | | | | state to analysis manager Differential Revision: https://reviews.llvm.org/D49772 llvm-svn: 338315
* [analyzer] Bugfix for autorelease + main run loop leak checkerGeorge Karpenkov2018-07-301-4/+9
| | | | | | | | | Do not warn when the other message-send-expression is correctly wrapped in a different autorelease pool. Differential Revision: https://reviews.llvm.org/D49921 llvm-svn: 338314
* [analyzer] Fix crash in RunLoopAutoreleaseChecker on empty childrenGeorge Karpenkov2018-07-301-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D50012 llvm-svn: 338312
* Remove trailing spaceFangrui Song2018-07-308-34/+34
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [analyzer] Add missing state transition in IteratorChecker.Reka Kovacs2018-07-301-0/+2
| | | | | | | | | After cleaning up program state maps in `checkDeadSymbols()`, a transition should be added to generate the new state. Differential Revision: https://reviews.llvm.org/D47417 llvm-svn: 338263
* [analyzer] Add support for more invalidating functions in InnerPointerChecker.Reka Kovacs2018-07-302-61/+132
| | | | | | | | | | | | According to the standard, pointers referring to the elements of a `basic_string` may be invalidated if they are used as an argument to any standard library function taking a reference to non-const `basic_string` as an argument. This patch makes InnerPointerChecker warn for these cases. Differential Revision: https://reviews.llvm.org/D49656 llvm-svn: 338259
* [Analyzer] Iterator Checker Hotfix: Defer deletion of container data until ↵Adam Balogh2018-07-301-1/+22
| | | | | | | | | | | | | | its last iterator is cleaned up The analyzer may consider a container region as dead while it still has live iterators. We must defer deletion of the data belonging to such containers until all its iterators are dead as well to be able to compare the iterator to the begin and the end of the container which is stored in the container data. Differential Revision: https://reviews.llvm.org/D48427 llvm-svn: 338234
* [analyzer] Extend NoStoreFuncVisitor to insert a note on IVarsGeorge Karpenkov2018-07-271-13/+50
| | | | | | | | | | | | | | The note is added in the following situation: - We are throwing a nullability-related warning on an IVar - The path goes through a method which *could have* (syntactically determined) written into that IVar, but did not rdar://42444460 Differential Revision: https://reviews.llvm.org/D49689 llvm-svn: 338149
* [analyzer] Fixed method to get APSInt modelMikhail R. Gadelha2018-07-261-23/+18
| | | | | | | | | | | | | | | | | | | Summary: This patch replaces the current method of getting an `APSInt` from Z3's model by calling generic API method `getBitvector` instead of `Z3_get_numeral_uint64`. By calling `getBitvector`, there's no need to handle bitvectors with bit width == 128 separately. And, as a bonus, clang now compiles correctly with Z3 4.7.1. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49818 llvm-svn: 338020
* [analyzer] Update SMT API documentation and methodsMikhail R. Gadelha2018-07-252-24/+19
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Update the documentation of all the classes introduced with the new generic SMT API, most of them were referencing Z3 and how previous operations were being done (like including the context as parameter in a few methods). Renamed the following methods, so it's clear that the operate on bitvectors: *`mkSignExt` -> `mkBVSignExt` *`mkZeroExt` -> `mkBVZeroExt` *`mkExtract` -> `mkBVExtract` *`mkConcat` -> `mkBVConcat` Removed the unecessary methods: * `getDataExpr`: it was an one line method that called `fromData` * `mkBitvector(const llvm::APSInt Int)`: it was not being used anywhere Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49799 llvm-svn: 337954
* [analyzer] Use the macro REGISTER_TRAIT_WITH_PROGRAMSTATE in the Z3 backendMikhail R. Gadelha2018-07-251-22/+7
| | | | | | | | | | | | | | | | | Summary: The macro was manually expanded in the Z3 backend and this patch adds it back. Adding the expanded code is dangerous as the macro may change in the future and the expanded code might be left outdated. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49769 llvm-svn: 337923
* [analyzer] Removed API used by the Refutation Manager from ↵Mikhail R. Gadelha2018-07-253-58/+43
| | | | | | | | | | | | | | | | | | | | | | | SMTConstraintManager and replace by proper calls to SMTSolver Summary: Third patch in the refactoring series, to decouple the SMT Solver from the Refutation Manager (1st: D49668, 2nd: D49767). The refutation API in the `SMTConstraintManager` was a hack to allow us to create an SMT solver and verify the constraints; it was conceptually wrong from the start. Now, we don't actually need to use the `SMTConstraintManager` and can create an SMT object directly, add the constraints and check them. While updating the Falsification visitor, I inlined the two functions that were used to collect the constraints and add them to the solver. As a result of this patch, we could move the SMT API elsewhere and as it's not really dependent on the CSA anymore. Maybe we can create a new dir (utils/smt) for Z3 and future solvers? Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49768 llvm-svn: 337922
* [analyzer] Moved code from SMTConstraintManager to SMTSolverMikhail R. Gadelha2018-07-251-298/+24
| | | | | | | | | | | | | | | | | Summary: This is the second part of D49668, and moves all the code that's not specific to a ConstraintManager to SMTSolver. No functional change intended. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49767 llvm-svn: 337921
* [analyzer] Try to minimize the number of equivalent bug reports evaluated by ↵Mikhail R. Gadelha2018-07-251-4/+17
| | | | | | | | | | | | | | | | | | | | | | | the refutation manager Summary: This patch changes how the SMT bug refutation runs in an equivalent bug report class. Now, all other visitor are executed until they find a valid bug or mark all bugs as invalid. When the one valid bug is found (and crosscheck is enabled), the SMT refutation checks the satisfiability of this single bug. If the bug is still valid after checking with Z3, it is returned and a bug report is created. If the bug is found to be invalid, the next bug report in the equivalent class goes through the same process, until we find a valid bug or all bugs are marked as invalid. Massive speedups when verifying redis/src/rax.c, from 1500s to 10s. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49693 llvm-svn: 337920
* [analyzer] Moved non solver specific code from Z3ConstraintManager to ↵Mikhail R. Gadelha2018-07-253-765/+552
| | | | | | | | | | | | | | | | | | | | | | | SMTConstraintManager Summary: This patch moves a lot of code from `Z3ConstraintManager` to `SMTConstraintManager`, leaving only the necessary: * `canReasonAbout` which returns if a Solver can handle a given `SVal` (should be moved to `SMTSolver` in the future). * `removeDeadBindings`, `assumeExpr` and `print`: methods that need to use `ConstraintZ3Ty`, can probably be moved to `SMTConstraintManager` in the future. The patch creates a new file, `SMTConstraintManager.cpp` with the moved code. Conceptually, this is move in the right direction and needs further improvements: `SMTConstraintManager` still does a lot of things that are not required by a `ConstraintManager`. We ought to move the unrelated to `SMTSolver` and remove everything that's not related to a `ConstraintManager`. In particular, we could remove `addRangeConstraints` and `isModelFeasible`, and make the refutation manager create an Z3Solver directly. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: mgorny, xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49668 llvm-svn: 337919
* [analyzer] Implemented SMT generic APIMikhail R. Gadelha2018-07-251-545/+569
| | | | | | | | | | | | | | | | | Summary: Created new SMT generic API. Small changes to `Z3ConstraintManager` because of the new generic objects (`SMTSort` and `SMTExpr`) returned by `SMTSolver`. Reviewers: george.karpenkov, NoQ Reviewed By: george.karpenkov Subscribers: mgorny, xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49495 llvm-svn: 337918
* [analyzer] Create generic SMT Expr classMikhail R. Gadelha2018-07-251-53/+44
| | | | | | | | | | | | | | | | | Summary: New base class for all future SMT Exprs. No major changes except moving `areEquivalent` and `getFloatSemantics` outside of `Z3Expr` to keep the class minimal. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49551 llvm-svn: 337917
* [analyzer] Create generic SMT Sort ClassMikhail R. Gadelha2018-07-251-25/+29
| | | | | | | | | | | | | | | | | Summary: New base class for all future SMT sorts. The only change is that the class implements methods `isBooleanSort()`, `isBitvectorSort()` and `isFloatSort()` so it doesn't rely on `Z3`'s enum. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49550 llvm-svn: 337916
* [analyzer] Moved static Context to class memberMikhail R. Gadelha2018-07-251-450/+471
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Although it is a big patch, the changes are simple: 1. There is one `Z3_Context` now, member of the `SMTConstraintManager` class. 2. `Z3Expr`, `Z3Sort`, `Z3Model` and `Z3Solver` are constructed with a reference to the `Z3_Context` in `SMTConstraintManager`. 3. All static functions are now members of `Z3Solver`, e.g, the `SMTConstraintManager` now calls `Solver.fromBoolean(false)` instead of `Z3Expr::fromBoolean(false)`. Most of the patch only move stuff around except: 1. New method `Z3Sort MkSort(const QualType &Ty, unsigned BitWidth)`, that creates a sort based on the `QualType` and its width. Used to simplify the `fromData` method. Unfortunate consequence of this patch: 1. `getInterpretation` was moved from `Z3Model` class to `Z3Solver`, because it needs to create a `Z3Sort` before returning the interpretation. This can be fixed by changing both `toAPFloat` and `toAPSInt` by removing the dependency of `Z3Sort` (it's only used to check which Sort was created and to retrieve the type width). Reviewers: NoQ, george.karpenkov, ddcc Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49236 llvm-svn: 337915
* [analyzer] Create generic SMT Context classMikhail R. Gadelha2018-07-251-6/+10
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch creates `SMTContext` which will wrap a specific SMT context, through `SMTSolverContext`. The templated `SMTSolverContext` class it's a simple wrapper around a SMT specific context (currently only used in the Z3 backend), while `Z3Context` inherits `SMTSolverContext<Z3_context>` and implements solver specific operations like initialization and destruction of the context. This separation was done because: 1. We might want to keep one single context, shared across different `SMTConstraintManager`s. It can be achieved by constructing a `SMTContext`, through a function like `CreateSMTContext(Z3)`, `CreateSMTContext(BOOLECTOR)`, etc. The rest of the CSA only need to know about `SMTContext`, so maybe it's a good idea moving `SMTSolverContext` to a separate header in the future. 2. Any generic SMT operation will only require one `SMTSolverContext`object, which can access the specific context by calling `getContext()`. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49233 llvm-svn: 337914
* [analyzer] Syntactic matcher for leaks associated with run loop and ↵George Karpenkov2018-07-252-0/+218
| | | | | | | | | | | | | | | | | | | | | | | autoreleasepool A checker for detecting leaks resulting from allocating temporary autoreleasing objects before starting the main run loop. Checks for two antipatterns: 1. ObjCMessageExpr followed by [[NARunLoop mainRunLoop] run] in the same autorelease pool. 2. ObjCMessageExpr followed by [[NARunLoop mainRunLoop] run] in no autorelease pool. Happens-before relationship is modeled purely syntactically. rdar://39299145 Differential Revision: https://reviews.llvm.org/D49528 llvm-svn: 337876
* Revert "[analyzer] Extend NoStoreFuncVisitor to insert a note on IVars"George Karpenkov2018-07-241-50/+13
| | | | | | | This reverts commit a9e21bd727112cd69eabc1af648c5da6b773d06e. Reverted because the dependency has not landed yet. llvm-svn: 337866
* [analyzer] Extend NoStoreFuncVisitor to insert a note on IVarsGeorge Karpenkov2018-07-241-13/+50
| | | | | | | | | | | | | | The note is added in the following situation: - We are throwing a nullability-related warning on an IVar - The path goes through a method which *could have* (syntactically determined) written into that IVar, but did not rdar://42444460 Differential Revision: https://reviews.llvm.org/D49689 llvm-svn: 337864
* [analyzer] pr38273: Legalize Loc<>NonLoc comparison symbols.Artem Dergachev2018-07-231-2/+4
| | | | | | | | | Remove an assertion in RangeConstraintManager that expects such symbols to never appear, while admitting that the constraint manager doesn't yet handle them. Differential Revision: https://reviews.llvm.org/D49703 llvm-svn: 337769
* [CStringSyntaxChecker] Improvements of strlcpy checkDavid Carlier2018-07-231-2/+18
| | | | | | | | | | | | Adding an additional check whenwe offset fro the buffer base address. Reviewers: george.karpenkov,NoQ Reviewed By: george.karpenkov Differential Revision: https://reviews.llvm.org/D49633 llvm-svn: 337721
* [Analyzer] Quick Fix for exponential execution time when simpilifying ↵Adam Balogh2018-07-232-9/+12
| | | | | | | | | | | | | | | | | | complex additive expressions Patch https://reviews.llvm.org/rC329780 not only rearranges comparisons but also binary expressions. This latter behavior is not protected by the analyzer option. Hower, since no complexity threshold is enforced to the symbols this may result in exponential execution time if the expressions are too complex: https://bugs.llvm.org/show_bug.cgi?id=38208. For a quick fix we extended the analyzer option to also cover the additive cases. This is only a temporary fix, the final solution should be enforcing the complexity threshold to the symbols. Differential Revision: https://reviews.llvm.org/D49536 llvm-svn: 337678
* [CStringSyntaxChecker] Fix build bot builds != x86 archsDavid Carlier2018-07-201-8/+9
| | | | | | | | | | Reviewers: NoQ,george.karpenkov Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D49588 llvm-svn: 337611
* [analyzer] Rename DanglingInternalBufferChecker to InnerPointerChecker.Reka Kovacs2018-07-204-35/+34
| | | | | | Differential Revision: https://reviews.llvm.org/D49553 llvm-svn: 337559
* Change \t to spacesFangrui Song2018-07-202-2/+2
| | | | llvm-svn: 337530
* [CStringSyntaxChecker] Check strlcpy sizeof syntaxDavid Carlier2018-07-191-0/+62
| | | | | | | | | | | | | | | | | The last argument is expected to be the destination buffer size (or less). Detects if it points to destination buffer size directly or via a variable. Detects if it is an integral, try to detect if the destination buffer can receive the source length. Updating bsd-string.c unit tests as it make it fails now. Reviewers: george.karpenpov, NoQ Reviewed By: george.karpenkov Differential Revision: https://reviews.llvm.org/D48884 llvm-svn: 337499
* [analyzer] Fix memory sanitizer error in MallocChecker.Reka Kovacs2018-07-191-3/+3
| | | | | | | | StringRef's data() returns a string that may be non-null-terminated. Switch to using StringRefs from const char pointers in visitor notes to avoid problems. llvm-svn: 337474
* [analyzer] Memoize complexity of SymExprMikhail R. Gadelha2018-07-192-8/+1
| | | | | | | | | | | | | | | | | Summary: This patch introduces a new member to SymExpr, which stores the symbol complexity, avoiding recalculating it every time computeComplexity() is called. Also, increase the complexity of conjured Symbols by one, so it's clear that it has a greater complexity than its underlying symbols. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ, george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49232 llvm-svn: 337472
* [analyzer] Fix disappearing notes in DanglingInternalBufferChecker testsReka Kovacs2018-07-191-2/+3
| | | | | | Correct a mistake of the exact same kind I am writing this checker for. llvm-svn: 337466
* [analyzer] Add support for more basic_string API inReka Kovacs2018-07-192-11/+71
| | | | | | | | | | | | | DanglingInternalBufferChecker. A pointer referring to the elements of a basic_string may be invalidated by calling a non-const member function, except operator[], at, front, back, begin, rbegin, end, and rend. The checker now warns if the pointer is used after such operations. Differential Revision: https://reviews.llvm.org/D49360 llvm-svn: 337463
* [analyzer] Remove a debug print that was accidentally left around.Artem Dergachev2018-07-181-1/+0
| | | | | | No functional change intended. llvm-svn: 337417
* [analyzer] Fix Z3 backend after D48205Mikhail R. Gadelha2018-07-171-30/+29
| | | | | | | | | | | | | | | | | Summary: An assertion was added in D48205 to catch places where a `nonloc::SymbolVal` was wrapping a `loc` object. This patch fixes that in the Z3 backend by making the `SValBuilder` object accessible from inherited instances of `SimpleConstraintManager` and calling `SVB.makeSymbolVal(foo)` instead of `nonloc::SymbolVal(foo)`. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49430 llvm-svn: 337304
* [analyzer] pr37802: Fix symbolic-pointer-to-boolean casts during load.Artem Dergachev2018-07-171-1/+2
| | | | | | | | | The canonical representation of pointer &SymRegion{$x} casted to boolean is "$x != 0", not "$x". Assertion added in r337227 catches that. Differential Revision: https://reviews.llvm.org/D48232 llvm-svn: 337228
* [analyzer] Assert that nonloc::SymbolVal always wraps a non-Loc-type symbol.Artem Dergachev2018-07-171-1/+1
| | | | | | | | | | | | | | | In the current SVal hierarchy there are multiple ways of representing certain values but few are actually used and expected to be seen by the code. In particular, a value of a symbolic pointer is always represented by a loc::MemRegionVal that wraps a SymbolicRegion that wraps the pointer symbol and never by a nonloc::SymbolVal that wraps that symbol directly. Assert the aforementioned fact. Fix one minor violation of it. Differential Revision: https://reviews.llvm.org/D48205 llvm-svn: 337227
* [analyzer] Make checkEndFunction() give access to the return statement.Reka Kovacs2018-07-1611-21/+28
| | | | | | Differential Revision: https://reviews.llvm.org/D49387 llvm-svn: 337215
* [analyzer] Bugfix for an overly eager suppression for null pointer return ↵George Karpenkov2018-07-161-39/+60
| | | | | | | | | | | | | from macros. Only suppress those cases where the null which came from the macro is relevant to the bug, and was not overwritten in between. rdar://41497323 Differential Revision: https://reviews.llvm.org/D48856 llvm-svn: 337213
OpenPOWER on IntegriCloud