2011-10-06 21:03:08 +08:00
|
|
|
//=- ClangSACheckersEmitter.cpp - Generate Clang SA checkers tables -*- C++ -*-
|
|
|
|
//
|
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-10-06 21:03:08 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This tablegen backend emits Clang Static Analyzer checkers tables.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2018-11-13 01:49:51 +08:00
|
|
|
#include "llvm/ADT/StringMap.h"
|
2012-10-26 00:37:08 +08:00
|
|
|
#include "llvm/TableGen/Error.h"
|
2012-06-13 13:12:41 +08:00
|
|
|
#include "llvm/TableGen/Record.h"
|
|
|
|
#include "llvm/TableGen/TableGenBackend.h"
|
2011-10-06 21:03:08 +08:00
|
|
|
#include <map>
|
|
|
|
#include <string>
|
2018-11-13 01:49:51 +08:00
|
|
|
|
2011-10-06 21:03:08 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Static Analyzer Checkers Tables generation
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
static std::string getPackageFullName(const Record *R);
|
|
|
|
|
|
|
|
static std::string getParentPackageFullName(const Record *R) {
|
|
|
|
std::string name;
|
2012-10-11 04:25:43 +08:00
|
|
|
if (DefInit *DI = dyn_cast<DefInit>(R->getValueInit("ParentPackage")))
|
2011-10-06 21:03:08 +08:00
|
|
|
name = getPackageFullName(DI->getDef());
|
|
|
|
return name;
|
|
|
|
}
|
|
|
|
|
|
|
|
static std::string getPackageFullName(const Record *R) {
|
|
|
|
std::string name = getParentPackageFullName(R);
|
2018-11-13 01:49:51 +08:00
|
|
|
if (!name.empty())
|
|
|
|
name += ".";
|
|
|
|
assert(!R->getValueAsString("PackageName").empty());
|
2017-06-01 03:01:22 +08:00
|
|
|
name += R->getValueAsString("PackageName");
|
|
|
|
return name;
|
2011-10-06 21:03:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static std::string getCheckerFullName(const Record *R) {
|
|
|
|
std::string name = getParentPackageFullName(R);
|
2018-11-13 01:49:51 +08:00
|
|
|
if (!name.empty())
|
|
|
|
name += ".";
|
|
|
|
assert(!R->getValueAsString("CheckerName").empty());
|
|
|
|
name += R->getValueAsString("CheckerName");
|
2011-10-06 21:03:08 +08:00
|
|
|
return name;
|
|
|
|
}
|
|
|
|
|
|
|
|
static std::string getStringValue(const Record &R, StringRef field) {
|
2012-10-11 04:25:43 +08:00
|
|
|
if (StringInit *SI = dyn_cast<StringInit>(R.getValueInit(field)))
|
2011-10-06 21:03:08 +08:00
|
|
|
return SI->getValue();
|
|
|
|
return std::string();
|
|
|
|
}
|
|
|
|
|
2018-12-21 04:20:20 +08:00
|
|
|
// Calculates the integer value representing the BitsInit object
|
2018-12-22 23:31:57 +08:00
|
|
|
static inline uint64_t getValueFromBitsInit(const BitsInit *B, const Record &R) {
|
2018-12-21 04:20:20 +08:00
|
|
|
assert(B->getNumBits() <= sizeof(uint64_t) * 8 && "BitInits' too long!");
|
|
|
|
|
|
|
|
uint64_t Value = 0;
|
|
|
|
for (unsigned i = 0, e = B->getNumBits(); i != e; ++i) {
|
2018-12-22 03:16:38 +08:00
|
|
|
const auto *Bit = dyn_cast<BitInit>(B->getBit(i));
|
|
|
|
if (Bit)
|
|
|
|
Value |= uint64_t(Bit->getValue()) << i;
|
|
|
|
else
|
2018-12-22 23:31:57 +08:00
|
|
|
PrintFatalError(R.getLoc(),
|
|
|
|
"missing Documentation for " + getCheckerFullName(&R));
|
2018-12-21 04:20:20 +08:00
|
|
|
}
|
|
|
|
return Value;
|
|
|
|
}
|
|
|
|
|
|
|
|
static std::string getCheckerDocs(const Record &R) {
|
|
|
|
StringRef LandingPage;
|
|
|
|
if (BitsInit *BI = R.getValueAsBitsInit("Documentation")) {
|
2018-12-22 23:31:57 +08:00
|
|
|
uint64_t V = getValueFromBitsInit(BI, R);
|
2018-12-21 04:20:20 +08:00
|
|
|
if (V == 1)
|
|
|
|
LandingPage = "available_checks.html";
|
|
|
|
else if (V == 2)
|
|
|
|
LandingPage = "alpha_checks.html";
|
|
|
|
}
|
|
|
|
|
|
|
|
if (LandingPage.empty())
|
|
|
|
return "";
|
|
|
|
|
|
|
|
return (llvm::Twine("https://clang-analyzer.llvm.org/") + LandingPage + "#" +
|
|
|
|
getCheckerFullName(&R))
|
|
|
|
.str();
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
/// Retrieves the type from a CmdOptionTypeEnum typed Record object. Note that
|
|
|
|
/// the class itself has to be modified for adding a new option type in
|
|
|
|
/// CheckerBase.td.
|
|
|
|
static std::string getCheckerOptionType(const Record &R) {
|
|
|
|
if (BitsInit *BI = R.getValueAsBitsInit("Type")) {
|
|
|
|
switch(getValueFromBitsInit(BI, R)) {
|
|
|
|
case 0:
|
|
|
|
return "int";
|
|
|
|
case 1:
|
|
|
|
return "string";
|
|
|
|
case 2:
|
|
|
|
return "bool";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
PrintFatalError(R.getLoc(),
|
|
|
|
"unable to parse command line option type for "
|
|
|
|
+ getCheckerFullName(&R));
|
|
|
|
return "";
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
static void printChecker(llvm::raw_ostream &OS, const Record &R) {
|
|
|
|
OS << "CHECKER(" << "\"";
|
|
|
|
OS.write_escaped(getCheckerFullName(&R)) << "\", ";
|
|
|
|
OS << R.getName() << ", ";
|
|
|
|
OS << "\"";
|
|
|
|
OS.write_escaped(getStringValue(R, "HelpText")) << "\", ";
|
|
|
|
OS << "\"";
|
|
|
|
OS.write_escaped(getCheckerDocs(R));
|
|
|
|
OS << "\"";
|
|
|
|
}
|
|
|
|
|
2012-06-13 13:12:41 +08:00
|
|
|
namespace clang {
|
|
|
|
void EmitClangSACheckers(RecordKeeper &Records, raw_ostream &OS) {
|
2011-10-06 21:03:08 +08:00
|
|
|
std::vector<Record*> checkers = Records.getAllDerivedDefinitions("Checker");
|
|
|
|
std::vector<Record*> packages = Records.getAllDerivedDefinitions("Package");
|
|
|
|
|
2018-11-13 01:49:51 +08:00
|
|
|
using SortedRecords = llvm::StringMap<const Record *>;
|
2011-10-06 21:03:08 +08:00
|
|
|
|
2018-12-21 04:20:20 +08:00
|
|
|
OS << "// This file is automatically generated. Do not edit this file by "
|
|
|
|
"hand.\n";
|
|
|
|
|
[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
|
|
|
// Emit packages.
|
|
|
|
//
|
|
|
|
// PACKAGE(PACKAGENAME)
|
|
|
|
// - PACKAGENAME: The name of the package.
|
|
|
|
OS << "\n"
|
|
|
|
"#ifdef GET_PACKAGES\n";
|
2011-10-06 21:03:08 +08:00
|
|
|
{
|
|
|
|
SortedRecords sortedPackages;
|
|
|
|
for (unsigned i = 0, e = packages.size(); i != e; ++i)
|
|
|
|
sortedPackages[getPackageFullName(packages[i])] = packages[i];
|
|
|
|
|
|
|
|
for (SortedRecords::iterator
|
|
|
|
I = sortedPackages.begin(), E = sortedPackages.end(); I != E; ++I) {
|
|
|
|
const Record &R = *I->second;
|
|
|
|
|
|
|
|
OS << "PACKAGE(" << "\"";
|
2018-11-13 01:49:51 +08:00
|
|
|
OS.write_escaped(getPackageFullName(&R)) << '\"';
|
2011-10-06 21:03:08 +08:00
|
|
|
OS << ")\n";
|
|
|
|
}
|
|
|
|
}
|
[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
|
|
|
OS << "#endif // GET_PACKAGES\n"
|
|
|
|
"\n";
|
|
|
|
|
[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
|
|
|
// Emit a package option.
|
|
|
|
//
|
|
|
|
// PACKAGE_OPTION(OPTIONTYPE, PACKAGENAME, OPTIONNAME, DESCRIPTION, DEFAULT)
|
|
|
|
// - OPTIONTYPE: Type of the option, whether it's integer or boolean etc.
|
|
|
|
// This is important for validating user input. Note that
|
|
|
|
// it's a string, rather than an actual type: since we can
|
|
|
|
// load checkers runtime, we can't use template hackery for
|
|
|
|
// sorting this out compile-time.
|
|
|
|
// - PACKAGENAME: Name of the package.
|
|
|
|
// - OPTIONNAME: Name of the option.
|
|
|
|
// - DESCRIPTION
|
|
|
|
// - DEFAULT: The default value for this option.
|
|
|
|
//
|
|
|
|
// The full option can be specified in the command like like this:
|
|
|
|
// -analyzer-config PACKAGENAME:OPTIONNAME=VALUE
|
|
|
|
OS << "\n"
|
|
|
|
"#ifdef GET_PACKAGE_OPTIONS\n";
|
|
|
|
for (const Record *Package : packages) {
|
|
|
|
|
|
|
|
if (Package->isValueUnset("PackageOptions"))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
std::vector<Record *> PackageOptions = Package
|
|
|
|
->getValueAsListOfDefs("PackageOptions");
|
|
|
|
for (Record *PackageOpt : PackageOptions) {
|
|
|
|
OS << "PACKAGE_OPTION(\"";
|
|
|
|
OS.write_escaped(getCheckerOptionType(*PackageOpt)) << "\", \"";
|
|
|
|
OS.write_escaped(getPackageFullName(Package)) << "\", ";
|
|
|
|
OS << '\"' << getStringValue(*PackageOpt, "CmdFlag") << "\", ";
|
|
|
|
OS << '\"';
|
|
|
|
OS.write_escaped(getStringValue(*PackageOpt, "Desc")) << "\", ";
|
|
|
|
OS << '\"';
|
|
|
|
OS.write_escaped(getStringValue(*PackageOpt, "DefaultVal")) << "\"";
|
|
|
|
OS << ")\n";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
OS << "#endif // GET_PACKAGE_OPTIONS\n"
|
|
|
|
"\n";
|
|
|
|
|
[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
|
|
|
// Emit checkers.
|
|
|
|
//
|
|
|
|
// CHECKER(FULLNAME, CLASS, HELPTEXT)
|
|
|
|
// - FULLNAME: The full name of the checker, including packages, e.g.:
|
|
|
|
// alpha.cplusplus.UninitializedObject
|
|
|
|
// - CLASS: The name of the checker, with "Checker" appended, e.g.:
|
|
|
|
// UninitializedObjectChecker
|
|
|
|
// - HELPTEXT: The description of the checker.
|
|
|
|
OS << "\n"
|
|
|
|
"#ifdef GET_CHECKERS\n"
|
|
|
|
"\n";
|
|
|
|
for (const Record *checker : checkers) {
|
|
|
|
printChecker(OS, *checker);
|
2011-10-06 21:03:08 +08:00
|
|
|
OS << ")\n";
|
|
|
|
}
|
[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
|
|
|
OS << "\n"
|
|
|
|
"#endif // GET_CHECKERS\n"
|
|
|
|
"\n";
|
|
|
|
|
|
|
|
// Emit dependencies.
|
|
|
|
//
|
|
|
|
// CHECKER_DEPENDENCY(FULLNAME, DEPENDENCY)
|
|
|
|
// - FULLNAME: The full name of the checker that depends on another checker.
|
|
|
|
// - DEPENDENCY: The full name of the checker FULLNAME depends on.
|
|
|
|
OS << "\n"
|
|
|
|
"#ifdef GET_CHECKER_DEPENDENCIES\n";
|
[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
|
|
|
for (const Record *Checker : checkers) {
|
|
|
|
if (Checker->isValueUnset("Dependencies"))
|
[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;
|
|
|
|
|
|
|
|
for (const Record *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
|
|
|
Checker->getValueAsListOfDefs("Dependencies")) {
|
[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
|
|
|
OS << "CHECKER_DEPENDENCY(";
|
|
|
|
OS << '\"';
|
[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
|
|
|
OS.write_escaped(getCheckerFullName(Checker)) << "\", ";
|
[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
|
|
|
OS << '\"';
|
|
|
|
OS.write_escaped(getCheckerFullName(Dependency)) << '\"';
|
|
|
|
OS << ")\n";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
OS << "\n"
|
|
|
|
"#endif // GET_CHECKER_DEPENDENCIES\n";
|
[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
|
|
|
|
|
|
|
// Emit a package option.
|
|
|
|
//
|
|
|
|
// CHECKER_OPTION(OPTIONTYPE, CHECKERNAME, OPTIONNAME, DESCRIPTION, DEFAULT)
|
|
|
|
// - OPTIONTYPE: Type of the option, whether it's integer or boolean etc.
|
|
|
|
// This is important for validating user input. Note that
|
|
|
|
// it's a string, rather than an actual type: since we can
|
|
|
|
// load checkers runtime, we can't use template hackery for
|
|
|
|
// sorting this out compile-time.
|
|
|
|
// - CHECKERNAME: Name of the package.
|
|
|
|
// - OPTIONNAME: Name of the option.
|
|
|
|
// - DESCRIPTION
|
|
|
|
// - DEFAULT: The default value for this option.
|
|
|
|
//
|
|
|
|
// The full option can be specified in the command like like this:
|
|
|
|
// -analyzer-config CHECKERNAME:OPTIONNAME=VALUE
|
|
|
|
OS << "\n"
|
|
|
|
"#ifdef GET_CHECKER_OPTIONS\n";
|
|
|
|
for (const Record *Checker : checkers) {
|
|
|
|
|
|
|
|
if (Checker->isValueUnset("CheckerOptions"))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
std::vector<Record *> CheckerOptions = Checker
|
|
|
|
->getValueAsListOfDefs("CheckerOptions");
|
|
|
|
for (Record *CheckerOpt : CheckerOptions) {
|
|
|
|
OS << "CHECKER_OPTION(\"";
|
|
|
|
OS << getCheckerOptionType(*CheckerOpt) << "\", \"";
|
|
|
|
OS.write_escaped(getCheckerFullName(Checker)) << "\", ";
|
|
|
|
OS << '\"' << getStringValue(*CheckerOpt, "CmdFlag") << "\", ";
|
|
|
|
OS << '\"';
|
|
|
|
OS.write_escaped(getStringValue(*CheckerOpt, "Desc")) << "\", ";
|
|
|
|
OS << '\"';
|
|
|
|
OS.write_escaped(getStringValue(*CheckerOpt, "DefaultVal")) << "\"";
|
|
|
|
OS << ")";
|
|
|
|
OS << '\n';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
OS << "#endif // GET_CHECKER_OPTIONS\n"
|
|
|
|
"\n";
|
2011-10-06 21:03:08 +08:00
|
|
|
}
|
2012-06-13 13:12:41 +08:00
|
|
|
} // end namespace clang
|