| Age | Commit message (Collapse) | Author |
|---|
|
Some implicit statements, such as the implicit 'self' inserted for "free"
Objective-C ivar access, have invalid source locations. If one of these
statements is the location where an issue is reported, we'll now look at
the enclosing statements for a valid source location.
<rdar://problem/12446776>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165354 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In C++, overriding virtual methods are allowed to specify a covariant
return type -- that is, if the return type of the base method is an
object pointer type (or reference type), the overriding method's return
type can be a pointer to a subclass of the original type. The analyzer
was failing to take this into account when devirtualizing a method call,
and anything that relied on the return value having the proper type later
would crash.
In Objective-C, overriding methods are allowed to specify ANY return type,
meaning we can NEVER be sure that devirtualizing will give us a "safe"
return value. Of course, a program that does this will most likely crash
at runtime, but the analyzer at least shouldn't crash.
The solution is to check and see if the function/method being inlined is
the function that static binding would have picked. If not, check that
the return value has the same type. If the types don't match, see if we
can fix it with a derived-to-base cast (the C++ case). If we can't,
return UnknownVal to avoid crashing later.
<rdar://problem/12409977>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165079 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These functions are store-agnostic, and would benefit from information in
DynamicTypeInfo but gain nothing from the store type.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165078 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Then, rename it getPointeeCXXRecordDecl and give it a nice doc comment,
and actually use it.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165077 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165059 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
an intermediate helper method to query and populate the Optional value.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165043 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
table, making it printable with the ConfigDump checker. Along the
way, fix a really serious bug where the value was getting parsed
from the string in code that was in an assert() call. This means
in a Release-Asserts build this code wouldn't work as expected.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the config string table. Also setup a test for dumping the analyzer
configuration for C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
By analogy with C structs, this seems to be legal, if probably discouraged.
It's only if the ivar is read from or written to that there's a problem.
Running a program that gets the "address" of an instance variable does in
fact return the offset when the base "object" is nil.
This isn't a full revert because r164442 includes some diagnostic tweaks
as well; those have been kept.
This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164960 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
an lvalue."
The original intent of this commit was to catch potential null dereferences
early, but it breaks the common "home-grown offsetof" idiom (PR13927):
(((struct Foo *)0)->member - ((struct foo *)0))
As it turns out, this appears to be legal in C, per a footnote in
C11 6.5.3.2: "Thus, &*E is equivalent to E (even if E is a null pointer)".
In C++ this issue is still open:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232
We'll just have to make sure we have good path notes in the future.
This reverts r164441 / 9be016dcd1ca3986873a7b66bd4bc027309ceb59.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164958 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
string in the config table so that it can be dumped as part of the
config dumper. Add a test to show that these options are sticking
and can be cross-checked using FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164954 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
correctly."
This is related to but not blocked by <rdar://problem/12137950>
("Return-by-value structs do not have associated regions")
This reverts r164875 / 3278d41e17749dbedb204a81ef373499f10251d7.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164952 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It is possible and valid to have a state manager and associated objects
without having a SubEngine or checkers.
Patch by Olaf Krzikalla!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164947 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
accessing fields"
This reverts commit 6f61df3e7256413dcb99afb9673f4206e3c4992c.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rvalue."
This reverts commit 0006ba445962621ed82ec84400a6b978205a3fbc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164876 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
correctly."
This reverts commit 580cd17f256259f39a382e967173f34d68e73859.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously the analyzer treated all inlined constructors like lvalues,
setting the value of the CXXConstructExpr to the newly-constructed
region. However, some CXXConstructExprs behave like rvalues -- in
particular, the implicit copy constructor into a pass-by-value argument.
In this case, we want only the /contents/ of a temporary object to be
passed, so that we can use the same "copy each argument into the
parameter region" algorithm that we use for scalar arguments.
This may change when we start modeling destructors of temporaries,
but for now this is the last part of <rdar://problem/12137950>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164830 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
An rvalue has no address, but calling a C++ member function requires a
'this' pointer. This commit makes the analyzer create a temporary region
in which to store the struct rvalue and use as a 'this' pointer whenever
a member function is called on an rvalue, which is essentially what
CodeGen does.
More of <rdar://problem/12137950>. The last part is tracking down the
C++ FIXME in array-struct-region.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164829 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Struct rvalues are represented in the analyzer by CompoundVals,
LazyCompoundVals, or plain ConjuredSymbols -- none of which have associated
regions. If the entire structure is going to persist, this is not a
problem -- either the rvalue will be assigned to an existing region, or
a MaterializeTemporaryExpr will be present to create a temporary region.
However, if we just need a field from the struct, we need to create the
temporary region ourselves.
This is inspired by the way CodeGen handles calls to temporaries;
support for that in the analyzer is coming next.
Part of <rdar://problem/12137950>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164828 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This isn't correct, as Jordan correctly points out.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164711 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164709 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164661 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
removeDeadBindings."
Previously, we'd just keep constraints around forever, which means we'd
never be able to merge paths that differed only in constraints on dead
symbols.
Because we now allow constraints on symbolic expressions, not just single
symbols, this requires changing SymExpr::symbol_iterator to include
intermediate symbol nodes in its traversal, not just the SymbolData leaf
nodes.
This depends on the previous commit to be correct. Originally applied in
r163444, reverted in r164275, now being re-applied.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164622 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No tests, but this allows the optimization of removing dead constraints.
We can then add tests that we don't do this prematurely.
<rdar://problem/12333297>
Note: the added FIXME to investigate SymbolRegionValue liveness is
tracked by <rdar://problem/12368183>. This patch does not change the
existing behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164621 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(Unfortunately, I do not have a good reduced test case for this.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164541 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a heuristic intended to greatly reduce the number of false
positives resulting from inlining, particularly inlining of generic,
defensive C++ methods that live in header files. The suppression is
triggered in the cases where we ask to track where a null pointer came
from, and it turns out that the source of the null pointer was an inlined
function call.
This change brings the number of bug reports in LLVM from ~1500 down to
around ~300, a much more manageable number. Yes, some true positives may
be hidden as well, but from what I looked at the vast majority of silenced
reports are false positives, and many of the true issues found by the
analyzer are still reported.
I'm hoping to improve this heuristic further by adding some exceptions
next week (cases in which a bug should still be reported).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164449 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also, tidy up the other tracking visitors so that they mark the right
things as interesting and don't do extra work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164448 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Before, PathDiagnosticConsumers that did not support actual path output
would (sensibly) cause the generation of the full path to be skipped.
However, BugReporterVisitors may want to see the path in order to mark a
BugReport as invalid.
Now, even for a path generation scheme of 'None' we will still create a
trimmed graph and walk backwards through the bug path, doing no work other
than passing the nodes to the BugReporterVisitors. This isn't cheap, but
it's necessary to properly do suppression when the first path consumer does
not support path notes.
In the future, we should try only generating the path and visitor-provided
path notes once, or at least only creating the trimmed graph once.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164447 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is intended to allow visitors to make decisions about whether a
BugReport is likely a false positive. Currently there are no visitors
making use of this feature, so there are no tests.
When a BugReport is marked invalid, the invalidator must provide a key
that identifies the invaliation (intended to be the visitor type and a
context pointer of some kind). This allows us to reverse the decision
later on. Being able to reverse a decision about invalidation gives us more
flexibility, and allows us to formulate conditions like "this report is
invalid UNLESS the original argument is 'foo'". We can use this to
fine-tune our false-positive suppression (coming soon).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164446 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows us to show /why/ a particular object is nil, even when it is
wrapped in an OpaqueValueExpr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164445 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Rather than saying "Null pointer value stored to 'foo'", we now say
"Passing null pointer value via Nth parameter 'foo'", which is much better.
The note is also now on the argument expression as well, rather than the
entire call.
This paves the way for continuing to track arguments back to their sources.
<rdar://problem/12211490>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164444 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Just a refactoring of common infrastructure. No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164443 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Like with struct fields, we want to catch cases like this early,
so that we can produce better diagnostics and path notes:
PointObj *p = nil;
int *px = &p->_x; // should warn here
*px = 1;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164442 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We want to catch cases like this early, so that we can produce better
diagnostics and path notes:
Point *p = 0;
int *px = &p->x; // should warn here
*px = 1;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164441 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Try this again, now that r164392 is in place.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164393 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
out bugs."
It crashed test/Analysis/Output/blocks.m on some hosts.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164368 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164364 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164363 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
when
their implementations are unavailable. Start by simulating dispatch_sync().
This change is largely a bunch of plumbing around something very simple. We
use AnalysisDeclContext to conjure up a fake function body (using the
current ASTContext) when one does not exist. This is controlled
under the analyzer-config option "faux-bodies", which is off by default.
The plumbing in this patch is largely to pass the necessary machinery
around. CallEvent needs the AnalysisDeclContextManager to get
the function definition, as one may get conjured up lazily.
BugReporter and PathDiagnosticLocation needed to be relaxed to handle
invalid locations, as the conjured body has no real source locations.
We do some primitive recovery in diagnostic generation to generate
some reasonable locations (for arrows and events), but it can be
improved.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164339 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
removeDeadBindings."
While we definitely want this optimization in the future, we're not
currently handling constraints on symbolic /expressions/ correctly.
These should stay live even if the SymExpr itself is no longer referenced
because could recreate an identical SymExpr later. Only once the SymExpr
can no longer be recreated -- i.e. a component symbol is dead -- can we
safely remove the constraints on it.
This liveness issue is tracked by <rdar://problem/12333297>.
This reverts r163444 / 24c7f98828e039005cff3bd847e7ab404a6a09f8.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164275 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in ObjCMethods.
Extend FunctionTextRegion to represent ObjC methods as well as
functions. Note, it is not clear what type ObjCMethod region should
return. Since the type of the FunctionText region is not currently used,
defer solving this issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164046 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thanks Jordan.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163762 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in NSException to a helper object in libAnalysis that can also
be used by Sema. Not sure if the predicate name 'isImplicitNoReturn'
is the best one, but we can massage that later.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163759 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
type is void.
Fixes a false positive found by analyzing LLVM code base.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163748 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Again, GCC is more aggressive about reusing temporary space than we are,
leading to Release build crashes for this undefined behavior.
PR13710 (though it may not be the only problem there)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163747 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Currently we don't update the dynamic type of a C++ object when it is
cast. This can cause the situation above, where the static type of the
region is now known to be a subclass of the dynamic type.
Once we start updating DynamicTypeInfo in response to the various kinds
of casts in C++, we can re-add this assert to make sure we don't miss
any cases. This work is tracked by <rdar://problem/12287087>.
In -Asserts builds, we will simply not return any runtime definition
when our DynamicTypeInfo is known to be incorrect like this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163745 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
type is worse."
Using the static type may be inconsistent with later calls. We should just
report that there is no inlining definition available if the static type is
better than the dynamic type. See next commit.
This reverts r163644 / 19d5886d1704e24282c86217b09d5c6d35ba604d.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163744 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
were not emitted.
Fixes <rdar://problem/12280665>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163683 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parameter packs where the reference is not being expanded but the pack has
been. Previously, Clang would segfault in such cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163672 91177308-0d34-0410-b5e6-96231b3b80d8
|
