| Age | Commit message (Collapse) | Author |
|---|
|
to prevent an edge being optimized away.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181088 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
same statement parents.
This change required some minor changes to LocationContextMap to have it map
from PathPieces to LocationContexts instead of PathDiagnosticCallPieces to
LocationContexts. These changes are in the other diagnostic
generation logic as well, but are functionally equivalent.
Interestingly, this optimize requires delaying "cleanUpLocation()" until
later; possibly after all edges have been optimized. This is because
we need PathDiagnosticLocations to refer to the semantic entity (e.g. a statement)
as long as possible. Raw source locations tell us nothing about
the semantic relationship between two locations in a path.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181084 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Not guaranteed to do anything useful yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of a weird merge error with git.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180981 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variable in BugReporter."
This reverts commit 180974. It broke the build.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180979 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
BugReporter.
BugReporter is used to process ALL bug reports. By using a shared map,
we are having mappings from different PathDiagnosticPieces to LocationContexts
well beyond the point where we are processing a given report. This
state is inherently error prone, and is analogous to using a global
variable. Instead, just create a temporary map, one per report,
and when we are done with it we throw it away. No extra state.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180974 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180747 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(through indirection) PathDiagnosticPieces."
Jordan rightly pointed out that we can do the same with std::list.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
indirection) PathDiagnosticPieces.
Much of this patch outside of PathDiagnostics.h are just minor
syntactic changes due to the return type for operator* and the like
changing for the iterator, so the real focus should be on
PathPieces itself.
This change is motivated so that we can do efficient insertion
and removal of individual pieces from within a PathPiece, just like
this was a kind of "IR" for static analyzer diagnostics. We
currently implement path transformations by iterating over an
entire PathPiece and making a copy. This isn't very natural for
some algorithms.
We use an ilist here instead of std::list because we want operations
to rip out/insert nodes in place, just like IR manipulation. This
isn't being used yet, but opens the door for more powerful
transformation algorithms on diagnostic paths.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180741 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PathDiagnosticLocation::createEndOfPath for greater code reuse
The 2 functions were computing the same location using different logic (each one had edge case bugs that the other
one did not). Refactor them to rely on the same logic.
The location of the warning reported in text/command line output format will now match that of the plist file.
There is one change in the plist output as well. When reporting an error on a BinaryOperator, we use the location of the
operator instead of the beginning of the BinaryOperator expression. This matches our output on command line and
looks better in most cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180165 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
tracking is not live in the last node of the path
We always register the visitor on a node in which the value we are tracking is live and constrained. However,
the visitation can restart at a node, later on the path, in which the value is under constrained because
it is no longer live. Previously, we just silently stopped tracking in that case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179731 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
visitor for nil receiver
We can check if the receiver is nil in the node that corresponds to the StmtPoint of the message send.
At that point, the receiver is guaranteed to be live. We will find at least one unreclaimed node due to
my previous commit (look for StmtPoint instead of PostStmt) and the fact that the nil receiver nodes are tagged.
+ a couple of extra tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178381 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
participates in the computation of the nil we warn about.
We should only suppress a bug report if the IDCed or null returned nil value is directly related to the value we are warning about. This was
not the case for nil receivers - we would suppress a bug report that had an IDCed nil receiver on the path regardless of how it’s
related to the warning.
1) Thread EnableNullFPSuppression parameter through the visitors to differentiate between tracking the value which
is directly responsible for the bug and other values that visitors are tracking (ex: general tracking of nil receivers).
2) in trackNullOrUndef specifically address the case when a value of the message send is nil due to the receiver being nil.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178309 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
reclaimed
The visitor should look for the PreStmt node as the receiver is nil in the PreStmt and this is the node. Also, tag the nil
receiver nodes with a special tag for consistency.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178152 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also, replace a std::string with a SmallString.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177352 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
sure it attaches in the given edge case
In the test case below, the value V is not constrained to 0 in ErrorNode but it is in node N.
So we used to fail to register the Suppression visitor.
We also need to change the way we determine that the Visitor should kick in because the node N belongs to
the ExplodedGraph and might not be on the BugReporter path that the visitor sees. Instead of trying to match the node,
turn on the visitor when we see the last node in which the symbol is ‘0’.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177121 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
same node it was registered at
The visitor used to assume that the value it’s tracking is null in the first node it examines. This is not true.
If we are registering the Suppress Inlined Defensive checks visitor while traversing in another visitor
(such as FindlastStoreVisitor). When we restart with the IDC visitor, the invariance of the visitor does
not hold since the symbol we are tracking no longer exists at that point.
I had to pass the ErrorNode when creating the IDC visitor, because, in some cases, node N is
neither the error node nor will be visible along the path (we had not finalized the path at that point
and are dealing with ExplodedGraph.)
We should revisit the other visitors which might not be aware that they might get nodes, which are
later in path than the trigger point.
This suppresses a number of inline defensive checks in JavaScriptCore.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176756 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Inlining brought a few "null pointer use" false positives, which occur because
the callee defensively checks if a pointer is NULL, whereas the caller knows
that the pointer cannot be NULL in the context of the given call.
This is a first attempt to silence these warnings by tracking the symbolic value
along the execution path in the BugReporter. The new visitor finds the node
in which the symbol was first constrained to NULL. If the node belongs to
a function on the active stack, the warning is reported, otherwise, it is
suppressed.
There are several areas for follow up work, for example:
- How do we differentiate the cases where the first check is followed by
another one, which does happen on the active stack?
Also, this only silences a fraction of null pointer use warnings. For example, it
does not do anything for the cases where NULL was assigned inside a callee.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176402 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This provides a few sundry cleanups, and allows us to provide
a compile-time check for a case that was a runtime assertion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175987 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Post-commit CR feedback from Jordan Rose regarding r175594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also removes some redundant DNI comments on function declarations already
using the macro.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173956 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
|
|
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
|
|
brought into 'clang' namespace by clang/Basic/LLVM.h
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The issue here is that if we have 2 leaks reported at the same line for
which we cannot print the corresponding region info, they will get
treated as the same by issue_hash+description. We need to AUGMENT the
issue_hash with the allocation info to differentiate the two issues.
Add the "hash" (offset from the beginning of a function) representing
allocation site to solve the issue.
We might want to generalize solution in the future when we decide to
track more than just the 2 locations from the diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171825 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is the case where the analyzer tries to print out source locations
for code within a synthesized function body, which of course does not have
a valid source location. The previous fix attempted to do this during
diagnostic path pruning, but some diagnostics have pruning disabled, and
so any diagnostic with a path that goes through a synthesized body will
either hit an assertion or emit invalid output.
<rdar://problem/12657843> (again)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169631 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a simpler sort, entirely automatic with the help of
llvm/utils/sort_includes.py -- no manual edits here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169238 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 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
|
|
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167275 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
|
|
Updates to llvm/Support/Casting.h have rendered these classof()'s
irrelevant.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165770 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Somewhat troublingly, without this implemented, the check inside
isa_impl<> would silently use the parent's `classof()` when determining
whether it was okay to downcast from the parent to the child!
Bug analysis:
A build failure after removing the parent's `classof()` initially
alerted me to the bug, after which a little bit of thinking and reading
of the code identified the root cause.
The compiler could be made to prevent this bug from happening if there
were a way to ensure that in the code
template <typename To, typename From, typename Enabler = void>
struct isa_impl {
static inline bool doit(const From &Val) {
return To::classof(&Val);
}
};
that `To::classof` is actually inside the class `To`, and not in a base
class. I am not aware of a way to check this in C++. If there is a means
to perform that check, please bring it up on the list and this will be
fixed.
There is a high likelihood that there are other instances of this same
bug in the codebase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165769 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
|
|
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
|
|
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
|
|
LLVM_DELETED_FUNCTION.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164102 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of a std::string.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163488 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
As per Jordan's suggestion. (Came out of code review for r163261.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163269 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162965 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162863 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162720 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162719 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162580 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ArrayRef<SourceRange> for ranges. This
removes conceptual clutter, and can allow us to easy migrate to C++11 style for-range loops if we
ever move to using C++11 in Clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162029 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162028 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Because of this, we would previously emit NO path notes when a parameter
is constrained to null (because there are no stores). Now we show where we
made the assumption, which is much more useful.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161280 91177308-0d34-0410-b5e6-96231b3b80d8
|
