Reland "[analyzer] Deprecate `-analyzer-store region` flag"

I'm trying to remove unused options from the `Analyses.def` file, then
merge the rest of the useful options into the `AnalyzerOptions.def`

Reland "[analyzer] Deprecate `-analyzer-store region` flag"

I'm trying to remove unused options from the `Analyses.def` file, then
merge the rest of the useful options into the `AnalyzerOptions.def`.
Then make sure one can set these by an `-analyzer-config XXX=YYY` style
flag.
Then surface the `-analyzer-config` to the `clang` frontend;

After all of this, we can pursue the tablegen approach described
https://discourse.llvm.org/t/rfc-tablegen-clang-static-analyzer-engine-options-for-better-documentation/61488

In this patch, I'm proposing flag deprecations.
We should support deprecated analyzer flags for exactly one release. In
this case I'm planning to drop this flag in `clang-16`.

In the clang frontend, now we won't pass this option to the cc1
frontend, rather emit a warning diagnostic reminding the users about
this deprecated flag, which will be turned into error in clang-16.

Unfortunately, I had to remove all the tests referring to this flag,
causing a mass change. I've also added a test for checking this warning.

I've seen that `scan-build` also uses this flag, but I think we should
remove that part only after we turn this into a hard error.

Reviewed By: martong

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

show more ...

Revert "[analyzer] Deprecate `-analyzer-store region` flag"

This reverts commit d50d9946d1d7e5f20881f0bc71fbd025040b1c96.
Broke check-clang, see comments on https://reviews.llvm.org/D126067

Also re

Revert "[analyzer] Deprecate `-analyzer-store region` flag"

This reverts commit d50d9946d1d7e5f20881f0bc71fbd025040b1c96.
Broke check-clang, see comments on https://reviews.llvm.org/D126067

Also revert dependent change "[analyzer] Deprecate the unused 'analyzer-opt-analyze-nested-blocks' cc1 flag"
This reverts commit 07b4a6d0461fe64e10d30029ed3d598e49ca3810.

