Added new enum in order to differentiate the warning messages on "misusing" into
3 categories: function calls, moving an object, copying an object. (At the
moment the checker gives the same message in case of copying and moving.)
Additional test cases added as well.
Differential Revision: https://reviews.llvm.org/D38674
llvm-svn: 316852
An earlier solution from Artem r315301 solves the reset problem, however, the
reports should be handled the same way in case of method calls. We should not
just report the base class of the object where the method was defined but the
whole object.
Fixed false positive which came from not removing the subobjects in case of a
state-resetting function. (Just replaced the State->remove(...) call to
removeFromState(..) which was defined exactly for that purpose.)
Some minor typos fixed in this patch as well which did not worth a whole new
patch in my opinion, so included them here.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 316850
OpaqueValueExpr in a GNU binary conditional expression.
It's not meaningful for a non-materialized temporary object to be used as a
common subexpression of multiple expressions.
llvm-svn: 316836
The loop unrolling feature aims to track the maximum possible steps a loop can
make. In order to implement this, it investigates the initial value of the
counter variable and the bound number. (It has to be known.)
These numbers are used as llvm::APInts, however, it was not checked if their
bitwidths are the same which lead to some crashes.
This revision solves this problem by extending the "shorter" one (to the length
of the "longer" one).
For the detailed bug report, see: https://bugs.llvm.org/show_bug.cgi?id=34943
Differential Revision: https://reviews.llvm.org/D38922
llvm-svn: 316830
In getLValueElement Base may represent the address of a label
(as in the newly-added test case), in this case it's not a loc::MemRegionVal
and Base.castAs<loc::MemRegionVal>() triggers an assert, this diff makes
getLValueElement return UnknownVal instead.
Differential revision: https://reviews.llvm.org/D39174
llvm-svn: 316399
Remove an option to use a reference type (on by default!) since a
non-reference type is always needed for creating expressions, functions
with multiple boolean parameters are very hard to use, and in general it
was just a booby trap for further crashes.
Furthermore, generalize call_once test case to fix some of the crashes mentioned
https://bugs.llvm.org/show_bug.cgi?id=34869
Also removes std::call_once crash.
Differential Revision: https://reviews.llvm.org/D39015
llvm-svn: 316041
The first attempt, rL315614 was reverted because one libcxx
test broke, and i did not know at the time how to deal with it.
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
llvm-svn: 315875
In some cases the analyzer didn't expect an array-type variable to be
initialized with anything other than a string literal. The patch essentially
removes the assertion, and ensures relatively sane behavior.
There is a bigger problem with these initializers. Currently our memory model
(RegionStore) is being ordered to initialize the array with a region that
is assumed to be storing the initializer rvalue, and it guesses to copy
the contents of that region to the array variable. However, it would make
more sense for RegionStore to receive the correct initializer in the first
place. This problem isn't addressed with this patch.
rdar://problem/27248428
Differential Revision: https://reviews.llvm.org/D23963
llvm-svn: 315750
The checker used to crash when a mempcpy's length argument is symbolic. In this
case the cast from 'void *' to 'char *' failed because the respective
ElementRegion that represents cast is hard to add on top of the existing
ElementRegion that represents the offset to the last copied byte, while
preseving a sane memory region structure.
Additionally, a few test cases are added (to casts.c) which demonstrate problems
caused by existing sloppy work we do with multi-layer ElementRegions. If said
cast would be modeled properly in the future, these tests would need to be
taken into account.
Differential Revision: https://reviews.llvm.org/D38797
llvm-svn: 315742
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
llvm-svn: 315736
If a method is resetting the state of an object that was moved from, it should
be safe to use this object again. However if the method was defined in a parent
class, but used in a child class, the reset didn't happen from the checker's
perspective.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 315301
The analyzer now realizes that C++ std::initializer_list objects and
Objective-C boxed structure/array/dictionary expressions can potentially
maintain a reference to the objects that were put into them. This avoids
false memory leak posivites and a few other issues.
This is a conservative behavior; for now, we do not model what actually happens
to the objects after being passed into such initializer lists.
rdar://problem/32918288
Differential Revision: https://reviews.llvm.org/D35216
llvm-svn: 314975
In ProgramState::getSVal(Location, Type) API which dereferences a pointer value,
when the optional Type parameter is not supplied and the Location is not typed,
type should have been guessed on a best-effort basis by inspecting the Location
more deeply. However, this never worked; the auto-detected type was instead
a pointer type to the correct type.
Fixed the issue and added various test cases to demonstrate which parts of the
analyzer were affected (uninitialized pointer argument checker, C++ trivial copy
modeling, Google test API modeling checker).
Additionally, autodetected void types are automatically replaced with char,
in order to simplify checker APIs. Which means that if the location is a void
pointer, getSVal() would read the first byte through this pointer
and return its symbolic value.
Fixes pr34305.
Differential Revision: https://reviews.llvm.org/D38358
llvm-svn: 314910
Fixes the test failure: temporary is now bound to std::string, tests
fully pass on Linux.
This reverts commit b36ee0924038e1d95ea74230c62d46e05f80587e.
llvm-svn: 314859
Only assume that IOBSDNameMatching and friends increment a reference counter
if their return type is a CFMutableDictionaryRef.
Differential Revision: https://reviews.llvm.org/D38487
llvm-svn: 314820
This function can now track null pointer through simple pointer arithmetic,
such as '*&*(p + 2)' => 'p' and so on, displaying intermediate diagnostic pieces
for the user to understand where the null pointer is coming from.
Differential Revision: https://reviews.llvm.org/D37025
llvm-svn: 314290
This API is used by checkers (and other entities) in order to track where does
a value originate from, by jumping from an expression value of which is equal
to that value to the expression from which this value has "appeared". For
example, it may be an lvalue from which the rvalue was loaded, or a function
call from which the dereferenced pointer was returned.
The function now avoids incorrectly unwrapping implicit lvalue-to-rvalue casts,
which caused crashes and incorrect intermediate diagnostic pieces. It also no
longer relies on how the expression is written when guessing what it means.
Fixes pr34373 and pr34731.
rdar://problem/33594502
Differential Revision: https://reviews.llvm.org/D37023
llvm-svn: 314287
This patch fixes analyzer's crash on the newly added test case
(see also https://bugs.llvm.org/show_bug.cgi?id=34374).
Pointers subtraction appears to be modeled incorrectly
in the following example:
char* p;
auto n = p - reinterpret_cast<char*>((unsigned long)1);
In this case the analyzer (built without this patch)
tries to create a symbolic value for the difference
treating reinterpret_cast<char*>((unsigned long)1)
as an integer, that is not correct.
Differential revision: https://reviews.llvm.org/D38214
Test plan: make check-all
llvm-svn: 314141
This patch introduces a class that can help to build tools that require cross
translation unit facilities. This class allows function definitions to be loaded
from external AST files based on an index. In order to use this functionality an
index is required. The index format is a flat text file but it might be
replaced with a different solution in the near future. USRs are used as names to
look up the functions definitions. This class also does caching to avoid
redundant loading of AST files.
Right now only function defnitions can be loaded using this API because this is
what the in progress cross translation unit feature of the Static Analyzer
requires. In to future this might be extended to classes, types etc.
Differential Revision: https://reviews.llvm.org/D34512
llvm-svn: 313975
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.
There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.
llvm-svn: 313729
overridden methods when compiling for non-ARC.
Previously, clang would error out when compiling for ARC, but didn't
print any diagnostics when compiling for non-ARC.
This was pointed out in the patch review for attribute noescape:
https://reviews.llvm.org/D32210
llvm-svn: 313717
Summary:
So far we used a value of 10 which was useful for testing but produces many false-positives in real programs. The usual suspicious clones we find seem to be at around a complexity value of 70 and for normal clone-reporting everything above 50 seems to be a valid normal clone for users, so let's just go with 50 for now and set this as the new default value.
This patch also explicitly sets the complexity value for the regression tests as they serve more of a regression testing/debugging purpose and shouldn't really be reported by default in real programs. I'll add more tests that reflect actual found bugs that then need to pass with the default setting in the future.
Reviewers: NoQ
Subscribers: cfe-commits, javed.absar, xazax.hun, v.g.vassilev
Differential Revision: https://reviews.llvm.org/D34178
llvm-svn: 312468
Replace "long" with __UINTPTR_TYPE__
to make the test added in rL311935 Windows-friendly.
Caught by the buildbot llvm-clang-x86_64-expensive-checks-win.
llvm-svn: 311947
This diff fixes modeling of arithmetic
expressions where pointers are treated as integers
(i.e. via C-style / reinterpret casts).
For now we return UnknownVal unless the operation is a comparison.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D37120
llvm-svn: 311935
This way the unrolling can be restricted for loops which will take at most a
given number of steps. It is defined as 128 in this patch and it seems to have
a good number for that purpose.
Differential Revision: https://reviews.llvm.org/D37181
llvm-svn: 311883
Added check if the execution of the last step of the given unrolled loop has
generated more branches. If yes, than treat it as a normal (non-unrolled) loop
in the remaining part of the analysis.
Differential Revision: https://reviews.llvm.org/D36962
llvm-svn: 311881
1. The LoopUnrolling feature needs the LoopExit included in the CFG so added this
dependency via the config options
2. The LoopExit element can be encountered even if we haven't encountered the
block of the corresponding LoopStmt. So the asserts were not right.
3. If we are caching out the Node then we get a nullptr from generateNode which
case was not handled.
Differential Revision: https://reviews.llvm.org/D37103
llvm-svn: 311880
Gabor Horvath