| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
This also includes some infrastructure to make it easier to build multi-argument
selectors, rather than trying to use string matching on each piece. There's a bit
more setup code, but less cost at runtime.
PR18908
llvm-svn: 205827
|
|
|
|
|
|
|
|
|
|
|
|
| |
construct.
Fixes a false positive when temporary destructors are enabled where a temporary
is destroyed after a variable is constructed but before the VarDecl itself is
processed, which occurs when the variable is in the condition of an if or while.
Patch by Alex McCarthy, with an extra test from me.
llvm-svn: 205661
|
|
|
|
|
|
|
|
| |
No functionality change.
Patch by Alex McCarthy!
llvm-svn: 205328
|
|
|
|
|
|
|
|
|
|
| |
If we're trying to get the zero element region of something that's not a region,
we should be returning UnknownVal, which is what ProgramState::getLValue will
do for us.
Patch by Alex McCarthy!
llvm-svn: 205327
|
|
|
|
|
|
|
|
| |
destroyed lock.
Patch by Daniel Fahlgren!
llvm-svn: 205276
|
|
|
|
|
|
| |
Patch by Daniel Fahlgren!
llvm-svn: 205275
|
|
|
|
|
|
|
|
|
| |
We've decided to punt on supporting recursive locks for now; the common case
is non-recursive.
Patch by Daniel Fahlgren!
llvm-svn: 205274
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add M_ZERO awareness to malloc() static analysis in Clang for FreeBSD,
NetBSD, and OpenBSD in a similar fashion to O_CREAT for open(2).
These systems have a three-argument malloc() in the kernel where the
third argument contains flags; the M_ZERO flag will zero-initialize the
allocated buffer.
This should reduce the number of false positives when running static
analysis on BSD kernels.
Additionally, add kmalloc() (Linux kernel malloc()) and treat __GFP_ZERO
like M_ZERO on Linux.
Future work involves a better method of checking for named flags without
hardcoding values.
Patch by Conrad Meyer, with minor modifications by me.
llvm-svn: 204832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A refinement of r198953 to handle cases where an object is accessed both through
a property getter and through direct ivar access. An object accessed through a
property should always be treated as +0, i.e. not owned by the caller. However,
an object accessed through an ivar may be at +0 or at +1, depending on whether
the ivar is a strong reference. Outside of ARC, we don't have that information,
so we just don't track objects accessed through ivars.
With this change, accessing an ivar directly will deliberately override the +0
provided by a getter, but only if the +0 hasn't participated in other retain
counting yet. That isn't perfect, but it's already unusual for people to be
mixing property access with direct ivar access. (The primary use case for this
is in setters, init methods, and -dealloc.)
Thanks to Ted for spotting a few mistakes in private review.
<rdar://problem/16333368>
llvm-svn: 204730
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
found with a smarter version of -Wunused-member-function that I'm playwing with.
Appologies in advance if I removed someone's WIP code.
ARCMigrate/TransProperties.cpp | 8 -----
AST/MicrosoftMangle.cpp | 1
Analysis/AnalysisDeclContext.cpp | 5 ---
Analysis/LiveVariables.cpp | 14 ----------
Index/USRGeneration.cpp | 10 -------
Sema/Sema.cpp | 33 +++++++++++++++++++++---
Sema/SemaChecking.cpp | 3 --
Sema/SemaDecl.cpp | 20 ++------------
StaticAnalyzer/Checkers/GenericTaintChecker.cpp | 1
9 files changed, 34 insertions(+), 61 deletions(-)
llvm-svn: 204561
|
|
|
|
| |
llvm-svn: 204375
|
|
|
|
|
|
| |
one subexpression of BinaryOperator would be explored.
llvm-svn: 204374
|
|
|
|
|
|
| |
class.
llvm-svn: 203999
|
|
|
|
|
|
| |
iterator_range decls(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203947
|
|
|
|
|
|
| |
propimpl_end() with iterator_range property_impls(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203930
|
|
|
|
|
|
| |
protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203863
|
|
|
|
|
|
| |
visible_extensions_end() with iterator_range visible_extensions(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203855
|
|
|
|
|
|
| |
visible_categories_end() with iterator_range visible_categories(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203851
|
|
|
|
|
|
| |
with iterator_range ivars(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203849
|
|
|
|
|
|
|
|
| |
protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
Drive-by fixing some incorrect types where a for loop would be improperly using ObjCInterfaceDecl::protocol_iterator. No functional changes in these cases.
llvm-svn: 203842
|
|
|
|
|
|
| |
instmeth_end() with iterator_range instance_methods(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203839
|
|
|
|
|
|
| |
for clarity.
llvm-svn: 203835
|
|
|
|
|
|
| |
with iterator_range methods(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203832
|
|
|
|
|
|
| |
with iterator_range props(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203830
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Passing a pointer to an uninitialized memory buffer is normally okay,
but if the function is declared to take a pointer-to-const then it's
very unlikely it will be modifying the buffer. In this case the analyzer
should warn that there will likely be a read of uninitialized memory.
This doesn't check all elements of an array, only the first one.
It also doesn't yet check Objective-C methods, only C functions and
C++ methods.
This is controlled by a new check: alpha.core.CallAndMessageUnInitRefArg.
Patch by Per Viberg!
llvm-svn: 203822
|
|
|
|
|
|
| |
iterator_range ctors(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203814
|
|
|
|
|
|
| |
iterator_range bases(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203803
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like the binary operator check of r201702, this actually checks the
condition of every if in a chain against every other condition, an
O(N^2) operation. In most cases N should be small enough to make this
practical, and checking all cases like this makes it much more likely
to catch a copy-paste error within the same series of branches.
Part of IdenticalExprChecker; patch by Daniel Fahlgren!
llvm-svn: 203585
|
|
|
|
| |
llvm-svn: 203507
|
|
|
|
|
|
| |
semantics where appropriate.
llvm-svn: 203477
|
|
|
|
|
|
| |
specific_attr_end() with iterator_range specific_attrs(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203474
|
|
|
|
| |
llvm-svn: 203389
|
|
|
|
|
|
| |
iterator_range fields(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203355
|
|
|
|
|
|
| |
Looks like GCC implements the lambda->function pointer conversion differently.
llvm-svn: 203293
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 203289
|
|
|
|
|
|
| |
This compiles cleanly with lldb/lld/clang-tools-extra/llvm.
llvm-svn: 203279
|
|
|
|
|
|
| |
iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203278
|
|
|
|
|
|
| |
This is a precursor to moving to std::unique_ptr.
llvm-svn: 203275
|
|
|
|
|
|
| |
with iterator_range params(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203255
|
|
|
|
|
|
| |
iterator_range params(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203248
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added an inserter for ArrayRef<SourceRange>, as it is already needed in at least
two places (static analyzer and clang-tidy).
Reviewers: jordan_rose
CC: cfe-commits, gribozavr
Differential Revision: http://llvm-reviews.chandlerc.com/D2984
llvm-svn: 203117
|
|
|
|
| |
llvm-svn: 203077
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 202755
|
|
|
|
| |
llvm-svn: 202639
|
|
|
|
| |
llvm-svn: 202635
|
|
|
|
| |
llvm-svn: 202625
|
|
|
|
| |
llvm-svn: 202611
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 202590
|
|
|
|
|
|
| |
Additional conditions that prevent useful nodes before call from being reclaimed.
llvm-svn: 202553
|
|
|
|
| |
llvm-svn: 202434
|