summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis/cxx-uninitialized-object-ptr-ref.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer][UninitializedObjectChecker] PR41611: Regard vector types as primitiveKristof Umann2019-04-301-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugs.llvm.org/show_bug.cgi?id=41611 Similarly to D61106, the checker ran over an llvm_unreachable for vector types: struct VectorSizeLong { VectorSizeLong() {} __attribute__((__vector_size__(16))) long x; }; void __vector_size__LongTest() { VectorSizeLong v; } Since, according to my short research, "The vector_size attribute is only applicable to integral and float scalars, although arrays, pointers, and function return values are allowed in conjunction with this construct." [src: https://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Vector-Extensions.html#Vector-Extensions] vector types are safe to regard as primitive. Differential Revision: https://reviews.llvm.org/D61246 llvm-svn: 359539
* [analyzer] Move UninitializedObjectChecker out of alphaKristof Umann2019-04-191-5/+5
| | | | | | | | | Moved UninitializedObjectChecker from the 'alpha.cplusplus' to the 'optin.cplusplus' package. Differential Revision: https://reviews.llvm.org/D58573 llvm-svn: 358797
* [analyzer][UninitializedObjectChecker] Uninit regions are only reported onceKristof Umann2018-11-181-0/+41
| | | | | | | | | | Especially with pointees, a lot of meaningless reports came from uninitialized regions that were already reported. This is fixed by storing all reported fields to the GDM. Differential Revision: https://reviews.llvm.org/D51531 llvm-svn: 347153
* [analyzer][UninitializedObjectChecker] Reports Loc fields pointing to themselvesKristof Umann2018-10-111-6/+11
| | | | | | | | | | | I've added a new functionality, the checker is now able to detect and report fields pointing to themselves. I figured this would fit well into the checker as there's no reason for a pointer to point to itself instead of being nullptr. Differential Revision: https://reviews.llvm.org/D51305 llvm-svn: 344242
* [analyzer] Attempt to make a windows buildbot happy.Kristof Umann2018-09-141-1/+1
| | | | | | | Got an error that a cast is happening from a pointer type to long, which is smaller. llvm-svn: 342223
* [analyzer][UninitializedObjectChecker] Support for nonloc::LocAsIntegerKristof Umann2018-09-141-0/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D49437 llvm-svn: 342221
* [analyzer][UninitializedObjectChecker] Fixed dereferencingKristof Umann2018-09-141-5/+87
| | | | | | | | | | iThis patch aims to fix derefencing, which has been debated for months now. Instead of working with SVals, the function now relies on TypedValueRegion. Differential Revision: https://reviews.llvm.org/D51057 llvm-svn: 342213
* [analyzer][UninitializedObjectChecker] Refactoring p6.: Move dereferencing ↵Kristof Umann2018-08-211-4/+17
| | | | | | | | | | | | to a function Now that it has it's own file, it makes little sense for isPointerOrReferenceUninit to be this large, so I moved dereferencing to a separate function. Differential Revision: https://reviews.llvm.org/D50509 llvm-svn: 340265
* [analyzer][UninitializedObjectChecker] Void pointers are casted back to ↵Kristof Umann2018-08-141-6/+6
| | | | | | | | their dynamic type in note message Differential Revision: https://reviews.llvm.org/D49228 llvm-svn: 339653
* [analyzer][UninitializedObjectChecker] Pointer/reference objects are ↵Kristof Umann2018-08-081-2/+51
| | | | | | | | | | | | | | | | dereferenced according to dynamic type 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 llvm-svn: 339240
* [analyzer][UninitializedObjectChecker] New flag to turn off dereferencingKristof Umann2018-08-071-3/+8
| | | | | | | | | | | 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 llvm-svn: 339135
* Fold dangling-field warning into general initialization lifetime checks.Richard Smith2018-07-231-6/+6
| | | | | | | This reinstates r337627, reverted in r337671, with a fix to correctly handle the lvalueness of array subscript expressions on pointers. llvm-svn: 337726
* Revert "Fold dangling-field warning into general initialization lifetime ↵Ilya Biryukov2018-07-231-6/+6
| | | | | | | | | | | | | | | | checks." 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] llvm-svn: 337671
* Fold dangling-field warning into general initialization lifetime checks.Richard Smith2018-07-201-6/+6
| | | | llvm-svn: 337627
* [analyzer][UninitializedObjectChecker] Support for MemberPointerTypesKristof Umann2018-07-131-8/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D48325 llvm-svn: 336994
* [analyzer] Checker for uninitialized C++ objectsKristof Umann2018-06-181-0/+699
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 llvm-svn: 334935
OpenPOWER on IntegriCloud