[analyzer] Supply all checkers with a shouldRegister function

Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO)
function very similarly to ento::register##CHECKERNAME. T

[analyzer] Supply all checkers with a shouldRegister function

Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO)
function very similarly to ento::register##CHECKERNAME. This will force every
checker to implement this function, but maybe it isn't that bad: I saw a lot of
ObjC or C++ specific checkers that should probably not register themselves based
on some LangOptions (mine too), but they do anyways.

A big benefit of this is that all registry functions now register their checker,
once it is called, registration is guaranteed.

This patch is a part of a greater effort to reinvent checker registration, more
info here: D54438#1315953

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

llvm-svn: 352277

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[analyzer] MoveChecker: Add one more common resetting method, "append".

This is especially crucial for reports related to use-after-move of
standard library objects.

rdar://problem/47338505

Differ

[analyzer] MoveChecker: Add one more common resetting method, "append".

This is especially crucial for reports related to use-after-move of
standard library objects.

rdar://problem/47338505

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

llvm-svn: 351500

show more ...

[analyzer] MoveChecker: Squash the bit field because it causes a GCC warning.

The warning seems spurious (GCC bug 51242), but the bit field is
simply not worth the hassle.

rdar://problem/41349073

[analyzer] MoveChecker: Squash the bit field because it causes a GCC warning.

The warning seems spurious (GCC bug 51242), but the bit field is
simply not worth the hassle.

rdar://problem/41349073

llvm-svn: 349394

show more ...

[analyzer] MoveChecker: Add an option to suppress warnings on locals.

Re-using a moved-from local variable is most likely a bug because there's
rarely a good motivation for not introducing a separat

[analyzer] MoveChecker: Add an option to suppress warnings on locals.

Re-using a moved-from local variable is most likely a bug because there's
rarely a good motivation for not introducing a separate variable instead.
We plan to keep emitting such warnings by default.

Introduce a flag that allows disabling warnings on local variables that are
not of a known move-unsafe type. If it doesn't work out as we expected,
we'll just flip the flag.

We still warn on move-unsafe objects and unsafe operations on known move-safe
objects.

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

llvm-svn: 349327

show more ...

Speculatively re-apply "[analyzer] MoveChecker: Add checks for dereferencing..."

This re-applies commit r349226 that was reverted in r349233 due to failures
on clang-x64-windows-msvc.

Specify enum

Speculatively re-apply "[analyzer] MoveChecker: Add checks for dereferencing..."

This re-applies commit r349226 that was reverted in r349233 due to failures
on clang-x64-windows-msvc.

Specify enum type as unsigned for use in bit field. Otherwise overflows
may cause UB.

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

llvm-svn: 349326

show more ...

