Revert "[Analyzer][CFG] Correctly handle rebuilt default arg and default init expression (#91879)" (#94597)

This depends on https://github.com/llvm/llvm-project/pull/92527 which
needs to be reverte

Revert "[Analyzer][CFG] Correctly handle rebuilt default arg and default init expression (#91879)" (#94597)

This depends on https://github.com/llvm/llvm-project/pull/92527 which
needs to be reverted due to
https://github.com/llvm/llvm-project/pull/92527#issuecomment-2149120420.

This reverts commit 905b402a5d8f1490d668f40942390ebd6e87aa8f.

Co-authored-by: Bogdan Graur <bgraur@google.com>

show more ...

[Analyzer][CFG] Correctly handle rebuilt default arg and default init expression (#91879)

Depends on https://github.com/llvm/llvm-project/pull/92527

Clang now support the following:
- Extending

[Analyzer][CFG] Correctly handle rebuilt default arg and default init expression (#91879)

Depends on https://github.com/llvm/llvm-project/pull/92527

Clang now support the following:
- Extending lifetime of object bound to reference members of aggregates,
that are created from default member initializer.
- Rebuild `CXXDefaultArgExpr` and `CXXDefaultInitExpr` as needed where
called or constructed.

But CFG and ExprEngine need to be updated to address this change.

This PR add `CXXDefaultArgExpr` and `CXXDefaultInitExpr` into CFG, and
correct handle these expressions in ExprEngine

---------

Signed-off-by: yronglin <yronglin777@gmail.com>

show more ...

[analyzer] PR41753: Include complex integer types in NonLoc::isCompoundType

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 primitive.

https://bugs.llvm.org/show_bug.cgi?id=41741

Pretty much the same as D61246 and D61106, this time for __complex_

[analyzer][UninitializedObjectChecker] PR41741: Regard all scalar types as 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

show more ...

[analyzer][UninitializedObjectChecker] PR41611: Regard vector types as primitive

https://bugs.llvm.org/show_bug.cgi?id=41611

Similarly to D61106, the checker ran over an llvm_unreachable for vector

[analyzer][UninitializedObjectChecker] PR41611: Regard vector types as primitive

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

show more ...

[analyzer][UninitializedObjectChecker] PR41590: Regard _Atomic types as primitive

https://bugs.llvm.org/show_bug.cgi?id=41590

For the following code snippet, UninitializedObjectChecker crashed:

st

[analyzer][UninitializedObjectChecker] PR41590: Regard _Atomic types as 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

show more ...

[analyzer] Move UninitializedObjectChecker out of alpha

Moved UninitializedObjectChecker from the 'alpha.cplusplus' to the
'optin.cplusplus' package.

Differential Revision: https://reviews.llvm.org

[analyzer] Move UninitializedObjectChecker out of alpha

Moved UninitializedObjectChecker from the 'alpha.cplusplus' to the
'optin.cplusplus' package.

Differential Revision: https://reviews.llvm.org/D58573

llvm-svn: 358797

show more ...

Revert "[analyzer] Toning down invalidation a bit".

This reverts commit r352473.

The overall idea is great, but it seems to cause unintented consequences
when not only Region Store invalidation but

Revert "[analyzer] Toning down invalidation a bit".

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

show more ...

[analyzer] Toning down invalidation a bit

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.

Differ

[analyzer] Toning down invalidation a bit

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

show more ...

[analyzer][UninitializedObjectChecker] Fixed dereferencing

iThis patch aims to fix derefencing, which has been debated for months now.

Instead of working with SVals, the function now relies on Type

[analyzer][UninitializedObjectChecker] Fixed dereferencing

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

show more ...

[analyzer][UninitializedObjectChecker] Refactoring p4.: Wrap FieldRegions and reduce weight on FieldChainInfo

Before this patch, FieldChainInfo used a spaghetti: it took care of way too many cases,

[analyzer][UninitializedObjectChecker] Refactoring p4.: Wrap FieldRegions 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

show more ...

[analyzer][UninitializedObjectChecker] Fixed a false negative by no longer filtering out certain constructor calls

As of now, all constructor calls are ignored that are being called
by a constructor

[analyzer][UninitializedObjectChecker] Fixed a false negative by no longer 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

show more ...

[analyzer][UninitializedObjectChecker] New flag to turn off dereferencing

Even for a checker being in alpha, some reports about pointees held so little
value to the user that it's safer to disable p

[analyzer][UninitializedObjectChecker] New flag to turn off dereferencing

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

show more ...

[analyzer][UninitializedObjectChecker] Fixed captured lambda variable name

Differential Revision: https://reviews.llvm.org/D48291

llvm-svn: 336995

[analyzer] Checker for uninitialized C++ objects

This checker analyzes C++ constructor calls, and reports uninitialized fields.

Due to the nature of this problem (uninitialized fields after an obje

[analyzer] Checker for uninitialized C++ objects

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

show more ...