summaryrefslogtreecommitdiffstats
path: root/clang/test/Analysis/cxx-uninitialized-object.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] PR41753: Include complex integer types in NonLoc::isCompoundTypeKristof Umann2019-05-181-12/+9
| | | | | | | | https://bugs.llvm.org/show_bug.cgi?id=41753 Differential Revision: https://reviews.llvm.org/D61570 llvm-svn: 361099
* [analyzer][UninitializedObjectChecker] PR41741: Regard all scalar types as ↵Kristof Umann2019-05-051-6/+35
| | | | | | | | | | | | | | | | | | | | primitive. https://bugs.llvm.org/show_bug.cgi?id=41741 Pretty much the same as D61246 and D61106, this time for __complex__ types. Upon further investigation, I realized that we should regard all types Type::isScalarType returns true for as primitive, so I merged isMemberPointerType(), isBlockPointerType() and isAnyComplexType()` into that instead. I also stumbled across yet another bug, https://bugs.llvm.org/show_bug.cgi?id=41753, but it seems to be unrelated to this checker. Differential Revision: https://reviews.llvm.org/D61569 llvm-svn: 359998
* [analyzer][UninitializedObjectChecker] PR41611: Regard vector types as primitiveKristof Umann2019-04-301-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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][UninitializedObjectChecker] PR41590: Regard _Atomic types as ↵Kristof Umann2019-04-251-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | primitive https://bugs.llvm.org/show_bug.cgi?id=41590 For the following code snippet, UninitializedObjectChecker crashed: struct MyAtomicInt { _Atomic(int) x; MyAtomicInt() {} }; void entry() { MyAtomicInt b; } The problem was that _Atomic types were not regular records, unions, dereferencable or primitive, making the checker hit the llvm_unreachable at lib/StaticAnalyzer/Checkers/UninitializedObject/UninitializedObjectChecker.cpp:347. The solution is to regard these types as primitive as well. The test case shows that with this addition, not only are we able to get rid of the crash, but we can identify x as uninitialized. Differential Revision: https://reviews.llvm.org/D61106 llvm-svn: 359230
* [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
* Revert "[analyzer] Toning down invalidation a bit".Artem Dergachev2019-04-031-2/+3
| | | | | | | | | | | | | | | This reverts commit r352473. The overall idea is great, but it seems to cause unintented consequences when not only Region Store invalidation but also pointer escape mechanism was accidentally affected. Based on discussions in https://reviews.llvm.org/D58121#1452483 and https://reviews.llvm.org/D57230#1434161 Differential Revision: https://reviews.llvm.org/D57230 llvm-svn: 357620
* [analyzer] Toning down invalidation a bitGabor Horvath2019-01-291-3/+2
| | | | | | | | | When a function takes the address of a field the analyzer will no longer assume that the function will change other fields of the enclosing structs. Differential Revision: https://reviews.llvm.org/D57230 llvm-svn: 352473
* [analyzer][UninitializedObjectChecker] Fixed dereferencingKristof Umann2018-09-141-8/+33
| | | | | | | | | | 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 p4.: Wrap FieldRegions ↵Kristof Umann2018-08-131-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and reduce weight on FieldChainInfo Before this patch, FieldChainInfo used a spaghetti: it took care of way too many cases, even though it was always meant as a lightweight wrapper around ImmutableList<const FieldRegion *>. This problem is solved by introducing a lightweight polymorphic wrapper around const FieldRegion *, FieldNode. It is an interface that abstracts away special cases like pointers/references, objects that need to be casted to another type for a proper note messages. Changes to FieldChainInfo: * Now wraps ImmutableList<const FieldNode &>. * Any pointer/reference related fields and methods were removed * Got a new add method. This replaces it's former constructors as a way to create a new FieldChainInfo objects with a new element. Changes to FindUninitializedField: * In order not to deal with dynamic memory management, when an uninitialized field is found, the note message for it is constructed and is stored instead of a FieldChainInfo object. (see doc around addFieldToUninits). Some of the test files are changed too, from now on uninitialized pointees of references always print "uninitialized pointee" instead of "uninitialized field" (which should've really been like this from the beginning). I also updated every comment according to these changes. Differential Revision: https://reviews.llvm.org/D50506 llvm-svn: 339599
* [analyzer][UninitializedObjectChecker] Fixed a false negative by no longer ↵Kristof Umann2018-08-081-4/+3
| | | | | | | | | | | | | | | | | filtering out certain constructor calls As of now, all constructor calls are ignored that are being called by a constructor. The point of this was not to analyze the fields of an object, so an uninitialized field wouldn't be reported multiple times. This however introduced false negatives when the two constructors were in no relation to one another -- see the test file for a neat example for this with singletons. This patch aims so fix this issue. Differential Revision: https://reviews.llvm.org/D48436 llvm-svn: 339237
* [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
* [analyzer][UninitializedObjectChecker] Fixed captured lambda variable nameKristof Umann2018-07-131-3/+48
| | | | | | Differential Revision: https://reviews.llvm.org/D48291 llvm-svn: 336995
* [analyzer] Checker for uninitialized C++ objectsKristof Umann2018-06-181-0/+1058
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