This patch fixed an issue where the dynamic type of pointer/reference
object was known by the analyzer, but wasn't obtained in the checker,
which resulted in false negatives. This should also increase reliability
of the checker, as derefencing is always done now according to the
dynamic type (even if that happens to be the same as the static type).
Special thanks to Artem Degrachev for setting me on the right track.
Differential Revision: https://reviews.llvm.org/D49199
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@339240 91177308-0d34-0410-b5e6-96231b3b80d8
Even for a checker being in alpha, some reports about pointees held so little
value to the user that it's safer to disable pointer/reference chasing for now.
It can be enabled with a new flag, in which case checker should function as it
has always been. This can be set with `CheckPointeeInitialization`.
Differential Revision: https://reviews.llvm.org/D49438
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@339135 91177308-0d34-0410-b5e6-96231b3b80d8
This reinstates r337627, reverted in r337671, with a fix to correctly
handle the lvalueness of array subscript expressions on pointers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@337726 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r337627.
After the change, clang started producing invalid warning on the following code:
struct foo {
foo(char *x) : x_(&x[10]) {}
private:
char *x_;
};
1.cpp:2:21: warning: initializing pointer member 'x_' with the stack address of parameter 'x' [-Wdangling-field]
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@337671 91177308-0d34-0410-b5e6-96231b3b80d8
This checker analyzes C++ constructor calls, and reports uninitialized fields.
Due to the nature of this problem (uninitialized fields after an object
construction), this checker doesn't search for bugs, but rather is a tool to
enforce a specific programming model where every field needs to be initialized.
This checker lands in alpha for now, and a number of followup patches will be
made to reduce false negatives and to make it easier for the user to understand
what rules the checker relies on, eg. whether a derived class' constructor is
responsible for initializing inherited data members or whether it should be
handled in the base class' constructor.
Differential Revision: https://reviews.llvm.org/D45532
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334935 91177308-0d34-0410-b5e6-96231b3b80d8
Kristof Umann