| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
The constructor that comes right before a variable declaration in the CFG might
not be the initialization of that variable. Previously, we just checked that
the variable's initializer expression was different from the construction
expression, but forgot to see whether the variable had an initializer expression
at all.
Thanks for the prompting, David.
llvm-svn: 207562
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While we don't model pointer-to-member operators yet (neither .* nor ->*),
CallAndMessageChecker still checks to make sure the 'this' object is not
null or undefined first. However, it also expects that the object should
always have a valid MemRegion, something that's generally important elsewhere
in the analyzer as well. Ensure this is true ahead of time, just like we do
for member access.
PR19531
llvm-svn: 207561
|
|
|
|
|
|
|
|
|
|
| |
variable.
This could happen due to unfortunate CFG coincidences.
PR19579
llvm-svn: 207486
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Thanks, Alex!
llvm-svn: 205720
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
at ... )')
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Also, add several destructor-related tests. Most of them don't work yet, but it's
good to have them recorded.
Patch by Alex McCarthy!
llvm-svn: 205326
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
when a class adopts a protocol that inherits from
undefined protocols. // rdar://16111182
llvm-svn: 203586
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
terminators.
llvm-svn: 203335
|
|
|
|
|
|
|
| |
Some files had CRLF line terminators, some only had a mixture of
CRLF and LF. Switch to LF.
llvm-svn: 202659
|
|
|
|
|
|
| |
Additional conditions that prevent useful nodes before call from being reclaimed.
llvm-svn: 202553
|
|
|
|
|
|
| |
cases.
llvm-svn: 202435
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
null comparison when the pointer is known to be non-null.
This catches the array to pointer decay, function to pointer decay and
address of variables. This does not catch address of function since this
has been previously used to silence a warning.
Pointer to bool conversion is under -Wbool-conversion.
Pointer to null comparison is under -Wtautological-pointer-compare, a sub-group
of -Wtautological-compare.
void foo() {
int arr[5];
int x;
// warn on these conditionals
if (foo);
if (arr);
if (&x);
if (foo == null);
if (arr == null);
if (&x == null);
if (&foo); // no warning
}
llvm-svn: 202216
|
|
|
|
|
|
|
|
|
| |
For now, just ignore them. Later, we could try looking through LazyCompoundVals,
but we at least shouldn't crash.
<rdar://problem/16153464>
llvm-svn: 202212
|
|
|
|
|
|
| |
There were many additional tests that had the bad behavior baked in.
llvm-svn: 202174
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D2711
llvm-svn: 201926
|
|
|
|
|
|
|
|
|
| |
Somehow both Daniel and I missed the fact that while loops are only identical
if they have identical bodies.
Patch by Daniel Fahlgren!
llvm-svn: 201829
|
|
|
|
|
|
|
|
|
|
|
| |
IdenticalExprChecker now warns if any expressions in a logical or bitwise
chain (&&, ||, &, |, or ^) are the same. Unlike the previous patch, this
actually checks all subexpressions against each other (an O(N^2) operation,
but N is likely to be small).
Patch by Daniel Fahlgren!
llvm-svn: 201702
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extends the checks for identical expressions to handle identical
statements, and compares the consequent and alternative ("then" and "else")
branches of an if-statement to see if they are identical, treating a single
statement surrounded by braces as equivalent to one without braces.
This does /not/ check subsequent branches in an if/else chain, let alone
branches that are not consecutive. This may improve in a future patch, but
it would certainly take more work.
Patch by Daniel Fahlgren!
llvm-svn: 201701
|
|
|
|
| |
llvm-svn: 201640
|
|
|
|
|
|
|
|
|
| |
...as well as fake flexible array members: structs that end in arrays with
length 0 or 1.
Patch by Daniel Fahlgren!
llvm-svn: 201583
|
|
|
|
| |
llvm-svn: 201478
|
|
|
|
|
|
|
|
|
| |
This will let us stage in the modeling of operator new. The -analyzer-config
opton 'c++-inline-allocators' is currently off by default.
Patch by Karthik Bhat!
llvm-svn: 201122
|
|
|
|
|
|
| |
<rdar://problem/15999214>
llvm-svn: 201007
|
|
|
|
|
|
|
|
|
| |
This means always walking the whole call stack for the end path node, but
we'll assume that's always fairly tractable.
<rdar://problem/15952973>
llvm-svn: 200980
|
|
|
|
|
|
|
|
| |
redeclaration, not just when looking them up for a use -- we need the implicit
declaration to appropriately check various properties of them (notably, whether
they're deleted).
llvm-svn: 200729
|
|
|
|
|
|
|
|
|
| |
cast into a boolean true value. This warning will catch code like:
if (@0) {}
if (@"foo") {}
llvm-svn: 200356
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to statement expressions supported as GCC extension, it is possible
to put 'break' or 'continue' into a loop/switch statement but outside
its body, for example:
for ( ; ({ if (first) { first = 0; continue; } 0; }); )
This code is rejected by GCC if compiled in C mode but is accepted in C++
code. GCC bug 44715 tracks this discrepancy. Clang used code generation
that differs from GCC in both modes: only statement of the third
expression of 'for' behaves as if it was inside loop body.
This change makes code generation more close to GCC, considering 'break'
or 'continue' statement in condition and increment expressions of a
loop as it was inside the loop body. It also adds error for the cases
when 'break'/'continue' appear outside loop due to this syntax. If
code generation differ from GCC, warning is issued.
Differential Revision: http://llvm-reviews.chandlerc.com/D2518
llvm-svn: 199897
|
|
|
|
|
|
|
|
|
|
|
| |
If there are non-trivially-copyable types /other/ than C++ records, we
won't have a synthesized copy expression, but we can't just use a simple
load/return.
Also, add comments and shore up tests, making sure to test in both ARC
and non-ARC.
llvm-svn: 199869
|
|
|
|
| |
llvm-svn: 199473
|
|
|
|
|
|
|
|
|
| |
Citation: C++11 [expr.shift]p1 (and the equivalent text in C11).
This fixes PR18073, but the right thing to do (as noted in the FIXME) is to
have a real checker for too-large shifts.
llvm-svn: 199405
|
|
|
|
|
|
|
|
| |
This allows us to use CHECK-LABEL to ensure that we're checking the right CFG.
Debugging change only.
llvm-svn: 199320
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test the CC1 layer.
This actually uncovered that the test semes to no longer be passing for
the reasons intended. =[ The name of the test would lead me to believe
that it should be testing the semantics of noreturn in the static
analyzer.... but there are in fact no -verify assertions about noreturn
that i can find. And the noreturn checker is no longer in 'alpha.core'.
It is in 'core.builtins'. The test *does* have one assertion for a null
dereference warning. This *also* isn't in 'alpha.core', but the driver
inserts a pile of other checker packages, including 'core' which has
this warning.
So I have switch the RUN line to actually do the minimal thing that this
test currently exercises, but someone who works on the static analyzer
should probably look at this and either nuke it or move it to actually
check the noreturn behavior.
llvm-svn: 199307
|
|
|
|
| |
llvm-svn: 199277
|
|
|
|
|
|
| |
PR18472
llvm-svn: 199227
|
|
|
|
|
|
|
| |
This allows the analyzer to handle properties with C++ class type,
finishing up the FIXME from r198953.
llvm-svn: 199226
|
|
|
|
|
|
|
|
|
|
| |
In preparation for making the Win32 triple imply MS ABI mode,
make all tests pass in this mode, or make them use the Itanium
mode explicitly.
Differential Revision: http://llvm-reviews.chandlerc.com/D2401
llvm-svn: 199130
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an expression like "new (a, b) Foo(x, y)", two things happen:
- Memory is allocated by calling a function named 'operator new'.
- The memory is initialized using the constructor for 'Foo'.
Currently the analyzer only models the second event, though it has special
cases for both the default and placement forms of operator new. This patch
is the first step towards properly modeling both events: it changes the CFG
so that the above expression now generates the following elements.
1. a
2. b
3. (CFGNewAllocator)
4. x
5. y
6. Foo::Foo
The analyzer currently ignores the CFGNewAllocator element, but the next
step is to treat that as a call like any other.
The CFGNewAllocator element is not added to the CFG for analysis-based
warnings, since none of them take advantage of it yet.
llvm-svn: 199123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...by synthesizing their body to be "return self->_prop;", with an extra
nudge to RetainCountChecker to still treat the value as +0 if we have no
other information.
This doesn't handle weak properties, but that's mostly correct anyway,
since they can go to nil at any time. This also doesn't apply to properties
whose implementations we can't see, since they may not be backed by an
ivar at all. And finally, this doesn't handle properties of C++ class type,
because we can't invoke the copy constructor. (Sema has actually done this
work already, but the AST it synthesizes is one the analyzer doesn't quite
handle -- it has an rvalue DeclRefExpr.)
Modeling setters is likely to be more difficult (since it requires
handling strong/copy), but not impossible.
<rdar://problem/11956898>
llvm-svn: 198953
|
|
|
|
| |
llvm-svn: 198820
|
|
|
|
|
|
|
|
|
|
| |
...rather somewhere in the destructor when we try to access something and
realize the object has already been deleted. This is necessary because
the destructor is processed before the 'delete' itself.
Patch by Karthik Bhat!
llvm-svn: 198779
|