| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 162977
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PathDiagnostics are actually profiled and uniqued independently of the
path on which the bug occurred. This is used to merge diagnostics that
refer to the same issue along different paths, as well as by the plist
diagnostics to reference files created by the HTML diagnostics.
However, there are two problems with the current implementation:
1) The bug description is included in the profile, but some
PathDiagnosticConsumers prefer abbreviated descriptions and some
prefer verbose descriptions. Fixed by including both descriptions in
the PathDiagnostic objects and always using the verbose one in the profile.
2) The "minimal" path generation scheme provides extra information about
which events came from macros that the "extensive" scheme does not.
This resulted not only in different locations for the plist and HTML
diagnostics, but also in diagnostics being uniqued in the plist output
but not in the HTML output. Fixed by storing the "end path" location
explicitly in the PathDiagnostic object, rather than trying to find the
last piece of the path when the diagnostic is requested.
This should hopefully finish unsticking our internal buildbot.
llvm-svn: 162965
|
| |
|
|
|
|
|
| |
Basically, do the correct thing to fix the XML generation error, rather
than making it even worse by unilaterally dereferencing a null pointer.
llvm-svn: 162964
|
| |
|
|
|
|
|
|
|
| |
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
|
| |
|
|
|
|
|
|
|
|
|
|
| |
reanalyzed.
The policy on what to reanalyze should be in AnalysisConsumer with the
rest of visitation order logic.
There is no reason why ExprEngine needs to pass the Visited set to
CoreEngine, it can populate it itself.
llvm-svn: 162957
|
| |
|
|
| |
llvm-svn: 162951
|
| |
|
|
|
|
| |
Thanks for catching this!
llvm-svn: 162949
|
| |
|
|
|
|
|
|
|
|
| |
If the current path diagnostic does /not/ have files associated with it, we
were simply skipping on to the next diagnostic with 'continue'. But that
also skipped the close tag for the diagnostic's <dict> node.
Part of fixing our internal analyzer buildbot.
llvm-svn: 162939
|
| |
|
|
|
|
|
|
| |
from callee to caller.
radar://12109638
llvm-svn: 162935
|
| |
|
|
| |
llvm-svn: 162934
|
| |
|
|
|
|
| |
should consider renaming the command line option as well.
llvm-svn: 162932
|
| |
|
|
|
|
|
|
| |
'visualizeExplodedGraphWithUbigGraph'
and 'visualizeExplodedGraphWithGraphViz' respectively.
llvm-svn: 162931
|
| |
|
|
| |
llvm-svn: 162930
|
| |
|
|
|
|
| |
individual flags.
llvm-svn: 162929
|
| |
|
|
| |
llvm-svn: 162928
|
| |
|
|
| |
llvm-svn: 162927
|
| |
|
|
|
|
|
|
|
|
|
|
| |
inlined function.
This resolves retain count checker false positives that are caused by
inlining ObjC and other methods. Essentially, if we are passing an
object to a method with "delegate" in the selector or a function pointer
as another argument, we should stop tracking the other parameters/return
value as far as the retain count checker is concerned.
llvm-svn: 162876
|
| |
|
|
|
|
| |
Thanks Jordan.
llvm-svn: 162875
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This heuristic addresses the case when a pointer (or ref) is passed
to a function, which initializes the variable (or sets it to something
other than '0'). On the branch where the inlined function does not
set the value, we report use of undefined value (or NULL pointer
dereference). The access happens in the caller and the path
through the callee would get pruned away with regular path pruning. To
solve this issue, we previously disabled diagnostic pruning completely
on undefined and null pointer dereference checks, which entailed very
verbose diagnostics in most cases. Furthermore, not all of the
undef value checks had the diagnostic pruning disabled.
This patch implements the following heuristic: if we pass a pointer (or
ref) to the region (on which the error is reported) into a function and
it's value is either undef or 'NULL' (and is a pointer), do not prune
the function.
llvm-svn: 162863
|
| |
|
|
|
|
|
|
|
| |
a comma separated collection of key:value pairs (which are strings). This
allows a general way to provide analyzer configuration data from the command line.
No clients yet.
llvm-svn: 162827
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In C++, objects being returned on the stack are actually copy-constructed into
the return value. That means that when a temporary is returned, it still has
to be destroyed, i.e. the returned expression will be wrapped in an
ExprWithCleanups node. Our "returning stack memory" checker needs to look
through this node to see if we really are returning an object by value.
PR13722
llvm-svn: 162817
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, CallEventManager::getCaller was looking at the call site for
an inlined call and trying to see what kind of call it was, but it only
checked for CXXConstructExprClass. (It's not using an isa<> here to avoid
doing three more checks on the the statement class.)
This caused an unreachable when we actually did inline the constructor of a
temporary object.
PR13717
llvm-svn: 162792
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When exiting a function, the analyzer looks for the last statement in the
function to see if it's a return statement (and thus bind the return value).
However, the search for "the last statement" was accepting statements that
were in implicitly-generated inlined functions (i.e. destructors). So we'd
go and get the statement from the destructor, and then say "oh look, this
function had no explicit return...guess there's no return value". And /that/
led to the value being returned being declared dead, and all our leak
checkers complaining.
llvm-svn: 162791
|
| |
|
|
|
|
|
|
| |
No test case since this is a debug option that we will never turn on by
default since it makes the leak checkers much less useful. (We'll only report
leaks at the end of analysis if -analyzer-purge=none.)
llvm-svn: 162772
|
| |
|
|
|
|
|
|
|
|
|
| |
This helper function (in the clang::ento::bugreporter namespace) may add more
than one visitor, but conceptually it's tracking a single use of a null or
undefined value and should do so as best it can.
Also, the BugReport parameter has been made a reference to underscore that
it is non-optional.
llvm-svn: 162720
|
| |
|
|
|
|
|
|
| |
As Anna pointed out to me offline, it's a little silly to walk backwards through
the graph to find the store site when BugReporter will do the exact same walk
as part of path diagnostic generation.
llvm-svn: 162719
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if we were tracking stores to a variable 'x', and came across this:
x = foo();
...we would simply emit a note here and stop. Now, we'll step into 'foo' and
continue tracking the returned value from there.
<rdar://problem/12114689>
llvm-svn: 162718
|
| |
|
|
|
|
|
|
|
|
| |
The two callers are using this in order to be conservative, so let's just
clarify the information that's actually being provided here. This is not
related to inlining decisions in any way.
No functionality change.
llvm-svn: 162717
|
| |
|
|
|
|
|
|
| |
Also, add comments to addTrackNullOrUndefValueVisitor.
Thanks for the review, Anna!
llvm-svn: 162695
|
| |
|
|
|
|
|
|
|
|
|
| |
Because the CXXNewExpr appears after the CXXConstructExpr in the CFG, we don't
actually have the correct region to construct into at the time we decide
whether or not to inline. The long-term fix (discussed in PR12014) might be to
introduce a new CFG node (CFGAllocator) that appears before the constructor.
Tracking the short-term fix in <rdar://problem/12180598>.
llvm-svn: 162689
|
| |
|
|
| |
llvm-svn: 162687
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This allows us to better reason about status objects, like Clang's own
llvm::Optional (when its contents are trivially destructible), which are
often intended to be passed around by value.
We still don't inline constructors for temporaries in the general case.
<rdar://problem/11986434>
llvm-svn: 162681
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows checkers (like the MallocChecker) to process the effects of the
bind. Previously, using a memory-allocating function (like strdup()) in an
initializer would result in a leak warning.
This does bend the expectations of checkBind a bit; since there is no
assignment expression, the statement being used is the initializer value.
In most cases this shouldn't matter because we'll use a PostInitializer
program point (rather than PostStmt) for any checker-generated nodes, though
we /will/ generate a PostStore node referencing the internal statement.
(In theory this could have funny effects if someone actually does an
assignment within an initializer; in practice, that seems like it would be
very rare.)
<rdar://problem/12171711>
llvm-svn: 162637
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 162632
|
| |
|
|
|
|
|
| |
this group into "alpha" and "beta" to distinguish between checkers in
different levels of premature state.
llvm-svn: 162582
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
generated for a given diagnostic to another. Because PathDiagnostics
are specific to a give PathDiagnosticConsumer, store in
a FoldingSet a unique hash for a PathDiagnostic (that will be the same
for the same bug for different PathDiagnosticConsumers) that
stores a list of files generated. This can then be read by the
other PathDiagnosticConsumers.
This fixes breakage in the PLIST-HTML output.
llvm-svn: 162580
|
| |
|
|
|
|
|
|
|
|
|
|
| |
More generally, any time we try to track where a null value came from, we
should show if it came from a function. This usually isn't necessary if
the value is symbolic, but if the value is just a constant we previously
just ignored its origin entirely. Now, we'll step into the function and
recursively add a visitor to the returned expression.
<rdar://problem/12114609>
llvm-svn: 162563
|
| |
|
|
|
|
|
| |
When reallocation of a non-allocated (not owned) symbol fails do not
expect it to be freed.
llvm-svn: 162533
|
| |
|
|
|
|
|
|
| |
This code has been added a while ago and removing it does not trigger
any test failures. The false positives it was trying to suppress are
probably handled by other logic (ex: special handling of delegates).
llvm-svn: 162529
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
With inlining, retain count checker starts tracking 'self' through the
init methods. The analyser results were too noisy if the developer
did not follow 'self = [super init]' pattern (which is common
especially in older code bases) - we reported self init anti-pattern AND
possible use-after-free. This patch teaches the retain count
checker to assume that [super init] does not fail when it's not consumed
by another expression. This silences the retain count warning that warns
about possibility of use-after-free when init fails, while preserving
all the other checking on 'self'.
llvm-svn: 162508
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Until we have full support for pointers-to-members, we can at least
approximate some of their use by tracking null and non-null values.
We thus treat &A::m_ptr as a non-null void * symbol, and MemberPointer(0)
as a pointer-sized null constant.
This enables support for what is sometimes called the "safe bool" idiom,
demonstrated in the test case.
llvm-svn: 162495
|
| |
|
|
|
|
|
|
| |
This is trivial; the UserDefinedConversion always wraps a CXXMemberCallExpr
for the appropriate conversion function, so it's just a matter of
propagating that value to the CastExpr itself.
llvm-svn: 162494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A CXXDefaultArgExpr wraps an Expr owned by a ParmVarDecl belonging to the
called function. In general, ExprEngine and Environment ought to treat this
like a ParenExpr or other transparent wrapper expression, with the inside
expression evaluated first.
However, if we call the same function twice, we'd produce a CFG that contains
the same wrapped expression twice, and we're not set up to handle that. I've
added a FIXME to the CFG builder to come back to that, but meanwhile we can
at least handle expressions that don't need to be explicitly evaluated:
literals. This probably handles many common uses of default parameters:
true/false, null, etc.
Part of PR13385 / <rdar://problem/12156507>
llvm-svn: 162453
|
| |
|
|
| |
llvm-svn: 162430
|
| |
|
|
| |
llvm-svn: 162412
|
| |
|
|
| |
llvm-svn: 162405
|
| |
|
|
|
|
|
|
| |
The checker adds assumptions that the return values from the known APIs
are non-nil. Teach the checker about NSArray/NSMutableArray/NSOrderedSet
objectAtIndex, objectAtIndexedSubscript.
llvm-svn: 162398
|
| |
|
|
|
|
| |
another way to whitelist these special cases. This is an intermediate patch.
llvm-svn: 162386
|
| |
|
|
|
|
|
|
| |
As part of this change, I discovered that a few of our tests were not testing
the RangeConstraintManager. Luckily all of those passed when I moved them
over to use that constraint manager.
llvm-svn: 162384
|
| |
|
|
|
|
|
|
|
| |
'killBinding()'. The name is more specific, and one just forwarded
to the other.
Add some doxygen comments along the way.
llvm-svn: 162350
|