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

Port getLocStart -> getBeginLoc

Reviewers: teemperor!

Subscribers: jholewinski, whisperity, jfb, cfe-commits

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

llvm-svn: 339385

Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338291

[analyzer] Make checkEndFunction() give access to the return statement.

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

llvm-svn: 337215

[analyzer] [NFC] A convenient getter for getting a current stack frame

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

llvm-svn: 335701

[analyzer] introduce getSVal(Stmt *) helper on ExplodedNode, make sure the helper is used consistently

In most cases using
`N->getState()->getSVal(E, N->getLocationContext())`
is ugly, verbose, and

[analyzer] introduce getSVal(Stmt *) helper on ExplodedNode, make sure the helper is used consistently

In most cases using
`N->getState()->getSVal(E, N->getLocationContext())`
is ugly, verbose, and also opens up more surface area for bugs if an
inconsistent location context is used.

This patch introduces a helper on an exploded node, and ensures
consistent usage of either `ExplodedNode::getSVal` or
`CheckContext::getSVal` across the codebase.
As a result, a large number of redundant lines is removed.

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

llvm-svn: 322753

show more ...

[analyzer] StackAddrEscape: For now, disable the new async escape checks.

The new check introduced in r318705 is useful, but suffers from a particular
class of false positives, namely, it does not a

[analyzer] StackAddrEscape: For now, disable the new async escape checks.

The new check introduced in r318705 is useful, but suffers from a particular
class of false positives, namely, it does not account for
dispatch_barrier_sync() API which allows one to ensure that the asyncronously
executed block that captures a pointer to a local variable does not actually
outlive that variable.

The new check is split into a separate checker, under the name of
alpha.core.StackAddressAsyncEscape, which is likely to get enabled by default
again once these positives are fixed. The rest of the StackAddressEscapeChecker
is still enabled by default.

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

llvm-svn: 320455

show more ...

[analyzer] Diagnose stack leaks via block captures

This diff extends StackAddrEscapeChecker
to catch stack addresses leaks via block captures
if the block is executed asynchronously or
returned from

[analyzer] Diagnose stack leaks via block captures

This diff extends StackAddrEscapeChecker
to catch stack addresses leaks via block captures
if the block is executed asynchronously or
returned from a function.

Differential revision: https://reviews.llvm.org/D39438

llvm-svn: 318705

show more ...

[Analyzer] Correct stack address escape diagnostic

Summary:
Leaking a stack address via a static variable refers to it in the diagnostic as a 'global'. This patch corrects the diagnostic for static

[Analyzer] Correct stack address escape diagnostic

Summary:
Leaking a stack address via a static variable refers to it in the diagnostic as a 'global'. This patch corrects the diagnostic for static variables.


Patch by Phil Camp, SN Systems

Reviewers: dcoughlin, zaks.anna

Subscribers: xazax.hun, cfe-commits

Differential Revision: http://reviews.llvm.org/D19866

Patch by Phil Camp

llvm-svn: 270849

show more ...

[analyzer] Suppress stack address escape on CK_CopyAndAutoreleaseBlockObject.

Don't warn about addresses of stack-allocated blocks escaping if the block
region was cast with CK_CopyAndAutoreleaseBlo

[analyzer] Suppress stack address escape on CK_CopyAndAutoreleaseBlockObject.

Don't warn about addresses of stack-allocated blocks escaping if the block
region was cast with CK_CopyAndAutoreleaseBlockObject. These casts, which
are introduced in the implicit conversion operator for lambda-to-block
conversions, cause the block to be copied to the heap -- so the warning is
spurious.

llvm-svn: 254639

show more ...

[analyzer] Add generateErrorNode() APIs to CheckerContext.

The analyzer trims unnecessary nodes from the exploded graph before reporting
path diagnostics. However, in some cases it can trim all node

[analyzer] Add generateErrorNode() APIs to CheckerContext.

