| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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.)
llvm-svn: 174468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 174447
|
|
|
|
|
|
|
|
| |
(void*)p.
Addresses the false positives similar to the test case.
llvm-svn: 174436
|
|
|
|
|
|
|
|
|
|
|
| |
...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.
llvm-svn: 174265
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 174245
|
|
|
|
| |
llvm-svn: 174244
|
|
|
|
| |
llvm-svn: 174243
|
|
|
|
|
|
|
|
| |
With the optimization in the previous commit, this should be safe again.
Originally applied in r173951, then reverted in r174069.
llvm-svn: 174212
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 174211
|
|
|
|
|
|
|
| |
The Cnt variable is adjusted (incremented) for simplification of
checking logic. The increment should not be stored in the state.
llvm-svn: 174104
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 174096
|
|
|
|
|
|
|
|
|
| |
It's causing hangs on our internal analyzer buildbot. Will restore after
investigating.
This reverts r173951 / baa7ca1142990e1ad6d4e9d2c73adb749ff50789.
llvm-svn: 174069
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 174031
|
|
|
|
|
|
|
|
|
|
| |
positives.
The includeSuffix was only set on the first iteration through the
function, resulting in invalid regions being produced by getLazyBinding
(ex: zoomRegion.y).
llvm-svn: 174016
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 173958
|
|
|
|
| |
llvm-svn: 173957
|
|
|
|
| |
llvm-svn: 173956
|
|
|
|
|
|
| |
Thanks Jordan!
llvm-svn: 173955
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 173951
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 173557
|
|
|
|
|
|
|
|
|
|
| |
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>.
llvm-svn: 173547
|
|
|
|
|
|
|
| |
This allows it to be used in places where the interesting statement
doesn't match up with the current node. No functionality change.
llvm-svn: 173546
|
|
|
|
|
|
| |
This should be used for testing only. Path pruning is still on by default.
llvm-svn: 173545
|
|
|
|
|
|
|
| |
"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.
llvm-svn: 173544
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 173386
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 173385
|
|
|
|
| |
llvm-svn: 173384
|
|
|
|
| |
llvm-svn: 173292
|
|
|
|
|
|
|
|
|
| |
This isn't likely a full solution, but it catches the common cases
and can be refined over time.
Fixes <rdar://problem/11634353>.
llvm-svn: 173291
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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'.
llvm-svn: 173067
|
|
|
|
|
|
| |
OpenCL restrictions (OpenCL 1.2 spec 6.9)
llvm-svn: 172973
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 172915
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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);
}
}
llvm-svn: 172883
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 172833
|
|
|
|
|
|
|
|
| |
Examples:
Calling constructor for 'Foo'
Entered call from 'Foo::create'
llvm-svn: 172832
|
|
|
|
| |
llvm-svn: 172766
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 172691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
llvm-svn: 172665
|
|
|
|
|
|
| |
assignment
llvm-svn: 172597
|
|
|
|
| |
llvm-svn: 172596
|
|
|
|
| |
llvm-svn: 172595
|
|
|
|
|
|
| |
Properly use const_cast to fix a cast-away-const error.
llvm-svn: 172561
|
|
|
|
|
|
| |
This should fix cast-away-const warnings reported by David Greene.
llvm-svn: 172446
|
|
|
|
|
|
|
|
|
|
|
| |
This was previously added to support -[NSAutoreleasePool drain], which
behaves like -release under non-GC and "please collect" under GC. We're
not currently modeling the autorelease pool stack, though, so we can
just take this out entirely.
Fixes PR14927.
llvm-svn: 172444
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
| |
Fixes PR 14634 and <rdar://problem/12903080>.
llvm-svn: 172274
|
|
|
|
|
|
|
| |
Fixes assertion failure reported in PR 14635 and
<rdar://problem/12902945> respectively.
llvm-svn: 172263
|
|
|
|
|
|
| |
can be fixed
llvm-svn: 172170
|
|
|
|
|
|
| |
This will get rid of some false positives as well as false negatives.
llvm-svn: 172169
|
|
|
|
| |
llvm-svn: 172168
|