[analyzer] Handle builtin functions in MallocChecker (#88416)

This commit ensures that the `CallDescription`s in `MallocChecker` are
matched with the mode `CDM::CLibrary`, so:
- they don't match m

[analyzer] Handle builtin functions in MallocChecker (#88416)

This commit ensures that the `CallDescription`s in `MallocChecker` are
matched with the mode `CDM::CLibrary`, so:
- they don't match methods or functions within user-defined namespaces;
- they also match builtin variants of these functions (if any), so the
checker can model `__builtin_alloca()` like `alloca()`.

This change fixes https://github.com/llvm/llvm-project/issues/81597. New
tests were added to verify that `std::malloc` and `std::free` (from
`<cstdlib>`) are modeled, but a method that's named e.g. `free` isn't
confused with the memory release function.

The responsibility for modeling `__builtin_alloca` and
`__builtin_alloca_with_align` was moved from `BuiltinFunctionChecker` to
`MallocChecker`, to avoid buggy interactions between the checkers and
ensure that the builtin and non-builtin variants are handled by exactly
the same logic.

This change might be a step backwards for the users who don't have
`unix.Malloc` enabled; but I suspect that `__builtin_alloca()` is so
rare that it would be a waste of time to implement backwards
compatibility for them.

There were several test files that relied on `__builtin_alloca()` calls
to get an `AllocaRegion`, these were modified to enable `unix.Malloc`.
One of these files (cxx-uninitialized-object-ptr-ref.cpp) had some tests
that relied on the fact that `malloc()` was treated as a "black box" in
them, these were updated to use `calloc()` (to get initialized memory)
and `free()` (to avoid memory leak reports).

While I was developing this change, I found a very suspicious assert in
`MallocChecker`. As it isn't blocking the goals of this commit, I just
marked it with a FIXME, but I'll try to investigate and fix it in a
follow-up change.

show more ...

[analyzer] Catch leaking stack addresses via stack variables

Not only global variables can hold references to dead stack variables.
Consider this example:

void write_stack_address_to(char **q) {

[analyzer] Catch leaking stack addresses via stack variables

Not only global variables can hold references to dead stack variables.
Consider this example:

void write_stack_address_to(char **q) {
char local;
*q = &local;
}

void test_stack() {
char *p;
write_stack_address_to(&p);
}

The address of 'local' is assigned to 'p', which becomes a dangling
pointer after 'write_stack_address_to()' returns.

The StackAddrEscapeChecker was looking for bindings in the store which
referred to variables of the popped stack frame, but it only considered
global variables in this regard. This patch relaxes this, catching
stack variable bindings as well.

---

This patch also works for temporary objects like:

struct Bar {
const int &ref;
explicit Bar(int y) : ref(y) {
// Okay.
} // End of the constructor call, `ref` is dangling now. Warning!
};

void test() {
Bar{33}; // Temporary object, so the corresponding memregion is
// *not* a VarRegion.
}

---

The return value optimization aka. copy-elision might kick in but that
is modeled by passing an imaginary CXXThisRegion which refers to the
parent stack frame which is supposed to be the 'return slot'.
Objects residing in the 'return slot' outlive the scope of the inner
call, thus we should expect no warning about them - except if we
explicitly disable copy-elision.

Reviewed By: NoQ, martong

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

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

[analyzer][UninitializedObjectChecker] Uninit regions are only reported once

Especially with pointees, a lot of meaningless reports came from uninitialized
regions that were already reported. This i

[analyzer][UninitializedObjectChecker] Uninit regions are only reported once

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

show more ...

[analyzer][UninitializedObjectChecker] Reports Loc fields pointing to themselves

I've added a new functionality, the checker is now able to
detect and report fields pointing to themselves. I figured

[analyzer][UninitializedObjectChecker] Reports Loc fields pointing to themselves

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

show more ...

[analyzer] Attempt to make a windows buildbot happy.

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::LocAsInteger

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

llvm-svn: 342221

[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 p6.: Move dereferencing to a function

Now that it has it's own file, it makes little sense for
isPointerOrReferenceUninit to be this large, so I mo

[analyzer][UninitializedObjectChecker] Refactoring p6.: Move dereferencing 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

show more ...

[analyzer][UninitializedObjectChecker] Void pointers are casted back to their dynamic type in note message

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

llvm-svn: 339653

[analyzer][UninitializedObjectChecker] Pointer/reference objects are dereferenced according to dynamic type

This patch fixed an issue where the dynamic type of pointer/reference
object was known by

[analyzer][UninitializedObjectChecker] Pointer/reference objects are 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

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

Fold dangling-field warning into general initialization lifetime checks.

This reinstates r337627, reverted in r337671, with a fix to correctly
handle the lvalueness of array subscript expressions on

Fold dangling-field warning into general initialization lifetime checks.

This reinstates r337627, reverted in r337671, with a fix to correctly
handle the lvalueness of array subscript expressions on pointers.

llvm-svn: 337726

show more ...

Revert "Fold dangling-field warning into general initialization lifetime checks."

This reverts commit r337627.
After the change, clang started producing invalid warning on the following code:
st

Revert "Fold dangling-field warning into general initialization lifetime 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

show more ...

Fold dangling-field warning into general initialization lifetime checks.

llvm-svn: 337627

[analyzer][UninitializedObjectChecker] Support for MemberPointerTypes

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

llvm-svn: 336994

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