[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend

ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept.
It derives from CheckerRegistry, and is placed

[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend

ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept.
It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend,
whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can
imagine, used to circumvent the problem that the registry functions of the
checkers are located in the clangStaticAnalyzerCheckers library, but that
library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend
depends on both of those libraries.

One can make the observation however, that CheckerRegistry has no place in Core,
it isn't used there at all! The only place where it is used is Frontend, which
is where it ultimately belongs.

This move implies that since
include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function:

class CheckerRegistry;

void registerBuiltinCheckers(CheckerRegistry &registry);

it had to re purposed, as CheckerRegistry is no longer available to
clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h,
which actually describes it a lot better -- it does not contain the registration
functions for checkers, but only those generated by the tblgen files.

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

llvm-svn: 349275

show more ...

Revert "[analyzer] MoveChecker: Add checks for dereferencing a smart pointer..."

This reverts commit r349226.

Fails on an MSVC buildbot.

llvm-svn: 349233

[analyzer] MoveChecker: Add checks for dereferencing a smart pointer after move.

Calling operator*() or operator->() on a null STL smart pointer is
undefined behavior.

Smart pointers are specified

[analyzer] MoveChecker: Add checks for dereferencing a smart pointer after move.

Calling operator*() or operator->() on a null STL smart pointer is
undefined behavior.

Smart pointers are specified to become null after being moved from.
So we can't warn on arbitrary method calls, but these two operators
definitely make no sense.

The new bug is fatal because it's an immediate UB,
unlike other use-after-move bugs.

The work on a more generic null smart pointer dereference checker
is still pending.

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

llvm-svn: 349226

show more ...

[analyzer] MoveChecker: NFC: De-duplicate a few checks.

No functional change intended.

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

llvm-svn: 349225

[analyzer] MoveChecker Pt.6: Suppress the warning for the move-safe STL classes.

Some C++ standard library classes provide additional guarantees about their
state after move. Suppress warnings on su

[analyzer] MoveChecker Pt.6: Suppress the warning for the move-safe STL classes.

Some C++ standard library classes provide additional guarantees about their
state after move. Suppress warnings on such classes until a more precise
behavior is implemented. Warnings for locals are not suppressed anyway
because it's still most likely a bug.

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

llvm-svn: 349191

show more ...

[analyzer] MoveChecker: Improve invalidation policies.

If a moved-from object is passed into a conservatively evaluated function
by pointer or by reference, we assume that the function may reset its

[analyzer] MoveChecker: Improve invalidation policies.

If a moved-from object is passed into a conservatively evaluated function
by pointer or by reference, we assume that the function may reset its state.

Make sure it doesn't apply to const pointers and const references. Add a test
that demonstrates that it does apply to rvalue references.

Additionally, make sure that the object is invalidated when its contents change
for reasons other than invalidation caused by evaluating a call conservatively.
In particular, when the object's fields are manipulated directly, we should
assume that some sort of reset may be happening.

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

llvm-svn: 349190

show more ...

[analyzer] MoveChecker: Add more common state resetting methods.

Includes "resize" and "shrink" because they can reset the object to a known
state in certain circumstances.

Differential Revision: h

[analyzer] MoveChecker: Add more common state resetting methods.

Includes "resize" and "shrink" because they can reset the object to a known
state in certain circumstances.

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

llvm-svn: 348235

show more ...

[analyzer] MoveChecker: Improve warning and note messages.

The warning piece traditionally describes the bug itself, i.e.
"The bug is a _____", eg. "Attempt to delete released memory",
"Resource lea

[analyzer] MoveChecker: Improve warning and note messages.

The warning piece traditionally describes the bug itself, i.e.
"The bug is a _____", eg. "Attempt to delete released memory",
"Resource leak", "Method call on a moved-from object".

Event pieces produced by the visitor are usually in a present tense, i.e.
"At this moment _____": "Memory is released", "File is closed",
"Object is moved".

Additionally, type information is added into the event pieces for STL objects
(in order to highlight that it is in fact an STL object), and the respective
event piece now mentions that the object is left in an unspecified state
after it was moved, which is a vital piece of information to understand the bug.

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

llvm-svn: 348229

show more ...

[analyzer] MoveChecker: Restrict to locals and std:: objects.

In general case there use-after-move is not a bug. It depends on how the
move-constructor or move-assignment is implemented.

In STL, th

[analyzer] MoveChecker: Restrict to locals and std:: objects.

In general case there use-after-move is not a bug. It depends on how the
move-constructor or move-assignment is implemented.

In STL, the convention that applies to most classes is that the move-constructor
(-assignment) leaves an object in a "valid but unspecified" state. Using such
object without resetting it to a known state first is likely a bug. Objects

Local value-type variables are special because due to their automatic lifetime
there is no intention to reuse space. If you want a fresh object, you might
as well make a new variable, no need to move from a variable and than re-use it.
Therefore, it is not always a bug, but it is obviously easy to suppress when it
isn't, and in most cases it indeed is - as there's no valid intention behind
the intentional use of a local after move.

This applies not only to local variables but also to parameter variables,
not only of value type but also of rvalue reference type (but not to lvalue
references).

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

llvm-svn: 348210

show more ...

[analyzer] MoveChecker: NFC: Remove the workaround for the "zombie symbols" bug.

The checker had extra code to clean up memory regions that were sticking around
in the checker without ever being cle

[analyzer] MoveChecker: NFC: Remove the workaround for the "zombie symbols" bug.

The checker had extra code to clean up memory regions that were sticking around
in the checker without ever being cleaned up due to the bug that was fixed in
r347953. Because of that, if a region was moved from, then became dead,
and then reincarnated, there were false positives.

Why regions are even allowed to reincarnate is a separate story. Luckily, this
only happens for local regions that don't produce symbols when loaded from.

No functional change intended. The newly added test demonstrates that even
though no cleanup is necessary upon destructor calls, the early return
cannot be removed. It was not failing before the patch.

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

llvm-svn: 348208

show more ...

[analyzer] Rename MisusedMovedObjectChecker to MoveChecker

This follows the Static Analyzer's tradition to name checkers after
things in which they find bugs, not after bugs they find.

Differential

[analyzer] Rename MisusedMovedObjectChecker to MoveChecker

This follows the Static Analyzer's tradition to name checkers after
things in which they find bugs, not after bugs they find.

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

llvm-svn: 348201

show more ...