The analyzer trims unnecessary nodes from the exploded graph before reporting
path diagnostics. However, in some cases it can trim all nodes (including the
error node), leading to an assertion failure (see
https://llvm.org/bugs/show_bug.cgi?id=24184).

This commit addresses the issue by adding two new APIs to CheckerContext to
explicitly create error nodes. Unless the client provides a custom tag, these
APIs tag the node with the checker's tag -- preventing it from being trimmed.
The generateErrorNode() method creates a sink error node, while
generateNonFatalErrorNode() creates an error node for a path that should
continue being explored.

The intent is that one of these two methods should be used whenever a checker
creates an error node.

This commit updates the checkers to use these APIs. These APIs
(unlike addTransition() and generateSink()) do not take an explicit Pred node.
This is because there are not any error nodes in the checkers that were created
with an explicit different than the default (the CheckerContext's Pred node).

It also changes generateSink() to require state and pred nodes (previously
these were optional) to reduce confusion.

Additionally, there were several cases where checkers did check whether a
generated node could be null; we now explicitly check for null in these places.

This commit also includes a test case written by Ying Yi as part of
http://reviews.llvm.org/D12163 (that patch originally addressed this issue but
was reverted because it introduced false positive regressions).

Differential Revision: http://reviews.llvm.org/D12780

llvm-svn: 247859

show more ...

[analyzer] Apply whitespace cleanups by Honggyu Kim.

llvm-svn: 246978

Clarify pointer ownership semantics by hoisting the std::unique_ptr creation to the caller instead of hiding it in emitReport. NFC.

llvm-svn: 240400

Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").

llvm-svn: 240353

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comme

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang

To reduce churn, not touching namespaces spanning less than 10 lines.

llvm-svn: 240270

show more ...

[C++11] Add 'override' keyword to virtual methods that override their base class.

llvm-svn: 203999

Replace OwningPtr with std::unique_ptr.

This compiles cleanly with lldb/lld/clang-tools-extra/llvm.

llvm-svn: 203279

Expose the name of the checker producing each diagnostic message.

Summary:
In clang-tidy we'd like to know the name of the checker producing each
diagnostic message. PathDiagnostic has BugType and C

Expose the name of the checker producing each diagnostic message.

Summary:
In clang-tidy we'd like to know the name of the checker producing each
diagnostic message. PathDiagnostic has BugType and Category fields, which are
both arbitrary human-readable strings, but we need to know the exact name of the
checker in the form that can be used in the CheckersControlList option to
enable/disable the specific checker.

This patch adds the CheckName field to the CheckerBase class, and sets it in
the CheckerManager::registerChecker() method, which gets them from the
CheckerRegistry.

Checkers that implement multiple checks have to store the names of each check
in the respective registerXXXChecker method.

Reviewers: jordan_rose, krememek

Reviewed By: jordan_rose

CC: cfe-commits

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

llvm-svn: 201186

show more ...

[analyzer] StackAddrEscapeChecker: strip qualifiers from temporary types.

With the new support for trivial copy constructors, we are not always
consistent about whether a CXXTempObjectRegion gets re

[analyzer] StackAddrEscapeChecker: strip qualifiers from temporary types.

With the new support for trivial copy constructors, we are not always
consistent about whether a CXXTempObjectRegion gets reused or created
from scratch, which affects whether qualifiers are preserved. However,
we probably don't care anyway.

This also switches to using the current PrintingPolicy for the type,
which means C++ types don't get a spurious 'struct' prefix anymore.

llvm-svn: 176068

show more ...

[analyzer] Rename callback EndPath -> EndFunction

This better reflects when callback is called and what the checkers
are relying on. (Both names meant the same pre-IPA.)

llvm-svn: 171432

Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/util

Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237

show more ...

Include pruning and general cleanup.

llvm-svn: 169095

Don't include Type.h in DeclarationName.h.

Recursively prune some includes.

llvm-svn: 169094

[analyzer] Rename 'EmitReport' to 'emitReport'.

No functionality change.

llvm-svn: 167275

[analyzer] C++ objects returned on the stack may be wrapped in ExprWithCleanups.

In C++, objects being returned on the stack are actually copy-constructed into
the return value. That means that when

[analyzer] C++ objects returned on the stack may be wrapped in ExprWithCleanups.

In C++, objects being returned on the stack are actually copy-constructed into
the return value. That means that when a temporary is returned, it still has
to be destroyed, i.e. the returned expression will be wrapped in an
ExprWithCleanups node. Our "returning stack memory" checker needs to look
through this node to see if we really are returning an object by value.

PR13722

llvm-svn: 162817

show more ...