2018-04-04 05:31:50 +08:00
|
|
|
//===- CheckerRegistry.cpp - Maintains all available checkers -------------===//
|
2011-08-17 05:24:21 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2011-08-17 05:24:21 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
[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 ®istry);
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
2018-12-16 00:23:51 +08:00
|
|
|
#include "clang/StaticAnalyzer/Frontend/CheckerRegistry.h"
|
2015-07-10 05:43:45 +08:00
|
|
|
#include "clang/Basic/Diagnostic.h"
|
2018-04-04 05:31:50 +08:00
|
|
|
#include "clang/Basic/LLVM.h"
|
2018-12-16 02:11:49 +08:00
|
|
|
#include "clang/Frontend/FrontendDiagnostic.h"
|
|
|
|
#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
|
2015-07-10 05:43:45 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
|
2019-04-19 01:32:51 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/CheckerManager.h"
|
2018-04-04 05:31:50 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2011-12-15 09:36:04 +08:00
|
|
|
#include "llvm/ADT/SetVector.h"
|
2018-04-04 05:31:50 +08:00
|
|
|
#include "llvm/ADT/StringMap.h"
|
|
|
|
#include "llvm/ADT/StringRef.h"
|
2018-12-16 02:11:49 +08:00
|
|
|
#include "llvm/Support/DynamicLibrary.h"
|
|
|
|
#include "llvm/Support/Path.h"
|
2012-12-02 01:12:56 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2018-04-04 05:31:50 +08:00
|
|
|
#include <algorithm>
|
2011-08-17 05:24:21 +08:00
|
|
|
|
|
|
|
using namespace clang;
|
|
|
|
using namespace ento;
|
2018-12-16 02:11:49 +08:00
|
|
|
using llvm::sys::DynamicLibrary;
|
|
|
|
|
|
|
|
using RegisterCheckersFn = void (*)(CheckerRegistry &);
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
static bool isCompatibleAPIVersion(const char *VersionString) {
|
|
|
|
// If the version string is null, its not an analyzer plugin.
|
|
|
|
if (!VersionString)
|
2018-12-16 02:11:49 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// For now, none of the static analyzer API is considered stable.
|
|
|
|
// Versions must match exactly.
|
2019-04-18 23:19:16 +08:00
|
|
|
return strcmp(VersionString, CLANG_ANALYZER_API_VERSION_STRING) == 0;
|
2018-12-16 02:11:49 +08:00
|
|
|
}
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
namespace {
|
2019-04-19 01:32:51 +08:00
|
|
|
template <class T> struct FullNameLT {
|
2019-04-18 23:19:16 +08:00
|
|
|
bool operator()(const T &Lhs, const T &Rhs) {
|
|
|
|
return Lhs.FullName < Rhs.FullName;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
[analyzer][NFC] Reimplement checker options
TL;DR:
* Add checker and package options to the TableGen files
* Added a new class called CmdLineOption, and both Package and Checker recieved
a list<CmdLineOption> field.
* Added every existing checker and package option to Checkers.td.
* The CheckerRegistry class
* Received some comments to most of it's inline classes
* Received the CmdLineOption and PackageInfo inline classes, a list of
CmdLineOption was added to CheckerInfo and PackageInfo
* Added addCheckerOption and addPackageOption
* Added a new field called Packages, used in addPackageOptions, filled up in
addPackage
Detailed description:
In the last couple months, a lot of effort was put into tightening the
analyzer's command line interface. The main issue is that it's spectacularly
easy to mess up a lenghty enough invocation of the analyzer, and the user was
given no warnings or errors at all in that case.
We can divide the effort of resolving this into several chapters:
* Non-checker analyzer configurations:
Gather every analyzer configuration into a dedicated file. Emit errors for
non-existent configurations or incorrect values. Be able to list these
configurations. Tighten AnalyzerOptions interface to disallow making such
a mistake in the future.
* Fix the "Checker Naming Bug" by reimplementing checker dependencies:
When cplusplus.InnerPointer was enabled, it implicitly registered
unix.Malloc, which implicitly registered some sort of a modeling checker
from the CStringChecker family. This resulted in all of these checker
objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions
asking for the wrong checker options from the command line:
cplusplus.InnerPointer:Optimisic
istead of
unix.Malloc:Optimistic.
This was resolved by making CheckerRegistry responsible for checker
dependency handling, instead of checkers themselves.
* Checker options: (this patch included!)
Same as the first item, but for checkers.
(+ minor fixes here and there, and everything else that is yet to come)
There were several issues regarding checker options, that non-checker
configurations didn't suffer from: checker plugins are loaded runtime, and they
could add new checkers and new options, meaning that unlike for non-checker
configurations, we can't collect every checker option purely by generating code.
Also, as seen from the "Checker Naming Bug" issue raised above, they are very
rarely used in practice, and all sorts of skeletons fell out of the closet while
working on this project.
They were extremely problematic for users as well, purely because of how long
they were. Consider the following monster of a checker option:
alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false
While we were able to verify whether the checker itself (the part before the
colon) existed, any errors past that point were unreported, easily resulting
in 7+ hours of analyses going to waste.
This patch, similarly to how dependencies were reimplemented, uses TableGen to
register checker options into Checkers.td, so that Checkers.inc now contains
entries for both checker and package options. Using the preprocessor,
Checkers.inc is converted into code in CheckerRegistry, adding every builtin
(checkers and packages that have an entry in the Checkers.td file) checker and
package option to the registry. The new addPackageOption and addCheckerOption
functions expose the same functionality to statically-linked non-builtin and
plugin checkers and packages as well.
Emitting errors for incorrect user input, being able to list these options, and
some other functionalies will land in later patches.
Differential Revision: https://reviews.llvm.org/D57855
llvm-svn: 358752
2019-04-19 20:32:10 +08:00
|
|
|
using PackageNameLT = FullNameLT<CheckerRegistry::PackageInfo>;
|
2019-04-18 23:19:16 +08:00
|
|
|
using CheckerNameLT = FullNameLT<CheckerRegistry::CheckerInfo>;
|
|
|
|
} // end of anonymous namespace
|
2019-01-27 00:35:33 +08:00
|
|
|
|
2019-04-19 01:34:45 +08:00
|
|
|
template <class CheckerOrPackageInfoList>
|
|
|
|
static
|
|
|
|
typename std::conditional<std::is_const<CheckerOrPackageInfoList>::value,
|
|
|
|
typename CheckerOrPackageInfoList::const_iterator,
|
|
|
|
typename CheckerOrPackageInfoList::iterator>::type
|
|
|
|
binaryFind(CheckerOrPackageInfoList &Collection, StringRef FullName) {
|
|
|
|
|
|
|
|
using CheckerOrPackage = typename CheckerOrPackageInfoList::value_type;
|
|
|
|
using CheckerOrPackageFullNameLT = FullNameLT<CheckerOrPackage>;
|
|
|
|
|
|
|
|
assert(std::is_sorted(Collection.begin(), Collection.end(),
|
|
|
|
CheckerOrPackageFullNameLT{}) &&
|
|
|
|
"In order to efficiently gather checkers/packages, this function "
|
|
|
|
"expects them to be already sorted!");
|
|
|
|
|
2019-04-19 09:54:36 +08:00
|
|
|
return llvm::lower_bound(Collection, CheckerOrPackage(FullName),
|
|
|
|
CheckerOrPackageFullNameLT{});
|
2019-04-19 01:34:45 +08:00
|
|
|
}
|
|
|
|
|
2019-01-27 00:35:33 +08:00
|
|
|
static constexpr char PackageSeparator = '.';
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
static bool isInPackage(const CheckerRegistry::CheckerInfo &Checker,
|
|
|
|
StringRef PackageName) {
|
2019-01-27 00:35:33 +08:00
|
|
|
// Does the checker's full name have the package as a prefix?
|
2019-04-18 23:19:16 +08:00
|
|
|
if (!Checker.FullName.startswith(PackageName))
|
2019-01-27 00:35:33 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// Is the package actually just the name of a specific checker?
|
2019-04-18 23:19:16 +08:00
|
|
|
if (Checker.FullName.size() == PackageName.size())
|
2019-01-27 00:35:33 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
// Is the checker in the package (or a subpackage)?
|
2019-04-18 23:19:16 +08:00
|
|
|
if (Checker.FullName[PackageName.size()] == PackageSeparator)
|
2019-01-27 00:35:33 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
CheckerRegistry::CheckerInfoListRange
|
|
|
|
CheckerRegistry::getMutableCheckersForCmdLineArg(StringRef CmdLineArg) {
|
2019-04-19 01:34:45 +08:00
|
|
|
auto It = binaryFind(Checkers, CmdLineArg);
|
2019-01-27 00:35:33 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
if (!isInPackage(*It, CmdLineArg))
|
2019-04-19 01:32:51 +08:00
|
|
|
return {Checkers.end(), Checkers.end()};
|
2019-01-27 00:35:33 +08:00
|
|
|
|
|
|
|
// See how large the package is.
|
|
|
|
// If the package doesn't exist, assume the option refers to a single
|
|
|
|
// checker.
|
2019-04-18 23:19:16 +08:00
|
|
|
size_t Size = 1;
|
|
|
|
llvm::StringMap<size_t>::const_iterator PackageSize =
|
|
|
|
PackageSizes.find(CmdLineArg);
|
2019-01-27 00:35:33 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
if (PackageSize != PackageSizes.end())
|
|
|
|
Size = PackageSize->getValue();
|
2019-01-27 00:35:33 +08:00
|
|
|
|
2019-04-19 01:32:51 +08:00
|
|
|
return {It, It + Size};
|
2019-01-27 00:35:33 +08:00
|
|
|
}
|
|
|
|
|
2019-01-27 01:27:40 +08:00
|
|
|
CheckerRegistry::CheckerRegistry(
|
2019-04-19 01:32:51 +08:00
|
|
|
ArrayRef<std::string> Plugins, DiagnosticsEngine &Diags,
|
|
|
|
AnalyzerOptions &AnOpts, const LangOptions &LangOpts,
|
|
|
|
ArrayRef<std::function<void(CheckerRegistry &)>> CheckerRegistrationFns)
|
|
|
|
: Diags(Diags), AnOpts(AnOpts), LangOpts(LangOpts) {
|
2019-01-26 22:23:08 +08:00
|
|
|
|
2019-01-27 00:35:33 +08:00
|
|
|
// Register builtin checkers.
|
2018-12-16 02:11:49 +08:00
|
|
|
#define GET_CHECKERS
|
2018-12-21 04:20:20 +08:00
|
|
|
#define CHECKER(FULLNAME, CLASS, HELPTEXT, DOC_URI) \
|
2019-01-26 22:23:08 +08:00
|
|
|
addChecker(register##CLASS, shouldRegister##CLASS, FULLNAME, HELPTEXT, \
|
|
|
|
DOC_URI);
|
2019-04-18 23:19:16 +08:00
|
|
|
|
[analyzer][NFC] Reimplement checker options
TL;DR:
* Add checker and package options to the TableGen files
* Added a new class called CmdLineOption, and both Package and Checker recieved
a list<CmdLineOption> field.
* Added every existing checker and package option to Checkers.td.
* The CheckerRegistry class
* Received some comments to most of it's inline classes
* Received the CmdLineOption and PackageInfo inline classes, a list of
CmdLineOption was added to CheckerInfo and PackageInfo
* Added addCheckerOption and addPackageOption
* Added a new field called Packages, used in addPackageOptions, filled up in
addPackage
Detailed description:
In the last couple months, a lot of effort was put into tightening the
analyzer's command line interface. The main issue is that it's spectacularly
easy to mess up a lenghty enough invocation of the analyzer, and the user was
given no warnings or errors at all in that case.
We can divide the effort of resolving this into several chapters:
* Non-checker analyzer configurations:
Gather every analyzer configuration into a dedicated file. Emit errors for
non-existent configurations or incorrect values. Be able to list these
configurations. Tighten AnalyzerOptions interface to disallow making such
a mistake in the future.
* Fix the "Checker Naming Bug" by reimplementing checker dependencies:
When cplusplus.InnerPointer was enabled, it implicitly registered
unix.Malloc, which implicitly registered some sort of a modeling checker
from the CStringChecker family. This resulted in all of these checker
objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions
asking for the wrong checker options from the command line:
cplusplus.InnerPointer:Optimisic
istead of
unix.Malloc:Optimistic.
This was resolved by making CheckerRegistry responsible for checker
dependency handling, instead of checkers themselves.
* Checker options: (this patch included!)
Same as the first item, but for checkers.
(+ minor fixes here and there, and everything else that is yet to come)
There were several issues regarding checker options, that non-checker
configurations didn't suffer from: checker plugins are loaded runtime, and they
could add new checkers and new options, meaning that unlike for non-checker
configurations, we can't collect every checker option purely by generating code.
Also, as seen from the "Checker Naming Bug" issue raised above, they are very
rarely used in practice, and all sorts of skeletons fell out of the closet while
working on this project.
They were extremely problematic for users as well, purely because of how long
they were. Consider the following monster of a checker option:
alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false
While we were able to verify whether the checker itself (the part before the
colon) existed, any errors past that point were unreported, easily resulting
in 7+ hours of analyses going to waste.
This patch, similarly to how dependencies were reimplemented, uses TableGen to
register checker options into Checkers.td, so that Checkers.inc now contains
entries for both checker and package options. Using the preprocessor,
Checkers.inc is converted into code in CheckerRegistry, adding every builtin
(checkers and packages that have an entry in the Checkers.td file) checker and
package option to the registry. The new addPackageOption and addCheckerOption
functions expose the same functionality to statically-linked non-builtin and
plugin checkers and packages as well.
Emitting errors for incorrect user input, being able to list these options, and
some other functionalies will land in later patches.
Differential Revision: https://reviews.llvm.org/D57855
llvm-svn: 358752
2019-04-19 20:32:10 +08:00
|
|
|
#define GET_PACKAGES
|
|
|
|
#define PACKAGE(FULLNAME) addPackage(FULLNAME);
|
|
|
|
|
2018-12-16 02:11:49 +08:00
|
|
|
#include "clang/StaticAnalyzer/Checkers/Checkers.inc"
|
|
|
|
#undef CHECKER
|
|
|
|
#undef GET_CHECKERS
|
2019-04-18 23:19:16 +08:00
|
|
|
#undef PACKAGE
|
|
|
|
#undef GET_PACKAGES
|
2018-12-16 02:11:49 +08:00
|
|
|
|
2019-01-27 00:35:33 +08:00
|
|
|
// Register checkers from plugins.
|
2019-04-18 23:19:16 +08:00
|
|
|
for (const std::string &Plugin : Plugins) {
|
2018-12-16 02:11:49 +08:00
|
|
|
// Get access to the plugin.
|
2019-04-18 23:19:16 +08:00
|
|
|
std::string ErrorMsg;
|
|
|
|
DynamicLibrary Lib =
|
|
|
|
DynamicLibrary::getPermanentLibrary(Plugin.c_str(), &ErrorMsg);
|
|
|
|
if (!Lib.isValid()) {
|
|
|
|
Diags.Report(diag::err_fe_unable_to_load_plugin) << Plugin << ErrorMsg;
|
2018-12-16 02:11:49 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
// See if its compatible with this build of clang.
|
|
|
|
const char *PluginAPIVersion = static_cast<const char *>(
|
|
|
|
Lib.getAddressOfSymbol("clang_analyzerAPIVersionString"));
|
|
|
|
|
|
|
|
if (!isCompatibleAPIVersion(PluginAPIVersion)) {
|
2018-12-16 02:11:49 +08:00
|
|
|
Diags.Report(diag::warn_incompatible_analyzer_plugin_api)
|
2019-04-18 23:19:16 +08:00
|
|
|
<< llvm::sys::path::filename(Plugin);
|
2018-12-16 02:11:49 +08:00
|
|
|
Diags.Report(diag::note_incompatible_analyzer_plugin_api)
|
2019-04-19 01:32:51 +08:00
|
|
|
<< CLANG_ANALYZER_API_VERSION_STRING << PluginAPIVersion;
|
2018-12-16 02:11:49 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Register its checkers.
|
2019-04-18 23:19:16 +08:00
|
|
|
RegisterCheckersFn RegisterPluginCheckers =
|
2019-04-19 01:32:51 +08:00
|
|
|
reinterpret_cast<RegisterCheckersFn>(
|
|
|
|
Lib.getAddressOfSymbol("clang_registerCheckers"));
|
2019-04-18 23:19:16 +08:00
|
|
|
if (RegisterPluginCheckers)
|
|
|
|
RegisterPluginCheckers(*this);
|
2018-12-16 02:11:49 +08:00
|
|
|
}
|
2011-08-17 05:24:21 +08:00
|
|
|
|
2019-01-27 01:27:40 +08:00
|
|
|
// Register statically linked checkers, that aren't generated from the tblgen
|
2019-04-19 01:32:51 +08:00
|
|
|
// file, but rather passed their registry function as a parameter in
|
|
|
|
// checkerRegistrationFns.
|
2019-01-27 01:27:40 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
for (const auto &Fn : CheckerRegistrationFns)
|
2019-01-27 01:27:40 +08:00
|
|
|
Fn(*this);
|
|
|
|
|
2019-01-27 00:35:33 +08:00
|
|
|
// Sort checkers for efficient collection.
|
|
|
|
// FIXME: Alphabetical sort puts 'experimental' in the middle.
|
|
|
|
// Would it be better to name it '~experimental' or something else
|
|
|
|
// that's ASCIIbetically last?
|
[analyzer][NFC] Reimplement checker options
TL;DR:
* Add checker and package options to the TableGen files
* Added a new class called CmdLineOption, and both Package and Checker recieved
a list<CmdLineOption> field.
* Added every existing checker and package option to Checkers.td.
* The CheckerRegistry class
* Received some comments to most of it's inline classes
* Received the CmdLineOption and PackageInfo inline classes, a list of
CmdLineOption was added to CheckerInfo and PackageInfo
* Added addCheckerOption and addPackageOption
* Added a new field called Packages, used in addPackageOptions, filled up in
addPackage
Detailed description:
In the last couple months, a lot of effort was put into tightening the
analyzer's command line interface. The main issue is that it's spectacularly
easy to mess up a lenghty enough invocation of the analyzer, and the user was
given no warnings or errors at all in that case.
We can divide the effort of resolving this into several chapters:
* Non-checker analyzer configurations:
Gather every analyzer configuration into a dedicated file. Emit errors for
non-existent configurations or incorrect values. Be able to list these
configurations. Tighten AnalyzerOptions interface to disallow making such
a mistake in the future.
* Fix the "Checker Naming Bug" by reimplementing checker dependencies:
When cplusplus.InnerPointer was enabled, it implicitly registered
unix.Malloc, which implicitly registered some sort of a modeling checker
from the CStringChecker family. This resulted in all of these checker
objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions
asking for the wrong checker options from the command line:
cplusplus.InnerPointer:Optimisic
istead of
unix.Malloc:Optimistic.
This was resolved by making CheckerRegistry responsible for checker
dependency handling, instead of checkers themselves.
* Checker options: (this patch included!)
Same as the first item, but for checkers.
(+ minor fixes here and there, and everything else that is yet to come)
There were several issues regarding checker options, that non-checker
configurations didn't suffer from: checker plugins are loaded runtime, and they
could add new checkers and new options, meaning that unlike for non-checker
configurations, we can't collect every checker option purely by generating code.
Also, as seen from the "Checker Naming Bug" issue raised above, they are very
rarely used in practice, and all sorts of skeletons fell out of the closet while
working on this project.
They were extremely problematic for users as well, purely because of how long
they were. Consider the following monster of a checker option:
alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false
While we were able to verify whether the checker itself (the part before the
colon) existed, any errors past that point were unreported, easily resulting
in 7+ hours of analyses going to waste.
This patch, similarly to how dependencies were reimplemented, uses TableGen to
register checker options into Checkers.td, so that Checkers.inc now contains
entries for both checker and package options. Using the preprocessor,
Checkers.inc is converted into code in CheckerRegistry, adding every builtin
(checkers and packages that have an entry in the Checkers.td file) checker and
package option to the registry. The new addPackageOption and addCheckerOption
functions expose the same functionality to statically-linked non-builtin and
plugin checkers and packages as well.
Emitting errors for incorrect user input, being able to list these options, and
some other functionalies will land in later patches.
Differential Revision: https://reviews.llvm.org/D57855
llvm-svn: 358752
2019-04-19 20:32:10 +08:00
|
|
|
llvm::sort(Packages, PackageNameLT{});
|
2019-04-18 23:19:16 +08:00
|
|
|
llvm::sort(Checkers, CheckerNameLT{});
|
2011-08-17 05:24:21 +08:00
|
|
|
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
#define GET_CHECKER_DEPENDENCIES
|
|
|
|
|
|
|
|
#define CHECKER_DEPENDENCY(FULLNAME, DEPENDENCY) \
|
|
|
|
addDependency(FULLNAME, DEPENDENCY);
|
|
|
|
|
[analyzer][NFC] Reimplement checker options
TL;DR:
* Add checker and package options to the TableGen files
* Added a new class called CmdLineOption, and both Package and Checker recieved
a list<CmdLineOption> field.
* Added every existing checker and package option to Checkers.td.
* The CheckerRegistry class
* Received some comments to most of it's inline classes
* Received the CmdLineOption and PackageInfo inline classes, a list of
CmdLineOption was added to CheckerInfo and PackageInfo
* Added addCheckerOption and addPackageOption
* Added a new field called Packages, used in addPackageOptions, filled up in
addPackage
Detailed description:
In the last couple months, a lot of effort was put into tightening the
analyzer's command line interface. The main issue is that it's spectacularly
easy to mess up a lenghty enough invocation of the analyzer, and the user was
given no warnings or errors at all in that case.
We can divide the effort of resolving this into several chapters:
* Non-checker analyzer configurations:
Gather every analyzer configuration into a dedicated file. Emit errors for
non-existent configurations or incorrect values. Be able to list these
configurations. Tighten AnalyzerOptions interface to disallow making such
a mistake in the future.
* Fix the "Checker Naming Bug" by reimplementing checker dependencies:
When cplusplus.InnerPointer was enabled, it implicitly registered
unix.Malloc, which implicitly registered some sort of a modeling checker
from the CStringChecker family. This resulted in all of these checker
objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions
asking for the wrong checker options from the command line:
cplusplus.InnerPointer:Optimisic
istead of
unix.Malloc:Optimistic.
This was resolved by making CheckerRegistry responsible for checker
dependency handling, instead of checkers themselves.
* Checker options: (this patch included!)
Same as the first item, but for checkers.
(+ minor fixes here and there, and everything else that is yet to come)
There were several issues regarding checker options, that non-checker
configurations didn't suffer from: checker plugins are loaded runtime, and they
could add new checkers and new options, meaning that unlike for non-checker
configurations, we can't collect every checker option purely by generating code.
Also, as seen from the "Checker Naming Bug" issue raised above, they are very
rarely used in practice, and all sorts of skeletons fell out of the closet while
working on this project.
They were extremely problematic for users as well, purely because of how long
they were. Consider the following monster of a checker option:
alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false
While we were able to verify whether the checker itself (the part before the
colon) existed, any errors past that point were unreported, easily resulting
in 7+ hours of analyses going to waste.
This patch, similarly to how dependencies were reimplemented, uses TableGen to
register checker options into Checkers.td, so that Checkers.inc now contains
entries for both checker and package options. Using the preprocessor,
Checkers.inc is converted into code in CheckerRegistry, adding every builtin
(checkers and packages that have an entry in the Checkers.td file) checker and
package option to the registry. The new addPackageOption and addCheckerOption
functions expose the same functionality to statically-linked non-builtin and
plugin checkers and packages as well.
Emitting errors for incorrect user input, being able to list these options, and
some other functionalies will land in later patches.
Differential Revision: https://reviews.llvm.org/D57855
llvm-svn: 358752
2019-04-19 20:32:10 +08:00
|
|
|
#define GET_CHECKER_OPTIONS
|
|
|
|
#define CHECKER_OPTION(TYPE, FULLNAME, CMDFLAG, DESC, DEFAULT_VAL) \
|
|
|
|
addCheckerOption(TYPE, FULLNAME, CMDFLAG, DEFAULT_VAL, DESC);
|
|
|
|
|
|
|
|
#define GET_PACKAGE_OPTIONS
|
|
|
|
#define PACKAGE_OPTION(TYPE, FULLNAME, CMDFLAG, DESC, DEFAULT_VAL) \
|
|
|
|
addPackageOption(TYPE, FULLNAME, CMDFLAG, DEFAULT_VAL, DESC);
|
|
|
|
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
#include "clang/StaticAnalyzer/Checkers/Checkers.inc"
|
|
|
|
#undef CHECKER_DEPENDENCY
|
|
|
|
#undef GET_CHECKER_DEPENDENCIES
|
[analyzer][NFC] Reimplement checker options
TL;DR:
* Add checker and package options to the TableGen files
* Added a new class called CmdLineOption, and both Package and Checker recieved
a list<CmdLineOption> field.
* Added every existing checker and package option to Checkers.td.
* The CheckerRegistry class
* Received some comments to most of it's inline classes
* Received the CmdLineOption and PackageInfo inline classes, a list of
CmdLineOption was added to CheckerInfo and PackageInfo
* Added addCheckerOption and addPackageOption
* Added a new field called Packages, used in addPackageOptions, filled up in
addPackage
Detailed description:
In the last couple months, a lot of effort was put into tightening the
analyzer's command line interface. The main issue is that it's spectacularly
easy to mess up a lenghty enough invocation of the analyzer, and the user was
given no warnings or errors at all in that case.
We can divide the effort of resolving this into several chapters:
* Non-checker analyzer configurations:
Gather every analyzer configuration into a dedicated file. Emit errors for
non-existent configurations or incorrect values. Be able to list these
configurations. Tighten AnalyzerOptions interface to disallow making such
a mistake in the future.
* Fix the "Checker Naming Bug" by reimplementing checker dependencies:
When cplusplus.InnerPointer was enabled, it implicitly registered
unix.Malloc, which implicitly registered some sort of a modeling checker
from the CStringChecker family. This resulted in all of these checker
objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions
asking for the wrong checker options from the command line:
cplusplus.InnerPointer:Optimisic
istead of
unix.Malloc:Optimistic.
This was resolved by making CheckerRegistry responsible for checker
dependency handling, instead of checkers themselves.
* Checker options: (this patch included!)
Same as the first item, but for checkers.
(+ minor fixes here and there, and everything else that is yet to come)
There were several issues regarding checker options, that non-checker
configurations didn't suffer from: checker plugins are loaded runtime, and they
could add new checkers and new options, meaning that unlike for non-checker
configurations, we can't collect every checker option purely by generating code.
Also, as seen from the "Checker Naming Bug" issue raised above, they are very
rarely used in practice, and all sorts of skeletons fell out of the closet while
working on this project.
They were extremely problematic for users as well, purely because of how long
they were. Consider the following monster of a checker option:
alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false
While we were able to verify whether the checker itself (the part before the
colon) existed, any errors past that point were unreported, easily resulting
in 7+ hours of analyses going to waste.
This patch, similarly to how dependencies were reimplemented, uses TableGen to
register checker options into Checkers.td, so that Checkers.inc now contains
entries for both checker and package options. Using the preprocessor,
Checkers.inc is converted into code in CheckerRegistry, adding every builtin
(checkers and packages that have an entry in the Checkers.td file) checker and
package option to the registry. The new addPackageOption and addCheckerOption
functions expose the same functionality to statically-linked non-builtin and
plugin checkers and packages as well.
Emitting errors for incorrect user input, being able to list these options, and
some other functionalies will land in later patches.
Differential Revision: https://reviews.llvm.org/D57855
llvm-svn: 358752
2019-04-19 20:32:10 +08:00
|
|
|
#undef CHECKER_OPTION
|
|
|
|
#undef GET_CHECKER_OPTIONS
|
|
|
|
#undef PACKAGE_OPTION
|
|
|
|
#undef GET_PACKAGE_OPTIONS
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
|
2019-04-19 19:01:35 +08:00
|
|
|
resolveDependencies();
|
[analyzer][NFC] Reimplement checker options
TL;DR:
* Add checker and package options to the TableGen files
* Added a new class called CmdLineOption, and both Package and Checker recieved
a list<CmdLineOption> field.
* Added every existing checker and package option to Checkers.td.
* The CheckerRegistry class
* Received some comments to most of it's inline classes
* Received the CmdLineOption and PackageInfo inline classes, a list of
CmdLineOption was added to CheckerInfo and PackageInfo
* Added addCheckerOption and addPackageOption
* Added a new field called Packages, used in addPackageOptions, filled up in
addPackage
Detailed description:
In the last couple months, a lot of effort was put into tightening the
analyzer's command line interface. The main issue is that it's spectacularly
easy to mess up a lenghty enough invocation of the analyzer, and the user was
given no warnings or errors at all in that case.
We can divide the effort of resolving this into several chapters:
* Non-checker analyzer configurations:
Gather every analyzer configuration into a dedicated file. Emit errors for
non-existent configurations or incorrect values. Be able to list these
configurations. Tighten AnalyzerOptions interface to disallow making such
a mistake in the future.
* Fix the "Checker Naming Bug" by reimplementing checker dependencies:
When cplusplus.InnerPointer was enabled, it implicitly registered
unix.Malloc, which implicitly registered some sort of a modeling checker
from the CStringChecker family. This resulted in all of these checker
objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions
asking for the wrong checker options from the command line:
cplusplus.InnerPointer:Optimisic
istead of
unix.Malloc:Optimistic.
This was resolved by making CheckerRegistry responsible for checker
dependency handling, instead of checkers themselves.
* Checker options: (this patch included!)
Same as the first item, but for checkers.
(+ minor fixes here and there, and everything else that is yet to come)
There were several issues regarding checker options, that non-checker
configurations didn't suffer from: checker plugins are loaded runtime, and they
could add new checkers and new options, meaning that unlike for non-checker
configurations, we can't collect every checker option purely by generating code.
Also, as seen from the "Checker Naming Bug" issue raised above, they are very
rarely used in practice, and all sorts of skeletons fell out of the closet while
working on this project.
They were extremely problematic for users as well, purely because of how long
they were. Consider the following monster of a checker option:
alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false
While we were able to verify whether the checker itself (the part before the
colon) existed, any errors past that point were unreported, easily resulting
in 7+ hours of analyses going to waste.
This patch, similarly to how dependencies were reimplemented, uses TableGen to
register checker options into Checkers.td, so that Checkers.inc now contains
entries for both checker and package options. Using the preprocessor,
Checkers.inc is converted into code in CheckerRegistry, adding every builtin
(checkers and packages that have an entry in the Checkers.td file) checker and
package option to the registry. The new addPackageOption and addCheckerOption
functions expose the same functionality to statically-linked non-builtin and
plugin checkers and packages as well.
Emitting errors for incorrect user input, being able to list these options, and
some other functionalies will land in later patches.
Differential Revision: https://reviews.llvm.org/D57855
llvm-svn: 358752
2019-04-19 20:32:10 +08:00
|
|
|
resolveCheckerAndPackageOptions();
|
2019-04-19 19:01:35 +08:00
|
|
|
|
2019-01-27 00:35:33 +08:00
|
|
|
// Parse '-analyzer-checker' and '-analyzer-disable-checker' options from the
|
|
|
|
// command line.
|
2019-04-18 23:19:16 +08:00
|
|
|
for (const std::pair<std::string, bool> &Opt : AnOpts.CheckersControlList) {
|
|
|
|
CheckerInfoListRange CheckerForCmdLineArg =
|
2019-04-19 01:32:51 +08:00
|
|
|
getMutableCheckersForCmdLineArg(Opt.first);
|
2011-08-17 05:24:21 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
if (CheckerForCmdLineArg.begin() == CheckerForCmdLineArg.end()) {
|
|
|
|
Diags.Report(diag::err_unknown_analyzer_checker) << Opt.first;
|
2019-01-27 00:35:33 +08:00
|
|
|
Diags.Report(diag::note_suggest_disabling_all_checkers);
|
|
|
|
}
|
2011-08-17 05:24:21 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
for (CheckerInfo &checker : CheckerForCmdLineArg) {
|
2019-04-19 01:32:51 +08:00
|
|
|
checker.State = Opt.second ? StateFromCmdLine::State_Enabled
|
|
|
|
: StateFromCmdLine::State_Disabled;
|
2019-01-27 00:35:33 +08:00
|
|
|
}
|
|
|
|
}
|
2011-08-17 05:24:21 +08:00
|
|
|
}
|
|
|
|
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
/// Collects dependencies in \p ret, returns false on failure.
|
2019-04-19 01:32:51 +08:00
|
|
|
static bool
|
|
|
|
collectDependenciesImpl(const CheckerRegistry::ConstCheckerInfoList &Deps,
|
|
|
|
const LangOptions &LO,
|
|
|
|
CheckerRegistry::CheckerInfoSet &Ret);
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
|
|
|
|
/// Collects dependenies in \p enabledCheckers. Return None on failure.
|
|
|
|
LLVM_NODISCARD
|
2019-04-19 01:32:51 +08:00
|
|
|
static llvm::Optional<CheckerRegistry::CheckerInfoSet>
|
|
|
|
collectDependencies(const CheckerRegistry::CheckerInfo &checker,
|
|
|
|
const LangOptions &LO) {
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
CheckerRegistry::CheckerInfoSet Ret;
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
// Add dependencies to the enabled checkers only if all of them can be
|
|
|
|
// enabled.
|
2019-04-18 23:19:16 +08:00
|
|
|
if (!collectDependenciesImpl(checker.Dependencies, LO, Ret))
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
return None;
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
return Ret;
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
}
|
|
|
|
|
2019-04-19 01:32:51 +08:00
|
|
|
static bool
|
|
|
|
collectDependenciesImpl(const CheckerRegistry::ConstCheckerInfoList &Deps,
|
|
|
|
const LangOptions &LO,
|
|
|
|
CheckerRegistry::CheckerInfoSet &Ret) {
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
for (const CheckerRegistry::CheckerInfo *Dependency : Deps) {
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
if (Dependency->isDisabled(LO))
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// Collect dependencies recursively.
|
2019-04-18 23:19:16 +08:00
|
|
|
if (!collectDependenciesImpl(Dependency->Dependencies, LO, Ret))
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
return false;
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
Ret.insert(Dependency);
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-01-26 23:59:21 +08:00
|
|
|
CheckerRegistry::CheckerInfoSet CheckerRegistry::getEnabledCheckers() const {
|
2018-12-15 23:44:05 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
CheckerInfoSet EnabledCheckers;
|
2018-12-15 23:44:05 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
for (const CheckerInfo &Checker : Checkers) {
|
|
|
|
if (!Checker.isEnabled(LangOpts))
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
continue;
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
// Recursively enable its dependencies.
|
|
|
|
llvm::Optional<CheckerInfoSet> Deps =
|
|
|
|
collectDependencies(Checker, LangOpts);
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
if (!Deps) {
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
// If we failed to enable any of the dependencies, don't enable this
|
|
|
|
// checker.
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Note that set_union also preserves the order of insertion.
|
2019-04-18 23:19:16 +08:00
|
|
|
EnabledCheckers.set_union(*Deps);
|
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
2019-01-27 04:06:54 +08:00
|
|
|
|
|
|
|
// Enable the checker.
|
2019-04-18 23:19:16 +08:00
|
|
|
EnabledCheckers.insert(&Checker);
|
2018-12-15 23:44:05 +08:00
|
|
|
}
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
return EnabledCheckers;
|
2011-08-17 05:24:21 +08:00
|
|
|
}
|
|
|
|
|
2019-04-19 19:01:35 +08:00
|
|
|
void CheckerRegistry::resolveDependencies() {
|
|
|
|
for (const std::pair<StringRef, StringRef> &Entry : Dependencies) {
|
|
|
|
auto CheckerIt = binaryFind(Checkers, Entry.first);
|
|
|
|
assert(CheckerIt != Checkers.end() && CheckerIt->FullName == Entry.first &&
|
|
|
|
"Failed to find the checker while attempting to set up its "
|
|
|
|
"dependencies!");
|
2019-04-18 23:19:16 +08:00
|
|
|
|
2019-04-19 19:01:35 +08:00
|
|
|
auto DependencyIt = binaryFind(Checkers, Entry.second);
|
|
|
|
assert(DependencyIt != Checkers.end() &&
|
|
|
|
DependencyIt->FullName == Entry.second &&
|
|
|
|
"Failed to find the dependency of a checker!");
|
|
|
|
|
|
|
|
CheckerIt->Dependencies.emplace_back(&*DependencyIt);
|
|
|
|
}
|
2019-04-18 23:19:16 +08:00
|
|
|
|
2019-04-19 19:01:35 +08:00
|
|
|
Dependencies.clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
void CheckerRegistry::addDependency(StringRef FullName, StringRef Dependency) {
|
|
|
|
Dependencies.emplace_back(FullName, Dependency);
|
2019-04-18 23:19:16 +08:00
|
|
|
}
|
|
|
|
|
[analyzer][NFC] Reimplement checker options
TL;DR:
* Add checker and package options to the TableGen files
* Added a new class called CmdLineOption, and both Package and Checker recieved
a list<CmdLineOption> field.
* Added every existing checker and package option to Checkers.td.
* The CheckerRegistry class
* Received some comments to most of it's inline classes
* Received the CmdLineOption and PackageInfo inline classes, a list of
CmdLineOption was added to CheckerInfo and PackageInfo
* Added addCheckerOption and addPackageOption
* Added a new field called Packages, used in addPackageOptions, filled up in
addPackage
Detailed description:
In the last couple months, a lot of effort was put into tightening the
analyzer's command line interface. The main issue is that it's spectacularly
easy to mess up a lenghty enough invocation of the analyzer, and the user was
given no warnings or errors at all in that case.
We can divide the effort of resolving this into several chapters:
* Non-checker analyzer configurations:
Gather every analyzer configuration into a dedicated file. Emit errors for
non-existent configurations or incorrect values. Be able to list these
configurations. Tighten AnalyzerOptions interface to disallow making such
a mistake in the future.
* Fix the "Checker Naming Bug" by reimplementing checker dependencies:
When cplusplus.InnerPointer was enabled, it implicitly registered
unix.Malloc, which implicitly registered some sort of a modeling checker
from the CStringChecker family. This resulted in all of these checker
objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions
asking for the wrong checker options from the command line:
cplusplus.InnerPointer:Optimisic
istead of
unix.Malloc:Optimistic.
This was resolved by making CheckerRegistry responsible for checker
dependency handling, instead of checkers themselves.
* Checker options: (this patch included!)
Same as the first item, but for checkers.
(+ minor fixes here and there, and everything else that is yet to come)
There were several issues regarding checker options, that non-checker
configurations didn't suffer from: checker plugins are loaded runtime, and they
could add new checkers and new options, meaning that unlike for non-checker
configurations, we can't collect every checker option purely by generating code.
Also, as seen from the "Checker Naming Bug" issue raised above, they are very
rarely used in practice, and all sorts of skeletons fell out of the closet while
working on this project.
They were extremely problematic for users as well, purely because of how long
they were. Consider the following monster of a checker option:
alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false
While we were able to verify whether the checker itself (the part before the
colon) existed, any errors past that point were unreported, easily resulting
in 7+ hours of analyses going to waste.
This patch, similarly to how dependencies were reimplemented, uses TableGen to
register checker options into Checkers.td, so that Checkers.inc now contains
entries for both checker and package options. Using the preprocessor,
Checkers.inc is converted into code in CheckerRegistry, adding every builtin
(checkers and packages that have an entry in the Checkers.td file) checker and
package option to the registry. The new addPackageOption and addCheckerOption
functions expose the same functionality to statically-linked non-builtin and
plugin checkers and packages as well.
Emitting errors for incorrect user input, being able to list these options, and
some other functionalies will land in later patches.
Differential Revision: https://reviews.llvm.org/D57855
llvm-svn: 358752
2019-04-19 20:32:10 +08:00
|
|
|
template <class T>
|
|
|
|
static void
|
|
|
|
insertOptionToCollection(StringRef FullName, T &Collection,
|
|
|
|
const CheckerRegistry::CmdLineOption &&Option) {
|
|
|
|
auto It = binaryFind(Collection, FullName);
|
|
|
|
assert(It != Collection.end() &&
|
|
|
|
"Failed to find the checker while attempting to add a command line "
|
|
|
|
"option to it!");
|
|
|
|
|
|
|
|
It->CmdLineOptions.emplace_back(std::move(Option));
|
|
|
|
}
|
|
|
|
|
|
|
|
void CheckerRegistry::resolveCheckerAndPackageOptions() {
|
|
|
|
for (const std::pair<StringRef, CmdLineOption> &CheckerOptEntry :
|
|
|
|
CheckerOptions) {
|
|
|
|
insertOptionToCollection(CheckerOptEntry.first, Checkers,
|
|
|
|
std::move(CheckerOptEntry.second));
|
|
|
|
}
|
|
|
|
CheckerOptions.clear();
|
|
|
|
|
|
|
|
for (const std::pair<StringRef, CmdLineOption> &PackageOptEntry :
|
|
|
|
PackageOptions) {
|
|
|
|
insertOptionToCollection(PackageOptEntry.first, Checkers,
|
|
|
|
std::move(PackageOptEntry.second));
|
|
|
|
}
|
|
|
|
PackageOptions.clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
void CheckerRegistry::addPackage(StringRef FullName) {
|
|
|
|
Packages.emplace_back(PackageInfo(FullName));
|
|
|
|
}
|
|
|
|
|
|
|
|
void CheckerRegistry::addPackageOption(StringRef OptionType,
|
|
|
|
StringRef PackageFullName,
|
|
|
|
StringRef OptionName,
|
|
|
|
StringRef DefaultValStr,
|
|
|
|
StringRef Description) {
|
|
|
|
PackageOptions.emplace_back(
|
|
|
|
PackageFullName,
|
|
|
|
CmdLineOption{OptionType, OptionName, DefaultValStr, Description});
|
|
|
|
}
|
|
|
|
|
|
|
|
void CheckerRegistry::addChecker(InitializationFunction Rfn,
|
|
|
|
ShouldRegisterFunction Sfn, StringRef Name,
|
|
|
|
StringRef Desc, StringRef DocsUri) {
|
|
|
|
Checkers.emplace_back(Rfn, Sfn, Name, Desc, DocsUri);
|
|
|
|
|
|
|
|
// Record the presence of the checker in its packages.
|
|
|
|
StringRef PackageName, LeafName;
|
|
|
|
std::tie(PackageName, LeafName) = Name.rsplit(PackageSeparator);
|
|
|
|
while (!LeafName.empty()) {
|
|
|
|
PackageSizes[PackageName] += 1;
|
|
|
|
std::tie(PackageName, LeafName) = PackageName.rsplit(PackageSeparator);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void CheckerRegistry::addCheckerOption(StringRef OptionType,
|
|
|
|
StringRef CheckerFullName,
|
|
|
|
StringRef OptionName,
|
|
|
|
StringRef DefaultValStr,
|
|
|
|
StringRef Description) {
|
|
|
|
CheckerOptions.emplace_back(
|
|
|
|
CheckerFullName,
|
|
|
|
CmdLineOption{OptionType, OptionName, DefaultValStr, Description});
|
|
|
|
}
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
void CheckerRegistry::initializeManager(CheckerManager &CheckerMgr) const {
|
2011-08-17 05:24:21 +08:00
|
|
|
// Collect checkers enabled by the options.
|
2019-01-26 23:59:21 +08:00
|
|
|
CheckerInfoSet enabledCheckers = getEnabledCheckers();
|
2011-08-17 05:24:21 +08:00
|
|
|
|
|
|
|
// Initialize the CheckerManager with all enabled checkers.
|
2019-04-18 23:19:16 +08:00
|
|
|
for (const auto *Checker : enabledCheckers) {
|
|
|
|
CheckerMgr.setCurrentCheckName(CheckName(Checker->FullName));
|
|
|
|
Checker->Initialize(CheckerMgr);
|
2011-08-17 05:24:21 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-26 23:59:21 +08:00
|
|
|
void CheckerRegistry::validateCheckerOptions() const {
|
2019-04-18 23:19:16 +08:00
|
|
|
for (const auto &Config : AnOpts.Config) {
|
|
|
|
size_t Pos = Config.getKey().find(':');
|
|
|
|
if (Pos == StringRef::npos)
|
2015-07-10 05:43:45 +08:00
|
|
|
continue;
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
bool HasChecker = false;
|
|
|
|
StringRef CheckerName = Config.getKey().substr(0, Pos);
|
|
|
|
for (const auto &Checker : Checkers) {
|
|
|
|
if (Checker.FullName.startswith(CheckerName) &&
|
|
|
|
(Checker.FullName.size() == Pos || Checker.FullName[Pos] == '.')) {
|
|
|
|
HasChecker = true;
|
2015-07-10 05:43:45 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2019-04-18 23:19:16 +08:00
|
|
|
if (!HasChecker)
|
|
|
|
Diags.Report(diag::err_unknown_analyzer_checker) << CheckerName;
|
2015-07-10 05:43:45 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
void CheckerRegistry::printCheckerWithDescList(raw_ostream &Out,
|
|
|
|
size_t MaxNameChars) const {
|
2011-08-17 05:24:21 +08:00
|
|
|
// FIXME: Print available packages.
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
Out << "CHECKERS:\n";
|
2011-08-17 05:24:21 +08:00
|
|
|
|
|
|
|
// Find the maximum option length.
|
2019-04-18 23:19:16 +08:00
|
|
|
size_t OptionFieldWidth = 0;
|
|
|
|
for (const auto &Checker : Checkers) {
|
2011-08-17 05:24:21 +08:00
|
|
|
// Limit the amount of padding we are willing to give up for alignment.
|
|
|
|
// Package.Name Description [Hidden]
|
2019-04-18 23:19:16 +08:00
|
|
|
size_t NameLength = Checker.FullName.size();
|
|
|
|
if (NameLength <= MaxNameChars)
|
|
|
|
OptionFieldWidth = std::max(OptionFieldWidth, NameLength);
|
2011-08-17 05:24:21 +08:00
|
|
|
}
|
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
const size_t InitialPad = 2;
|
|
|
|
for (const auto &Checker : Checkers) {
|
|
|
|
Out.indent(InitialPad) << Checker.FullName;
|
2011-08-17 05:24:21 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
int Pad = OptionFieldWidth - Checker.FullName.size();
|
2011-08-17 05:24:21 +08:00
|
|
|
|
|
|
|
// Break on long option names.
|
2019-04-18 23:19:16 +08:00
|
|
|
if (Pad < 0) {
|
|
|
|
Out << '\n';
|
|
|
|
Pad = OptionFieldWidth + InitialPad;
|
2011-08-17 05:24:21 +08:00
|
|
|
}
|
2019-04-18 23:19:16 +08:00
|
|
|
Out.indent(Pad + 2) << Checker.Desc;
|
2011-08-17 05:24:21 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
Out << '\n';
|
2011-08-17 05:24:21 +08:00
|
|
|
}
|
|
|
|
}
|
2016-08-08 21:41:04 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
void CheckerRegistry::printEnabledCheckerList(raw_ostream &Out) const {
|
2016-08-08 21:41:04 +08:00
|
|
|
// Collect checkers enabled by the options.
|
2019-04-18 23:19:16 +08:00
|
|
|
CheckerInfoSet EnabledCheckers = getEnabledCheckers();
|
2016-08-08 21:41:04 +08:00
|
|
|
|
2019-04-18 23:19:16 +08:00
|
|
|
for (const auto *i : EnabledCheckers)
|
|
|
|
Out << i->FullName << '\n';
|
2016-08-08 21:41:04 +08:00
|
|
|
}
|