In the current implementation, we run visitors until the fixed point is
reached.
That is, if a visitor adds another visitor, the currently processed path
is destroyed, all diagnostics is discarded, and it is regenerated again,
until it's no longer modified.
This pattern has a few negative implications:
- This loop does not even guarantee to terminate.
E.g. just imagine two visitors bouncing a diagnostics around.
- Performance-wise, e.g. for sqlite3 all visitors are being re-run at
least 10 times for some bugs.
We have already seen a few reports where it leads to timeouts.
- If we want to add more computationally intense visitors, this will
become worse.
- From architectural standpoint, the current layout requires copying
visitors, which is conceptually wrong, and can be annoying (e.g. no
unique_ptr on visitors allowed).
The proposed change is a much simpler architecture: the outer loop
processes nodes upwards, and whenever the visitor is added it only
processes current nodes and above, thus guaranteeing termination.
Differential Revision: https://reviews.llvm.org/D47856
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335666 91177308-0d34-0410-b5e6-96231b3b80d8
r315736 added support for the misplaced CF_RETURNS_RETAINED annotation on
CFRetain() wrappers. It works by trusting the function's name (seeing if it
confirms to the CoreFoundation naming convention) rather than the annotation.
There are more false positives caused by users using a different naming
convention, namely starting the function name with "retain" or "release"
rather than suffixing it with "retain" or "release" respectively.
Because this isn't according to the naming convention, these functions
are usually inlined and the annotation is therefore ignored, which is correct.
But sometimes we run out of inlining stack depth and the function is
evaluated conservatively and then the annotation is trusted.
Add support for the "alternative" naming convention and test the situation when
we're running out of inlining stack depth.
rdar://problem/18270122
Differential Revision: https://reviews.llvm.org/D45117
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@330375 91177308-0d34-0410-b5e6-96231b3b80d8
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@329399 91177308-0d34-0410-b5e6-96231b3b80d8
For other regions, the error message contains a good indication of the
problem, and there, in general, nothing helpful we can print.
Error pointer to the problematic expression seems enough.
rdar://37323555
Differential Revision: https://reviews.llvm.org/D44409
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@327727 91177308-0d34-0410-b5e6-96231b3b80d8
MemRegion::getString() is a wrapper around MemRegion::dump(), which is not
user-friendly and should never be used for diagnostic messages.
Actual cases where raw dumps were reaching the user were unintentionally fixed
in r315736; these were noticed accidentally and shouldn't be reproducible
anymore. For now RetainCountChecker only tracks pointers through variable
regions, and for those dumps are "fine". However, we should still use a less
dangerous method for producing our path notes.
This patch replaces the dump with printing a variable name, asserting that this
is indeed a variable.
Differential Revision: https://reviews.llvm.org/D42015
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322799 91177308-0d34-0410-b5e6-96231b3b80d8
In most cases using
`N->getState()->getSVal(E, N->getLocationContext())`
is ugly, verbose, and also opens up more surface area for bugs if an
inconsistent location context is used.
This patch introduces a helper on an exploded node, and ensures
consistent usage of either `ExplodedNode::getSVal` or
`CheckContext::getSVal` across the codebase.
As a result, a large number of redundant lines is removed.
Differential Revision: https://reviews.llvm.org/D42155
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322753 91177308-0d34-0410-b5e6-96231b3b80d8
Teach the retain-count checker that CoreMedia reference types use
CoreFoundation-style reference counting. This enables the checker
to catch leaks and over releases of those types.
rdar://problem/33599757
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318979 91177308-0d34-0410-b5e6-96231b3b80d8
It is not uncommon for the users to make their own wrappers around
CoreFoundation's CFRetain and CFRelease functions that are defensive
against null references. In such cases CFRetain is often incorrectly
marked as CF_RETURNS_RETAINED. Ignore said annotation and treat such
wrappers similarly to the regular CFRetain.
rdar://problem/31699502
Differential Revision: https://reviews.llvm.org/D38877
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315736 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes the test failure: temporary is now bound to std::string, tests
fully pass on Linux.
This reverts commit b36ee0924038e1d95ea74230c62d46e05f80587e.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314859 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds the functionality of performing reference counting on the
callee side for Integer Set Library (ISL) to Clang Static Analyzer's
RetainCountChecker.
Reference counting on the callee side can be extensively used to perform
debugging within a function (For example: Finding leaks on error paths).
Patch by Malhar Thakkar!
Differential Revision: https://reviews.llvm.org/D36441
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311063 91177308-0d34-0410-b5e6-96231b3b80d8
Add a 'Generalized' object kind to the retain-count checker and suitable
generic diagnostic text for retain-count diagnostics involving those objects.
For now the object kind is introduced in summaries by 'annotate' attributes.
Once we have more experience with these annotations we will propose explicit
attributes.
Patch by Malhar Thakkar!
Differential Revision: https://reviews.llvm.org/D35613
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@308990 91177308-0d34-0410-b5e6-96231b3b80d8
Add support to the retain-count checker for an annotation indicating that a
function's implementation should be trusted by the retain count checker.
Functions with these attributes will not be inlined and the arguments will
be treating as escaping.
Adding this annotation avoids spurious diagnostics when the implementation of
a reference counting operation is visible but the analyzer can't reason
precisely about the ref count.
Patch by Malhar Thakkar!
Differential Revision: https://reviews.llvm.org/D34937
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@308416 91177308-0d34-0410-b5e6-96231b3b80d8
Simplifies and makes explicit the memory ownership model rather than
implicitly passing/acquiring ownership.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291143 91177308-0d34-0410-b5e6-96231b3b80d8
This function receives a callback block. The analyzer suspects that this block
may be used to take care of releasing the libdispatch object returned from
the function. In fact, it doesn't - it only releases the raw data buffer.
Inform the analyzer about that. Fixes the resulting false negatives.
rdar://problem/22280098
Differential Revision: https://reviews.llvm.org/D27409
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289047 91177308-0d34-0410-b5e6-96231b3b80d8
Under automated reference counting the analyzer treats a methods -- even those
starting with 'copy' and friends -- as returning an unowned value. This is
because ownership of CoreFoundation objects must be transferred to ARC
with __bridge_transfer or CFBridgingRelease() before being returned as
ARC-managed bridged objects.
Unfortunately this could lead to a poor diagnostic inside copy methods under
ARC where the analyzer would complain about a leak of a returned CF value inside
a method "whose name does not start with 'copy'" -- even though the name did
start with 'copy'.
This commit improves the diagnostic under ARC to say inside a method "returned
from a method managed by Automated Reference Counting".
rdar://problem/28849667
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286694 91177308-0d34-0410-b5e6-96231b3b80d8
The context argument passed to VideoToolbox's
VTCompressionSessionEncodeFrame() function is ultimately passed to a callback
supplied when creating the compression session and so may be freed by that
callback. To suppress false positives in this case, teach the retain count
checker to stop tracking that argument.
This isn't suppressed by the usual callback context mechanism because the call
to VTCompressionSessionEncodeFrame() doesn't include the callback itself.
rdar://problem/27685213
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286633 91177308-0d34-0410-b5e6-96231b3b80d8
The class BodyFarm creates bodies for
OSAtomicCompareAndSwap*, objc_atomicCompareAndSwap*, dispatch_sync*, dispatch_once*
and for them the flag isBodyAutosynthesized is set to true.
This diff
1. makes AnalysisConsumer::HandleCode skip the autosynthesized code
2. replaces assert(LCtx->getParent()) in RetainCountChecker::checkEndFunction
by assert(!LCtx->inTopFrame()) (minor cleanup)
Test plan: make -j8 check-clang-analysis
Differential revision: https://reviews.llvm.org/D24792
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282293 91177308-0d34-0410-b5e6-96231b3b80d8
Change the retain count checker to treat CoreFoundation-style "CV"-prefixed
reference types from CoreVideo similarly to CoreGraphics types. With this
change, we treat CVFooRetain() on a CVFooRef type as a retain. CVFooRelease()
APIs are annotated as consuming their parameter, so this change prevents false
positives about incorrect decrements of reference counts.
<rdar://problem/27116090>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278382 91177308-0d34-0410-b5e6-96231b3b80d8
This encourages checkers to make logical decisions depending on
value of which region was the symbol under consideration
introduced to denote.
A similar technique is already used in a couple of checkers;
they were modified to call the new method.
Differential Revision: http://reviews.llvm.org/D22242
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275290 91177308-0d34-0410-b5e6-96231b3b80d8
The analyzer trims unnecessary nodes from the exploded graph before reporting
path diagnostics. However, in some cases it can trim all nodes (including the
error node), leading to an assertion failure (see
https://llvm.org/bugs/show_bug.cgi?id=24184).
This commit addresses the issue by adding two new APIs to CheckerContext to
explicitly create error nodes. Unless the client provides a custom tag, these
APIs tag the node with the checker's tag -- preventing it from being trimmed.
The generateErrorNode() method creates a sink error node, while
generateNonFatalErrorNode() creates an error node for a path that should
continue being explored.
The intent is that one of these two methods should be used whenever a checker
creates an error node.
This commit updates the checkers to use these APIs. These APIs
(unlike addTransition() and generateSink()) do not take an explicit Pred node.
This is because there are not any error nodes in the checkers that were created
with an explicit different than the default (the CheckerContext's Pred node).
It also changes generateSink() to require state and pred nodes (previously
these were optional) to reduce confusion.
Additionally, there were several cases where checkers did check whether a
generated node could be null; we now explicitly check for null in these places.
This commit also includes a test case written by Ying Yi as part of
http://reviews.llvm.org/D12163 (that patch originally addressed this issue but
was reverted because it introduced false positive regressions).
Differential Revision: http://reviews.llvm.org/D12780
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247859 91177308-0d34-0410-b5e6-96231b3b80d8
(return by value is in ExprEngine::processPointerEscapedOnBind and any
other call to the scanReachableSymbols function template used there)
Protect the special members in the base class to avoid slicing, and make
derived classes final so these special members don't accidentally become
public on an intermediate base which would open up the possibility of
slicing again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244975 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
Includes a simple static analyzer check and not much else, but we'll also
be able to take advantage of this in Swift.
This feature can be tested for using __has_feature(cf_returns_on_parameters).
This commit also contains two fixes:
- Look through non-typedef sugar when deciding whether something is a CF type.
- When (cf|ns)_returns(_not)?_retained is applied to invalid properties,
refer to "property" instead of "method" in the error message.
rdar://problem/18742441
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240185 91177308-0d34-0410-b5e6-96231b3b80d8
This is imitating a pre-r228174 state where ivars are not considered tracked by
default, but with the addition that even ivars /with/ retain count information
(e.g. "[_ivar retain]; [ivar _release];") are not being tracked as well. This is
to ensure that we don't regress on values accessed through both properties and
ivars, which is what r228174 was trying to fix.
The issue occurs in code like this:
[_contentView retain];
[_contentView removeFromSuperview];
[self addSubview:_contentView]; // invalidates 'self'
[_contentView release];
In this case, the call to -addSubview: may change the value of self->_contentView,
and so the analyzer can't be sure that we didn't leak the original _contentView.
This is a correct conservative view of the world, but not a useful one. Until we
have a heuristic that allows us to not consider this a leak, not emitting a
diagnostic is our best bet.
This commit disables all of the ivar-related retain count tests, but does not
remove them to ensure that we don't crash trying to evaluate either valid or
erroneous code. The next commit will add a new test for the example above so
that this commit (and the previous one) can be reverted wholesale when a better
solution is implemented.
Rest of rdar://problem/20335433
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233592 91177308-0d34-0410-b5e6-96231b3b80d8
Give up this checking in order to continue tracking that these values came from
direct ivar access, which will be important in the next commit.
Part of rdar://problem/20335433
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233591 91177308-0d34-0410-b5e6-96231b3b80d8
Similarly, don't assume +0 if the property's setter is manually implemented.
In both cases, if the property's ownership is explicitly written, then we /do/
assume the ivar has the same ownership.
rdar://problem/20218183
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232849 91177308-0d34-0410-b5e6-96231b3b80d8
In theory we could assume a CF property is stored at +0 if there's not a custom
setter, but that's not really worth the complexity. What we do know is that a
CF property can't have ownership attributes, and so we shouldn't assume anything
about the ownership of the ivar.
rdar://problem/20076963
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231553 91177308-0d34-0410-b5e6-96231b3b80d8
We would wrongfully reject (a.~A)() in both the destructor and
pseudo-destructor cases.
This fixes PR22668.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230512 91177308-0d34-0410-b5e6-96231b3b80d8
We expect in general that any nil value has no retain count information
associated with it; violating this results in unexpected state unification
/later/ when we decide to throw the information away. Unexpectedly caching
out can lead to an assertion failure or crash.
rdar://problem/19862648
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229934 91177308-0d34-0410-b5e6-96231b3b80d8
George Karpenkov