| Age | Commit message (Collapse) | Author |
|---|
|
<rdar://problem/12759044>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168843 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
initializer.
The stop-gap here is to just drop such objects when processing the InitListExpr.
We still need a better solution.
Fixes <rdar://problem/12755044>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168757 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This was also covered by <rdar://problem/12753384>. The static analyzer
evaluates a CXXConstructExpr within an initializer expression and
RegionStore doesn't know how to handle the resulting CXXTempObjectRegion
that gets created. We need a better solution than just dropping the
value, but we need to better understand how to implement the right
semantics here.
Thanks to Jordan for his help diagnosing the behavior here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168741 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thanks for the original catch in r168303, Takumi.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168671 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The AllocaRegion did not have the superRegion (based on LocationContext)
as part of it's hash. As a consequence, the AllocaRegions from
different frames were uniqued to be the same region.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168599 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168303 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This fixes a few cases where we'd emit path notes like this:
+---+
1| v
p = malloc(len);
^ |2
+---+
In general this should make path notes more consistent and more correct,
especially in cases where the leak happens on the false branch of an if
that jumps directly to the end of the function. There are a couple places
where the leak is reported farther away from the cause; these are usually
cases where there are several levels of nested braces before the end of
the function. This still matches our current behavior for when there /is/
a statement after all the braces, though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168070 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows us to properly remove dead bindings at the end of the top-level
stack frame, using the ReturnStmt, if there is one, to keep the return value
live. This in turn removes the need for a check::EndPath callback in leak
checkers.
This does cause some changes in the path notes for leak checkers. Previously,
a leak would be reported at the location of the closing brace in a function.
Now, it gets reported at the last statement. This matches the way leaks are
currently reported for inlined functions, but is less than ideal for both.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168066 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168020 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We do this by using the "most recent" good location: if a synthesized
function 'A' calls another function 'B', the path notes for the call to 'B'
will be placed at the same location as the path note for calling 'A'.
Similarly, the call to 'A' will have a note saying "Entered call from...",
and now we just don't emit that (since the user doesn't have a body to look
at anyway).
Previously, we were doing this for the "Calling..." notes, but not for the
"Entered call from..." or "Returning to caller". This caused a crash when
the path entered and then exiting a call within a synthesized body.
<rdar://problem/12657843>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168019 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167995 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is also a false-positive test case for <rdar://problem/12415065>.
<rdar://problem/12687586>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167994 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
type conversion between integers. This allows the warning to be more accurate.
Also, turned the warning off in an analyzer test. The relavent test cases
are covered by the tests in Sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167992 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This simplifies logic, fixes a bug, and adds a test case.
Thanks Jordan!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167868 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
tricky.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167814 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and other functions.
When these functions return null, the pointer is not freed by
them/ownership is not transfered. So we should allow the user to free
the pointer by calling another function when the return value is NULL.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167813 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This code assigned the last created CFGBlock* to the variable 'Block',
which is a scratch variable which is null'ed out after a block is
completed. By assigning the last created block to 'Block', we start
editing a completed block, inserting CFGStmts that should be in
another block. This was the case with 'try'. The test case that
showed this had a while loop inside a 'try', and the logic before
the while loop was being included as part of the "condition block"
for the loop. This showed up as a bogus dead store, but could
have lots of implications.
Turns out this bug was replicated a few times within CFG.cpp, so
I went and fixed up those as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167788 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
conditions.
The adjustment is needed only in case of dynamic dispatch performed by
the analyzer - when the runtime declaration is different from the static
one.
Document this explicitly in the code (by adding a helper). Also, use
canonical Decls to avoid matching against the case where the definition
is different from found declaration.
This fix suppresses the testcase I added in r167762, so add another
testcase to make sure we do test commit r167762.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167780 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Suppresses a leak false positive (radar://12663777).
In addition, we'll need to rewrite the adjustReturnValue() method not to
return UnknownVal by default, but rather assert in cases we cannot
handle. To make it possible, we need to correctly handle some of the
edge cases we already know about.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167762 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, RegionStore was being VERY conservative in saying that because
p[i].x and p[i].y have a concrete base region of 'p', they might overlap.
Now, we check the chain of fields back up to the base object and check if
they match.
This only kicks in when dealing with symbolic offset regions because
RegionStore's "base+offset" representation of concrete offset regions loses
all information about fields. In cases where all offsets are concrete
(s.x and s.y), RegionStore will already do the right thing, but mixing
concrete and symbolic offsets can cause bindings to be invalidated that
are known to not overlap (e.g. p[0].x and p[i].y).
This additional refinement is tracked by <rdar://problem/12676180>.
<rdar://problem/12530149>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167654 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Sean McBride!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167537 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167439 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This will simplify checkers that need to register for leaks. Currently,
they have to register for both: check dead and check end of path.
I've modified the SymbolReaper to consider everything on the stack dead
if the input StackLocationContext is 0.
(This is a bit disruptive, so I'd like to flash out all the issues
asap.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167352 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167099 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
IdentifierInfo.
Ee: C++ copy constructors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167092 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Sean McBride!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166995 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a syntactic checker aimed at helping iOS programmers correctly
subclass and override the methods of UIViewController. While this should
eventually be covered by the 'objc_requires_super' attribute, this
checker can be used with the existing iOS SDKs without any header changes.
This new checker is currently named 'alpha.osx.cocoa.MissingSuperCall'.
Patch by Julian Mayer!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166993 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is an example checker for catching fopen fclose API misuses.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166976 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Our one basic suppression heuristic is to assume that functions do not
usually return NULL. However, when one of the arguments is NULL it is
suddenly much more likely that NULL is a valid return value. In this case,
we don't suppress the report here, but we do attach /another/ visitor to
go find out if this NULL argument also comes from an inlined function's
error path.
This new behavior, controlled by the 'avoid-suppressing-null-argument-paths'
analyzer-config option, is turned off by default. Turning it on produced
two false positives and no new true positives when running over LLVM/Clang.
This is one of the possible refinements to our suppression heuristics.
<rdar://problem/12350829>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166941 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Additionally, don't collect PostStore nodes -- they are often used in
path diagnostics.
Previously, we tried to track null arguments in the same way as any other
null values, but in many cases the necessary nodes had already been
collected (a memory optimization in ExplodedGraph). Now, we fall back to
using the value of the argument at the time of the call, which may not
always match the actual contents of the region, but often will.
This is a precursor to improving our suppression heuristic.
<rdar://problem/12350829>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166940 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
path notes for cases where a value may be assumed to be null, etc.
Instead of having redundant diagnostics, do a pass over the generated
PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor
that are already covered by ConditionBRVisitor, whose notes tend
to be better.
Fixes <rdar://problem/12252783>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166728 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(so that it can have additional options set when trying to debug issues causing regressions).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166681 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This caused assertion failures analyzing LLVM.
<rdar://problem/12560282>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166529 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
After every 1000 CFGElements processed, the ExplodedGraph trims out nodes
that satisfy a number of criteria for being "boring" (single predecessor,
single successor, and more). Rather than controlling this with a cc1 option,
which can only disable this behavior, we now have an analyzer-config option,
'graph-trim-interval', which can change this interval from 1000 to something
else. Setting the value to 0 disables reclamation.
The next commit relies on this behavior to actually test anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166528 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is actually required by the C++ standard in
[basic.stc.dynamic.allocation]p3:
If an allocation function declared with a non-throwing
exception-specification fails to allocate storage, it shall return a
null pointer. Any other allocation function that fails to allocate
storage shall indicate failure only by throwing an exception of a type
that would match a handler of type std::bad_alloc.
We don't bother checking for the specific exception type, but just go off
the operator new prototype. This should help with a certain class of lazy
initalization false positives.
<rdar://problem/12115221>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166363 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166280 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166211 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This actually looks through several kinds of expression, such as
OpaqueValueExpr and ExprWithCleanups. The idea is that binding and lookup
should be consistent, and so if the environment needs to be modified later,
the code doing the modification will not have to manually look through these
"transparent" expressions to find the real binding to change.
This is necessary for proper updating of struct rvalues as described in
the previous commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166121 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In C++, rvalues that need to have their address taken (for example, to be
passed to a function by const reference) will be wrapped in a
MaterializeTemporaryExpr, which lets CodeGen know to create a temporary
region to store this value. However, MaterializeTemporaryExprs are /not/
created when a method is called on an rvalue struct, even though the 'this'
pointer needs a valid value. CodeGen works around this by creating a
temporary region anyway; now, so does the analyzer.
The analyzer also does this when accessing a field of a struct rvalue.
This is a little unfortunate, since the rest of the struct will soon be
thrown away, but it does make things consistent with the rest of the
analyzer.
This allows us to bring back the assumption that all known 'this' values
are Locs. This is a revised version of r164828-9, reverted in r164876-7.
<rdar://problem/12137950>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166120 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
@implementation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166047 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This implementation doesn't warn on anything that GCC doesn't warn on with the
exception of templates specializations (GCC doesn't warn, Clang does). The
specific skipped cases (boolean, constant expressions, enums) are open for
debate/adjustment if anyone wants to demonstrate that GCC is being overly
conservative here. The only really obvious false positive I found was in the
Clang regression suite's MPI test - apparently MPI uses specific flag values in
pointer constants. (eg: #define FOO (void*)~0)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166039 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Follow-up to r165838, which fixed a potential crash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166002 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165992 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165744 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This time, actually uncomment the code that's supposed to fix the problem.
This reverts r165671 / 8ceb837585ed973dc36fba8dfc57ef60fc8f2735.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165676 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
offsets."
Author: Jordan Rose <jordan_rose@apple.com>
Date: Wed Oct 10 21:31:21 2012 +0000
[analyzer] Treat fields of unions as having symbolic offsets.
This allows only one field to be active at a time in RegionStore.
This isn't quite the correct behavior for unions, but it at least
would handle the case of "value goes in, value comes out" from the
same field.
RegionStore currently has a number of places where any access to a union
results in UnknownVal being returned. However, it is clearly missing
some cases, or the original issue wouldn't have occurred. It is probably
now safe to remove those changes, but that's a potentially destabilizing
change that should wait for more thorough testing.
Fixes PR14054.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165660 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit cf9030e480f77ab349672f00ad302e216c26c92c.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165671 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows only one field to be active at a time in RegionStore.
This isn't quite the correct behavior for unions, but it at least
would handle the case of "value goes in, value comes out" from the
same field.
RegionStore currently has a number of places where any access to a union
results in UnknownVal being returned. However, it is clearly missing
some cases, or the original issue wouldn't have occurred. It is probably
now safe to remove those changes, but that's a potentially destabilizing
change that should wait for more thorough testing.
Fixes PR14054.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165660 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
...but do run them on user headers.
Previously, we were inconsistent here: non-path-sensitive checks on code
/bodies/ were only run in the main source file, but checks on
/declarations/ were run in /all/ headers. Neither of those is the
behavior we want.
Thanks to Sujit for pointing this out!
<rdar://problem/12454226>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165635 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This should fix the bots.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165358 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The Clang ASTs are a DAG, not a pure tree. However, ParentMap has to
choose a single parent for each object. In the main (only?) cases in
which the AST forms a DAG, it protects from multiple traversal by using
OpaqueValueExprs. Previously, ParentMap would just unconditionally look
through all OpaqueValueExprs when building its map.
In order to make this behavior better for the analyzer's diagnostics,
ParentMap was changed to not set a statement's parent if there already
was one in the map. However, ParentMap is supposed to allow updating
existing mappings by calling addStmt once again. This change makes the
"transparency" of OpaqueValueExprs explicit, and disables it when it
is not desired, rather than checking the current contents of the map.
This new code seems like a big change, but it should actually have
essentially the same performance as before. Only OpaqueValueExprs and
their users (PseudoObjectExpr and BinaryConditionalOperator) will
have any different behavior.
There should be no user-visible functionality change, though a test
has been added for the current behavior of BinaryConditionalOperator
source locations and accompanying Xcode arrows (which are not so great...).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165355 91177308-0d34-0410-b5e6-96231b3b80d8
|
