It is a reference-counted class but it uses different methods for that
and the checker doesn't understand them yet.
Differential Revision: https://reviews.llvm.org/D103081
When searching for stores and creating corresponding notes, the
analyzer is more specific about the target region of the store
as opposed to the stored value. While this description was tweaked
for constant and undefined values, it lacked in the most general
case of symbolic values.
This patch tries to find a memory region, where this value is stored,
to use it as a better alias for the value.
rdar://76645710
Differential Revision: https://reviews.llvm.org/D101041
Since we can report memory leaks on one variable, while the originally
allocated object was stored into another one, we should explain
how did it get there.
rdar://76645710
Differential Revision: https://reviews.llvm.org/D100852
When reporting leaks, we try to attach the leaking object to some
variable, so it's easier to understand. Before the patch, we always
tried to use the first variable that stored the object in question.
This can get very confusing for the user, if that variable doesn't
contain that object at the moment of the actual leak. In many cases,
the warning is dismissed as false positive and it is effectively a
false positive when we fail to properly explain the warning to the
user.
This patch addresses the bigest issue in cases like this. Now we
check if the variable still contains the leaking symbolic object.
If not, we look for the last variable to actually hold it and use
that variable instead.
rdar://76645710
Differential Revision: https://reviews.llvm.org/D100839
This reverts commit 3500cc8d89.
This old commit was made over a completely false premise. OSSymbols
aren't different from other OSObjects and we shouldn't treat them
differently for the purposes of static analysis.
So far we've been dropping coverage every time we've encountered
a CXXInheritedCtorInitExpr. This patch attempts to add some
initial support for it.
Constructors for arguments of a CXXInheritedCtorInitExpr are still
not fully supported.
Differential Revision: https://reviews.llvm.org/D74735
It's a new API for custom RTTI in Apple IOKit/DriverKit framework that is
similar to OSDynamicCast() that's already supported, but crashes instead of
returning null (and therefore causing UB when the cast fails unexpectedly).
Kind of like cast_or_null<> as opposed to dyn_cast_or_null<> in LLVM's RTTI.
Historically, RetainCountChecker was responsible for modeling OSDynamicCast.
This is simply an extension of the same functionality.
Differential Revision: https://reviews.llvm.org/D63117
llvm-svn: 363891
The checker was crashing when it was trying to assume a structure
to be null or non-null so that to evaluate the effect of the annotation.
Differential Revision: https://reviews.llvm.org/D61958
llvm-svn: 360790
In the OSObject universe there appears to be another slightly popular contract,
apart from "create" and "get", which is "matching". It optionally consumes
a "table" parameter and if a table is passed, it fills in the table and
returns it at +0; otherwise, it creates a new table, fills it in and
returns it at +1.
For now suppress false positives by doing a conservative escape on all functions
that end with "Matching", which is the naming convention that seems to be
followed by all such methods.
Differential Revision: https://reviews.llvm.org/D61161
llvm-svn: 359264
Track them for ISL/OS objects by default, and for NS/CF under a flag.
rdar://47536377
Differential Revision: https://reviews.llvm.org/D57356
llvm-svn: 352534
This is not NFC strictly speaking, since it unifies CleanupAttr handling,
so that out parameters now also understand it.
Differential Revision: https://reviews.llvm.org/D56759
llvm-svn: 351394
The fix done in D55465 did not previously apply when the function was inlined.
rdar://46889541
Differential Revision: https://reviews.llvm.org/D55976
llvm-svn: 349876
Previously, we were not printing a note at all if at least one of the parameters was not annotated.
rdar://46888422
Differential Revision: https://reviews.llvm.org/D55972
llvm-svn: 349875
Right now they report to have one parameter with null decl,
because initializing an ArrayRef of pointers with a nullptr
yields an ArrayRef to an array of one null pointer.
Fixes a crash in the OSObject section of RetainCountChecker.
Differential Revision: https://reviews.llvm.org/D55671
llvm-svn: 349229
This is currently a diagnostics, but might be upgraded to an error in the future,
especially if we introduce os_return_on_success attributes.
rdar://46359592
Differential Revision: https://reviews.llvm.org/D55530
llvm-svn: 348820
Escaping to void * / uint64_t / others non-OSObject * should stop tracking,
as such functions can have heterogeneous semantics depending on context,
and can not always be annotated.
rdar://46439133
Differential Revision: https://reviews.llvm.org/D55465
llvm-svn: 348675
Allow enabling and disabling tracking of ObjC/CF objects
separately from tracking of OS objects.
Differential Revision: https://reviews.llvm.org/D55400
llvm-svn: 348638
The "free" call frees the object immediately, ignoring the reference count.
Sadly, it is actually used in a few places, so we need to model it.
Differential Revision: https://reviews.llvm.org/D55092
llvm-svn: 347950
Move visitors to the implementation file, move a complicated logic into
a function.
Differential Revision: https://reviews.llvm.org/D55036
llvm-svn: 347946
Attempt to get a fully qualified name from AST if an SVal corresponding
to the object is not available.
Differential Revision: https://reviews.llvm.org/D55034
llvm-svn: 347944
If the object is a temporary, and there is no variable it binds to,
let's at least print out the object name in order to help differentiate
it from other temporaries.
rdar://45175098
Differential Revision: https://reviews.llvm.org/D55033
llvm-svn: 347943
Georgeta Igna