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

[NFC][Clang][test] Inclusive language: Remove and rephrase uses of sanity test/check in clang/test

Part of work to use more inclusive terms in clang/llvm.

[analyzer] Move analyzer-eagerly-assume to AnalyzerOptions, enable by default

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

llvm-svn: 340963

Implement C++ [basic.link]p8.

If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it

Implement C++ [basic.link]p8.

If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.

There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.

llvm-svn: 313729

show more ...

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

[analyzer] Drop explicit mention of range constraint solver

Summary: The basic constraint solver was dropped in rL162384, leaving the range constraint solver as the default and only constraint solve

[analyzer] Drop explicit mention of range constraint solver

Summary: The basic constraint solver was dropped in rL162384, leaving the range constraint solver as the default and only constraint solver. Explicitly specifying it is unnecessary, and makes it difficult to test with other solver backends.

Reviewers: zaks.anna, dcoughlin

Subscribers: cfe-commits

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

llvm-svn: 288372

show more ...

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

llvm-svn: 210372

[analyzer] Use the expression’s type instead of region’s type in ArrayToPointer decay evaluation

This gives slightly better precision, specifically, in cases where a non-typed region represents the

[analyzer] Use the expression’s type instead of region’s type in ArrayToPointer decay evaluation

This gives slightly better precision, specifically, in cases where a non-typed region represents the array
or when the type is a non-array type, which can happen when an array is a result of a reinterpret_cast.

llvm-svn: 182810

show more ...

[analyzer] Tweak getDerefExpr more to track DeclRefExprs to references.

In the committed example, we now see a note that tells us when the pointer
was assumed to be null.

This is the only case in w

[analyzer] Tweak getDerefExpr more to track DeclRefExprs to references.

In the committed example, we now see a note that tells us when the pointer
was assumed to be null.

This is the only case in which getDerefExpr returned null (failed to get
the dereferenced expr) throughout our regression tests. (There were multiple
occurrences of this one.)

llvm-svn: 179736

show more ...

Force a load when creating a reference to a temporary copied from a bitfield.

For this source:
const int &ref = someStruct.bitfield;

We used to generate this AST:

DeclStmt [...]
`-VarDecl [.

Force a load when creating a reference to a temporary copied from a bitfield.

For this source:
const int &ref = someStruct.bitfield;

We used to generate this AST:

DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'const int' lvalue <NoOp>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'

Notice the lvalue inside the MaterializeTemporaryExpr, which is very
confusing (and caused an assertion to fire in the analyzer - PR15694).

We now generate this:

DeclStmt [...]
`-VarDecl [...] ref 'const int &'
`-MaterializeTemporaryExpr [...] 'const int' lvalue
`-ImplicitCastExpr [...] 'int' <LValueToRValue>
`-MemberExpr [...] 'int' lvalue bitfield .bitfield [...]
`-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X'

Which makes a lot more sense. This allows us to remove code in both
CodeGen and AST that hacked around this special case.

The commit also makes Clang accept this (legal) C++11 code:

int &&ref = std::move(someStruct).bitfield

PR15694 / <rdar://problem/13600396>

llvm-svn: 179250

show more ...

[analyzer] Warn on passing a reference to null pointer as an argument in a call

Warn about null pointer dereference earlier when a reference to a null pointer is
passed in a call. The idea is that e

[analyzer] Warn on passing a reference to null pointer as an argument in a call

Warn about null pointer dereference earlier when a reference to a null pointer is
passed in a call. The idea is that even though the standard might allow this, reporting
the issue earlier is better for diagnostics (the error is reported closer to the place where
the pointer was set to NULL). This also simplifies analyzer’s diagnostic logic, which has
to track “where the null came from”. As a consequence, some of our null pointer
warning suppression mechanisms started triggering more often.

TODO: Change the name of the file and class to reflect the new check.
llvm-svn: 176612

show more ...

[analyzer] Check for returning null references in ReturnUndefChecker.

Officially in the C++ standard, a null reference cannot exist. However,
it's still very easy to create one:

int &getNullRef() {

[analyzer] Check for returning null references in ReturnUndefChecker.

Officially in the C++ standard, a null reference cannot exist. However,
it's still very easy to create one:

int &getNullRef() {
int *p = 0;
return *p;
}

We already check that binds to reference regions don't create null references.
This patch checks that we don't create null references by returning, either.

<rdar://problem/13364378>

llvm-svn: 176601

show more ...

[analyzer] Create a temporary region when accessing a struct rvalue.

In C++, rvalues that need to have their address taken (for example, to be
passed to a function by const reference) will be wrappe

[analyzer] Create a temporary region when accessing a struct rvalue.

In C++, rvalues that need to have their address taken (for example, to be
passed to a function by const reference) will be wrapped in a
MaterializeTemporaryExpr, which lets CodeGen know to create a temporary
region to store this value. However, MaterializeTemporaryExprs are /not/
created when a method is called on an rvalue struct, even though the 'this'
pointer needs a valid value. CodeGen works around this by creating a
temporary region anyway; now, so does the analyzer.

The analyzer also does this when accessing a field of a struct rvalue.
This is a little unfortunate, since the rest of the struct will soon be
thrown away, but it does make things consistent with the rest of the
analyzer.

This allows us to bring back the assumption that all known 'this' values
are Locs. This is a revised version of r164828-9, reverted in r164876-7.

<rdar://problem/12137950>

llvm-svn: 166120

show more ...

Revert "[analyzer] Create a temporary region for rvalue structs when accessing fields"

This reverts commit 6f61df3e7256413dcb99afb9673f4206e3c4992c.

llvm-svn: 164877

[analyzer] Create a temporary region for rvalue structs when accessing fields

Struct rvalues are represented in the analyzer by CompoundVals,
LazyCompoundVals, or plain ConjuredSymbols -- none of wh

[analyzer] Create a temporary region for rvalue structs when accessing fields

Struct rvalues are represented in the analyzer by CompoundVals,
LazyCompoundVals, or plain ConjuredSymbols -- none of which have associated
regions. If the entire structure is going to persist, this is not a
problem -- either the rvalue will be assigned to an existing region, or
a MaterializeTemporaryExpr will be present to create a temporary region.
However, if we just need a field from the struct, we need to create the
temporary region ourselves.

This is inspired by the way CodeGen handles calls to temporaries;
support for that in the analyzer is coming next.

Part of <rdar://problem/12137950>

llvm-svn: 164828

show more ...