Also revert "[analyzer] Fix buildbots after introducing a new frontend warning"
This reverts commit 90374df15ddc58d823ca42326a76f58e748f20eb.
(See https://reviews.llvm.org/rG90374df15ddc58d823ca42326a76f58e748f20eb)

show more ...

[analyzer] Deprecate `-analyzer-store region` flag

I'm trying to remove unused options from the `Analyses.def` file, then
merge the rest of the useful options into the `AnalyzerOptions.def`.
Then ma

[analyzer] Deprecate `-analyzer-store region` flag

I'm trying to remove unused options from the `Analyses.def` file, then
merge the rest of the useful options into the `AnalyzerOptions.def`.
Then make sure one can set these by an `-analyzer-config XXX=YYY` style
flag.
Then surface the `-analyzer-config` to the `clang` frontend;

After all of this, we can pursue the tablegen approach described
https://discourse.llvm.org/t/rfc-tablegen-clang-static-analyzer-engine-options-for-better-documentation/61488

In this patch, I'm proposing flag deprecations.
We should support deprecated analyzer flags for exactly one release. In
this case I'm planning to drop this flag in `clang-16`.

In the clang frontend, now we won't pass this option to the cc1
frontend, rather emit a warning diagnostic reminding the users about
this deprecated flag, which will be turned into error in clang-16.

Unfortunately, I had to remove all the tests referring to this flag,
causing a mass change. I've also added a test for checking this warning.

I've seen that `scan-build` also uses this flag, but I think we should
remove that part only after we turn this into a hard error.

Reviewed By: martong

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

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

Fold -Wreturn-stack-address into general initialization lifetime
checking.

llvm-svn: 337743

Reland 4: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and pe

Reland 4: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

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

llvm-svn: 296895

show more ...

Revert "Reland 3: [analyzer] NFC: Update test infrastructure to support multiple constraint managers"

This reverts commit ea36f1406e1f36bf456c3f3929839b024128e468.

llvm-svn: 296841

Reland 3: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and pe

Reland 3: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

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

llvm-svn: 296837

show more ...

Revert "Reland 2: [analyzer] NFC: Update test infrastructure to support multiple constraint managers"

This reverts commit f93343c099fff646a2314cc7f4925833708298b1.

llvm-svn: 296836

Reland 2: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and pe

Reland 2: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

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

llvm-svn: 296835

show more ...

Revert "Reland: [analyzer] NFC: Update test infrastructure to support multiple constraint managers"

This reverts commit 1b28d0b10e1c8feccb971abb6ef7a18bee589830.

llvm-svn: 296422

Reland: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perf

Reland: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

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

llvm-svn: 296414

show more ...

Revert "[analyzer] NFC: Update test infrastructure to support multiple constraint managers"

This reverts commit 8e7780b9e59ddaad1800baf533058d2c064d4787.

llvm-svn: 296317

[analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runt

[analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

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

llvm-svn: 296312

show more ...

Add -Wtautological-undefined-compare and -Wundefined-bool-conversion warnings
to detect underfined behavior involving pointers.

llvm-svn: 210372

[analyzer] Fix FP warnings when binding a temporary to a local static variable

Summary:
When binding a temporary object to a static local variable, the analyzer would
complain about a dangling refer

[analyzer] Fix FP warnings when binding a temporary to a local static variable

Summary:
When binding a temporary object to a static local variable, the analyzer would
complain about a dangling reference even though the temporary's lifetime should
be extended past the end of the function. This commit tries to detect these
cases and construct them in a global memory region instead of a local one.

Reviewers: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1133

llvm-svn: 187196

show more ...

Re-apply "[analyzer] Model casts to bool differently from other numbers."

This doesn't appear to be the cause of the slowdown. I'll have to try a
manual bisect to see if there's really anything ther

Re-apply "[analyzer] Model casts to bool differently from other numbers."

This doesn't appear to be the cause of the slowdown. I'll have to try a
manual bisect to see if there's really anything there, or if it's just
the bot itself taking on additional load. Meanwhile, this change helps
with correctness.

This changes an assertion and adds a test case, then re-applies r180638,
which was reverted in r180714.

<rdar://problem/13296133> and PR15863

llvm-svn: 180864

show more ...

Revert "[analyzer] Model casts to bool differently from other numbers."

This seems to be causing quite a slowdown on our internal analyzer bot,
and I'm not sure why. Needs further investigation.

Th

Revert "[analyzer] Model casts to bool differently from other numbers."

This seems to be causing quite a slowdown on our internal analyzer bot,
and I'm not sure why. Needs further investigation.

This reverts r180638 / 9e161ea981f22ae017b6af09d660bfc3ddf16a09.

llvm-svn: 180714

show more ...

[analyzer] Model casts to bool differently from other numbers.

Casts to bool (and _Bool) are equivalent to checks against zero,
not truncations to 1 bit or 8 bits.

This improved reasoning does caus

[analyzer] Model casts to bool differently from other numbers.

Casts to bool (and _Bool) are equivalent to checks against zero,
not truncations to 1 bit or 8 bits.

This improved reasoning does cause a change in the behavior of the alpha
BoolAssignment checker. Previously, this checker complained about statements
like "bool x = y" if 'y' was known not to be 0 or 1. Now it does not, since
that conversion is well-defined. It's hard to say what the "best" behavior
here is: this conversion is safe, but might be better written as an explicit
comparison against zero.

More usefully, besides improving our model of booleans, this fixes spurious
warnings when returning the address of a local variable cast to bool.

<rdar://problem/13296133>

llvm-svn: 180638

show more ...

[analyzer] Make sure a materialized temporary matches its bindings.

This is a follow-up to r175830, which made sure a temporary object region
created for, say, a struct rvalue matched up with the in

[analyzer] Make sure a materialized temporary matches its bindings.

This is a follow-up to r175830, which made sure a temporary object region
created for, say, a struct rvalue matched up with the initial bindings
being stored into it. This does the same for the case in which the AST
actually tells us that we need to create a temporary via a
MaterializeObjectExpr. I've unified the two code paths and moved a static
helper function onto ExprEngine.

This also caused a bit of test churn, causing us to go back to describing
temporary regions without a 'const' qualifier. This seems acceptable; it's
our behavior from a few months ago.

<rdar://problem/13265460> (part 2)

llvm-svn: 175854

show more ...

Fix regression in modeling assignments of an address of a variable to itself. Fixes <rdar://problem/13226577>.

llvm-svn: 175852

Better wording for reference self-initialization warning.

llvm-svn: 162198

Warn about self-initialization of references.

Initializing a reference with itself, e.g. "int &a = a;" seems like a
very bad idea.

llvm-svn: 162093

When going through references to check if the function returns the address
of a local variable, make sure we don't infinitely recurse when the
reference binds to itself.

e.g:

int* func() {
int&

When going through references to check if the function returns the address
of a local variable, make sure we don't infinitely recurse when the
reference binds to itself.

e.g:

int* func() {
int& i = i; // assign non-exist variable to a reference which has same name.
return &i; // return pointer
}

rdar://11345441

llvm-svn: 155856

show more ...

Fix LiveVariables analysis bug with MaterializeTemporaryExpr and fix handling in ExprEngine. Fixes <rdar://problem/10201666>.

llvm-svn: 140956