[clang][NFC] Trim license header comments to 81 characters (#82919)

clang-format would format these headers poorly by splitting it into
multiple lines.

[Sema, StaticAnalyzer] Use StringRef::contains (NFC)

[analyzer][DirectIvarAssignment] Turn DirectIvarAssignmentForAnnotatedFunctions into a checker option

Since this is an alpha checker, I don't worry about backward compatibility :)

Differential Revi

[analyzer][DirectIvarAssignment] Turn DirectIvarAssignmentForAnnotatedFunctions into a checker option

Since this is an alpha checker, I don't worry about backward compatibility :)

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

show more ...

[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions

Some checkers may not only depend on language options but also analyzer options.
To make this possible this patc

[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions

Some checkers may not only depend on language options but also analyzer options.
To make this possible this patch changes the parameter of the shouldRegister*
function to CheckerManager to be able to query the analyzer options when
deciding whether the checker should be registered.

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

show more ...

Redeclare Objective-C property accessors inside the ObjCImplDecl in which they are synthesized.

This patch is motivated by (and factored out from)
https://reviews.llvm.org/D66121 which is a debug in

Redeclare Objective-C property accessors inside the ObjCImplDecl in which they are synthesized.

This patch is motivated by (and factored out from)
https://reviews.llvm.org/D66121 which is a debug info bugfix. Starting
with DWARF 5 all Objective-C methods are nested inside their
containing type, and that patch implements this for synthesized
Objective-C properties.

1. SemaObjCProperty populates a list of synthesized accessors that may
need to inserted into an ObjCImplDecl.

2. SemaDeclObjC::ActOnEnd inserts forward-declarations for all
accessors for which no override was provided into their
ObjCImplDecl. This patch does *not* synthesize AST function
*bodies*. Moving that code from the static analyzer into Sema may
be a good idea though.

3. Places that expect all methods to have bodies have been updated.

I did not update the static analyzer's inliner for synthesized
properties to point back to the property declaration (see
test/Analysis/Inputs/expected-plists/nullability-notes.m.plist), which
I believed to be more bug than a feature.

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

rdar://problem/53782400

show more ...

[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker

This patch effectively fixes the almost decade old checker naming issue.
The solution i

[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker

This patch effectively fixes the almost decade old checker naming issue.
The solution is to assert when CheckerManager::getChecker is called on an
unregistered checker, and assert when CheckerManager::registerChecker is called
on a checker that is already registered.

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

llvm-svn: 352292

show more ...

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

Use instance_properties instead of properties. NFC.

All current properties are instance properties.

This is the second patch in a series of patches to support class properties
in addition to instan

Use instance_properties instead of properties. NFC.

All current properties are instance properties.

This is the second patch in a series of patches to support class properties
in addition to instance properties in objective-c.

rdar://23891898

llvm-svn: 258824

show more ...

Refactor: Simplify boolean conditional return statements in lib/StaticAnalyzer/Checkers

Summary: Use clang-tidy to simplify boolean conditional return values

Reviewers: dcoughlin, krememek

Subscri

Refactor: Simplify boolean conditional return statements in lib/StaticAnalyzer/Checkers

Summary: Use clang-tidy to simplify boolean conditional return values

Reviewers: dcoughlin, krememek

Subscribers: krememek, cfe-commits

Patch by Richard Thomson!

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

llvm-svn: 256491

show more ...

Switch users of the 'for (StmtRange range = stmt->children(); range; ++range)‘ pattern to range for loops.

The pattern was born out of the lack of range-based for loops in C++98
and is somewhat obsc

Switch users of the 'for (StmtRange range = stmt->children(); range; ++range)‘ pattern to range for loops.

The pattern was born out of the lack of range-based for loops in C++98
and is somewhat obscure. No functionality change intended.

llvm-svn: 241300

show more ...

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] Replacing ObjCContainerDecl iterators instmeth_begin() and instmeth_end() with iterator_range instance_methods(). Updating all of the usages of the iterators with range-based for loops.

llvm

[C++11] Replacing ObjCContainerDecl iterators instmeth_begin() and instmeth_end() with iterator_range instance_methods(). Updating all of the usages of the iterators with range-based for loops.

llvm-svn: 203839

show more ...

Renaming the recently-created (r203830) props() range API to properties() for clarity.

llvm-svn: 203835

[C++11] Replacing ObjCContainerDecl iterators prop_begin() and prop_end() with iterator_range props(). Updating all of the usages of the iterators with range-based for loops.

llvm-svn: 203830

[C++11] Replacing DeclBase iterators specific_attr_begin() and specific_attr_end() with iterator_range specific_attrs(). Updating all of the usages of the iterators with range-based for loops.

llvm-

[C++11] Replacing DeclBase iterators specific_attr_begin() and specific_attr_end() with iterator_range specific_attrs(). Updating all of the usages of the iterators with range-based for loops.

llvm-svn: 203474

show more ...

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

DirectIvarAssignment: Replace vtable'd objects with simple functions.

Avoids unnecessary static constructors.

llvm-svn: 188083

[analyzer] DirectIvarAssignment: allow suppression annotation on Ivars.

llvm-svn: 172766

[analyzer] Add an annotation to allow suppression of direct ivar
assignment

llvm-svn: 172597

Fix typo: objc_no_direct_instance_variable_assignmemt => objc_no_direct_instance_variable_assignment.

Fixes <rdar://problem/12927551>.

llvm-svn: 170971

Add missing virtual destructors reported by -Wnon-virtual-dtor.

llvm-svn: 169365

[analyzer] Implement an opt-in variant of direct ivar assignment.

This will only check the direct ivar assignments in the annotated
methods.

llvm-svn: 169349