| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174782 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Separate the checking for the missing invalidation methods into a
separate checker so that it can be turned on/off independently.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174781 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174780 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The new annotation allows having methods that only partially invalidate
IVars and might not be called from the invalidation methods directly
(instead, are guaranteed to be called before the invalidation occurs).
The checker is going to trust the programmer to call the partial
invalidation method before the invalidator.This is common in cases when
partial object tear down happens before the death of the object.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174779 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
body is skipped.
Fixes <rdar://problem/12322528>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174736 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174730 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174680 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The malloc checker will now catch the case when a previously malloc'ed
region is freed, but the pointer passed to free does not point to the
start of the allocated memory. For example:
int *p1 = malloc(sizeof(int));
p1++;
free(p1); // warn
From the "memory.LeakPtrValChanged enhancement to unix.Malloc" entry
in the list of potential checkers.
A patch by Branden Archer!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174678 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The checkPointerEscape callback previously did not specify how a
pointer escaped. This change includes an enum which describes the
different ways a pointer may escape. This enum is passed to the
checkPointerEscape callback when a pointer escapes. If the escape
is due to a function call, the call is passed. This changes
previous behavior where the call is passed as NULL if the escape
was due to indirectly invalidating the region the pointer referenced.
A patch by Branden Archer!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174677 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This patch makes sure that we do not reinitialize static globals when
the function is called more than once along a path. The motivation is
code with initialization patterns that rely on 2 static variables, where
one of them has an initializer while the other does not. Currently, we
reset the static variables with initializers on every visit to the
function along a path.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174676 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a "quick fix".
The underlining issue is that when a const pointer to a struct is passed
into a function, we do not invalidate the pointer fields. This results
in false positives that are common in C++ (since copy constructors are
prevalent). (Silences two llvm false positives.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174468 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a more natural order of evaluation, and it is very important
for visualization in the static analyzer. Within Xcode, the arrows
will not jump from right to left, which looks very visually jarring.
It also provides a more natural location for dataflow-based diagnostics.
Along the way, we found a case in the analyzer diagnostics where we
needed to indicate that a variable was "captured" by a block.
-fsyntax-only timings on sqlite3.c show no visible performance change,
although this is just one test case.
Fixes <rdar://problem/13016513>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(void*)p.
Addresses the false positives similar to the test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174436 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
...again. The problem has not been fixed and our internal buildbot is still
getting hangs.
This reverts r174212, originally applied in r173951, then reverted in r174069.
Will not re-apply until the entire project analyzes successfully on my
local machine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174265 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Inlining these functions is essential for correctness. We often have
cases where we do not inline calls. For example, the shallow mode and
when reanalyzing previously inlined ObjC methods as top level.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174245 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174244 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174243 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
With the optimization in the previous commit, this should be safe again.
Originally applied in r173951, then reverted in r174069.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows us to keep from chaining LazyCompoundVals in cases like this:
CGRect r = CGRectMake(0, 0, 640, 480);
CGRect r2 = r;
CGRect r3 = r2;
Previously we only made this optimization if the struct did not begin with
an aggregate member, to make sure that we weren't picking up an LCV for
the first field of the struct. But since LazyCompoundVals are typed, we can
make that inference directly by comparing types.
This is a pure optimization; the test changes are to guard against possible
future regressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174211 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The Cnt variable is adjusted (incremented) for simplification of
checking logic. The increment should not be stored in the state.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174104 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This matches our behavior for autorelease pools created by +alloc. Some
people like to create autorelease pools in one method and release them
somewhere else.
If you want safe autorelease pool semantics, use the new ARC-compatible
syntax: @autoreleasepool { ... }
<rdar://problem/13121353>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174096 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It's causing hangs on our internal analyzer buildbot. Will restore after
investigating.
This reverts r173951 / baa7ca1142990e1ad6d4e9d2c73adb749ff50789.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174069 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a hack to work around the fact that we don't track extents for our
default bindings:
CGPoint p;
p.x = 0.0;
p.y = 0.0;
rectParam.origin = p;
use(rectParam.size); // warning: uninitialized value in rectParam.size.width
In this case, the default binding for 'p' gets copied into 'rectParam',
because the 'origin' field is at offset 0 within CGRect. From then on,
rectParam's old default binding (in this case a symbol) is lost.
This patch silences the warning by pretending that lazy bindings are never
made from uninitialized memory, but not only is that not true, the original
default binding is still getting overwritten (see FIXME test cases).
The long-term solution is tracked in <rdar://problem/12701038>
PR14765 and <rdar://problem/12875012>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174031 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
positives.
The includeSuffix was only set on the first iteration through the
function, resulting in invalid regions being produced by getLazyBinding
(ex: zoomRegion.y).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174016 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Redefine the shallow mode to inline all functions for which we have a
definite definition (ipa=inlining). However, only inline functions that
are up to 4 basic blocks large and cut the max exploded nodes generated
per top level function in half.
This makes shallow faster and allows us to keep inlining small
functions. For example, we would keep inlining wrapper functions and
constructors/destructors.
With the new shallow, it takes 104s to analyze sqlite3, whereas
the deep mode is 658s and previous shallow is 209s.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173958 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173957 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173956 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thanks Jordan!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173955 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is faster for the analyzer to process than inlining the constructor
and performing a member-wise copy, and it also solves the problem of
warning when a partially-initialized POD struct is copied.
Before:
CGPoint p;
p.x = 0;
CGPoint p2 = p; <-- assigned value is garbage or undefined
After:
CGPoint p;
p.x = 0;
CGPoint p2 = p; // no-warning
This matches our behavior in C, where we don't see a field-by-field copy.
<rdar://problem/12305288>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173951 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When the analyzer sees an initializer, it checks if the initializer
contains a CXXConstructExpr. If so, it trusts that the CXXConstructExpr
does the necessary work to initialize the object, and performs no further
initialization.
This patch looks through any implicit wrapping expressions like
ExprWithCleanups to find the CXXConstructExpr inside.
Fixes PR15070.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173557 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The expression 'a->b.c()' contains a call to the 'c' method of 'a->b'.
We emit an error if 'a' is NULL, but previously didn't actually track
the null value back through the 'a->b' expression, which caused us to
miss important false-positive-suppression cases, including
<rdar://problem/12676053>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173547 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows it to be used in places where the interesting statement
doesn't match up with the current node. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173546 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This should be used for testing only. Path pruning is still on by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173545 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
"Prune" is the term for eliminating pieces of a path that are not
relevant to the user. "Suppress" means don't show that path at all.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173544 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The idea is to introduce a higher level "user mode" option for
different use scenarios. For example, if one wants to run the analyzer
for a small project each time the code is built, they would use
the "shallow" mode.
The user mode option will influence the default settings for the
lower-level analyzer options. For now, this just influences the ipa
modes, but we plan to find more optimal settings for them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173386 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173385 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173384 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173292 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This isn't likely a full solution, but it catches the common cases
and can be refined over time.
Fixes <rdar://problem/11634353>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173291 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Before:
struct Wrapper { <-- 2. Calling default constructor for 'NonTrivial'.
NonTrivial m;
};
Wrapper w; <-- 1. Calling implicit default constructor for 'Wrapper'.
After:
struct Wrapper {
NonTrivial m;
};
Wrapper w; <-- 1. Calling implicit default constructor for 'Wrapper'.
^-- 2. Calling default constructor for 'NonTrivial'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173067 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
OpenCL restrictions (OpenCL 1.2 spec 6.9)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172973 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Before:
Calling implicit default constructor for 'Foo' (where Foo is constructed)
Entered call from 'test' (at "=default" or 'Foo' declaration)
Calling default constructor for 'Bar' (at "=default" or 'Foo' declaration)
After:
Calling implicit default constructor for 'Foo' (where Foo is constructed)
Calling default constructor for 'Bar' (at "=default" or 'Foo' declaration)
This only affects the plist diagnostics; this note is never shown in the
other diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172915 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Suppress the warning by just not emitting the report. The sink node
would get generated, which is fine since we did reach a bad state.
Motivation
Due to the way code is structured in some of these macros, we do not
reason correctly about it and report false positives. Specifically, the
following loop reports a use-after-free. Because of the way the code is
structured inside of the macro, the analyzer assumes that the list can
have cycles, so you end up with use-after-free in the loop, that is
safely deleting elements of the list. (The user does not have a way to
teach the analyzer about shape of data structures.)
SLIST_FOREACH_SAFE(item, &ctx->example_list, example_le, tmpitem) {
if (item->index == 3) { // if you remove each time, no complaints
assert((&ctx->example_list)->slh_first == item);
SLIST_REMOVE(&ctx->example_list, item, example_s, example_le);
free(item);
}
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172883 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Examples:
Calling implicit default constructor for Foo
Calling defaulted move constructor for Foo
Calling copy constructor for Foo
Calling implicit destructor for Foo
Calling defaulted move assignment operator for Foo
Calling copy assignment operator for Foo
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172833 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Examples:
Calling constructor for 'Foo'
Entered call from 'Foo::create'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172832 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172766 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it apart from [[gnu::noreturn]] / __attribute__((noreturn)), since their
semantics are not equivalent (for instance, we treat [[gnu::noreturn]] as
affecting the function type, whereas [[noreturn]] does not).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172691 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
consider (sub)module visibility.
The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:
visible_categories_iterator: Iterates over all visible categories
and extensions, hiding any that have their "hidden" bit set. This is
by far the most commonly used iterator.
known_categories_iterator: Iterates over all categories and
extensions, ignoring the "hidden" bit. This tends to be used for
redeclaration-like traversals.
visible_extensions_iterator: Iterates over all visible extensions,
hiding any that have their "hidden" bit set.
known_extensions_iterator: Iterates over all extensions, whether
they are visible to normal name lookup or not.
The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.
Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.
Part two of <rdar://problem/10634711>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172665 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
assignment
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172597 91177308-0d34-0410-b5e6-96231b3b80d8
|
