In order to provide more test coverage for inlined operator new(), add more
run-lines to existing test cases, which would trigger our fake header
to provide a body for operator new(). Most of the code should still behave
reasonably. When behavior intentionally changes, #ifs are provided.
Differential Revision: https://reviews.llvm.org/D42221
llvm-svn: 323376
This allows the analyzer to analyze ("inline") custom operator new() calls and,
even more importantly, inline constructors of objects that were allocated
by any operator new() - not necessarily a custom one.
All changes in the tests in the current commit are intended improvements,
even if they didn't carry any explicit FIXME flag.
It is possible to restore the old behavior via
-analyzer-config c++-allocator-inlining=false
(this flag is supported by scan-build as well, and it can be into a clang
--analyze invocation via -Xclang .. -Xclang ..). There is no intention to
remove the old behavior for now.
Differential Revision: https://reviews.llvm.org/D42219
rdar://problem/12180598
llvm-svn: 323373
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
This diff fixes analyzer's crash (triggered assert) on the newly added test case.
The assert being discussed is assert(!B.lookup(R, BindingKey::Direct))
in lib/StaticAnalyzer/Core/RegionStore.cpp, however the root cause is different.
For classes with empty bases the offsets might be tricky.
For example, let's assume we have
struct S: NonEmptyBase, EmptyBase {
...
};
In this case Clang applies empty base class optimization and
the offset of EmptyBase will be 0, it can be verified via
clang -cc1 -x c++ -v -fdump-record-layouts main.cpp -emit-llvm -o /dev/null.
When the analyzer tries to perform zero initialization of EmptyBase
it will hit the assert because that region
has already been "written" by the constructor of NonEmptyBase.
Test plan:
make check-all
Differential revision: https://reviews.llvm.org/D36851
llvm-svn: 311182
The constructor that comes right before a variable declaration in the CFG might
not be the initialization of that variable. Previously, we just checked that
the variable's initializer expression was different from the construction
expression, but forgot to see whether the variable had an initializer expression
at all.
Thanks for the prompting, David.
llvm-svn: 207562
RegionStore tries to protect against accidentally initializing the same
region twice, but it doesn't take subregions into account very well. If
the outer region being initialized is a struct with an empty base class,
the offset of the first field in the struct will be 0. When we initialize
the base class, we may invalidate the contents of the struct by providing
a default value of Unknown (or some new symbol). We then go to initialize
the member with a zeroing constructor, only to find that the region at
that offset in the struct already has a value. The best we can do here is
to invalidate that value and continue; neither the old default value nor
the new 0 is correct for the entire struct after the member constructor call.
The correct solution for this is to track region extents in the store.
<rdar://problem/14914316>
llvm-svn: 190530
Previously, the use of a std::initializer_list (actually, a
CXXStdInitializerListExpr) would cause the analyzer to give up on the rest
of the path. Now, it just uses an opaque symbolic value for the
initializer_list and continues on.
At some point in the future we can add proper support for initializer_list,
with access to the elements in the InitListExpr.
<rdar://problem/14340207>
llvm-svn: 186519
Re-apply r184511, reverted in r184561, with the trivial default constructor
fast path removed -- it turned out not to be necessary here.
Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.
<rdar://problem/14212563>
llvm-svn: 184815
Per review from Anna, this really should have been two commits, and besides
it's causing problems on our internal buildbot. Reverting until these have
been worked out.
This reverts r184511 / 98123284826bb4ce422775563ff1a01580ec5766.
llvm-svn: 184561
Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.
As a bonus, trivial default constructors are now no longer inlined; they
are instead processed explicitly by ExprEngine. This has a (positive)
effect on the generated path edges: they no longer stop at a default
constructor call unless there's a user-provided implementation.
<rdar://problem/14212563>
llvm-svn: 184511
Artem Dergachev