2018-03-07 08:17:48 +08:00
|
|
|
//===- AnalyzerOptions.cpp - Analysis Engine Options ----------------------===//
|
2012-09-01 01:06:49 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains special accessors for analyzer configuration options
|
|
|
|
// with string representations.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
|
2015-03-05 01:59:34 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/Checker.h"
|
2012-10-03 04:31:56 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "llvm/ADT/StringSwitch.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
#include "llvm/ADT/Twine.h"
|
2013-01-31 03:12:39 +08:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2012-10-03 04:31:56 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include <cassert>
|
|
|
|
#include <cstddef>
|
|
|
|
#include <utility>
|
|
|
|
#include <vector>
|
2012-09-01 01:06:49 +08:00
|
|
|
|
|
|
|
using namespace clang;
|
2015-03-05 01:59:34 +08:00
|
|
|
using namespace ento;
|
2012-09-11 06:37:19 +08:00
|
|
|
using namespace llvm;
|
2012-09-01 01:06:49 +08:00
|
|
|
|
2016-11-08 15:23:32 +08:00
|
|
|
std::vector<StringRef>
|
|
|
|
AnalyzerOptions::getRegisteredCheckers(bool IncludeExperimental /* = false */) {
|
|
|
|
static const StringRef StaticAnalyzerChecks[] = {
|
|
|
|
#define GET_CHECKERS
|
2018-12-21 04:20:20 +08:00
|
|
|
#define CHECKER(FULLNAME, CLASS, HELPTEXT, DOC_URI) \
|
2016-11-08 15:23:32 +08:00
|
|
|
FULLNAME,
|
|
|
|
#include "clang/StaticAnalyzer/Checkers/Checkers.inc"
|
|
|
|
#undef CHECKER
|
|
|
|
#undef GET_CHECKERS
|
|
|
|
};
|
|
|
|
std::vector<StringRef> Result;
|
|
|
|
for (StringRef CheckName : StaticAnalyzerChecks) {
|
|
|
|
if (!CheckName.startswith("debug.") &&
|
|
|
|
(IncludeExperimental || !CheckName.startswith("alpha.")))
|
|
|
|
Result.push_back(CheckName);
|
|
|
|
}
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2018-11-02 23:50:44 +08:00
|
|
|
ExplorationStrategyKind
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
AnalyzerOptions::getExplorationStrategy() const {
|
2018-11-02 23:50:44 +08:00
|
|
|
auto K =
|
|
|
|
llvm::StringSwitch<llvm::Optional<ExplorationStrategyKind>>(
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
ExplorationStrategy)
|
2018-11-02 23:50:44 +08:00
|
|
|
.Case("dfs", ExplorationStrategyKind::DFS)
|
|
|
|
.Case("bfs", ExplorationStrategyKind::BFS)
|
|
|
|
.Case("unexplored_first",
|
|
|
|
ExplorationStrategyKind::UnexploredFirst)
|
|
|
|
.Case("unexplored_first_queue",
|
|
|
|
ExplorationStrategyKind::UnexploredFirstQueue)
|
|
|
|
.Case("unexplored_first_location_queue",
|
|
|
|
ExplorationStrategyKind::UnexploredFirstLocationQueue)
|
|
|
|
.Case("bfs_block_dfs_contents",
|
|
|
|
ExplorationStrategyKind::BFSBlockDFSContents)
|
|
|
|
.Default(None);
|
|
|
|
assert(K.hasValue() && "User mode is invalid.");
|
|
|
|
return K.getValue();
|
2018-02-02 10:01:55 +08:00
|
|
|
}
|
|
|
|
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
IPAKind AnalyzerOptions::getIPAMode() const {
|
|
|
|
auto K = llvm::StringSwitch<llvm::Optional<IPAKind>>(IPAMode)
|
2018-11-02 23:50:44 +08:00
|
|
|
.Case("none", IPAK_None)
|
|
|
|
.Case("basic-inlining", IPAK_BasicInlining)
|
|
|
|
.Case("inlining", IPAK_Inlining)
|
|
|
|
.Case("dynamic", IPAK_DynamicDispatch)
|
|
|
|
.Case("dynamic-bifurcate", IPAK_DynamicDispatchBifurcate)
|
|
|
|
.Default(None);
|
|
|
|
assert(K.hasValue() && "IPA Mode is invalid.");
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2018-11-02 23:50:44 +08:00
|
|
|
return K.getValue();
|
2013-01-25 07:15:30 +08:00
|
|
|
}
|
|
|
|
|
2012-09-01 01:06:49 +08:00
|
|
|
bool
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
AnalyzerOptions::mayInlineCXXMemberFunction(
|
|
|
|
CXXInlineableMemberKind Param) const {
|
2013-01-25 07:15:30 +08:00
|
|
|
if (getIPAMode() < IPAK_Inlining)
|
2012-09-01 01:06:49 +08:00
|
|
|
return false;
|
|
|
|
|
2018-11-02 23:50:44 +08:00
|
|
|
auto K =
|
|
|
|
llvm::StringSwitch<llvm::Optional<CXXInlineableMemberKind>>(
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
CXXMemberInliningMode)
|
2018-11-02 23:50:44 +08:00
|
|
|
.Case("constructors", CIMK_Constructors)
|
|
|
|
.Case("destructors", CIMK_Destructors)
|
|
|
|
.Case("methods", CIMK_MemberFunctions)
|
|
|
|
.Case("none", CIMK_None)
|
|
|
|
.Default(None);
|
2012-09-01 01:06:49 +08:00
|
|
|
|
2018-11-02 23:50:44 +08:00
|
|
|
assert(K.hasValue() && "Invalid c++ member function inlining mode.");
|
2012-09-01 01:06:49 +08:00
|
|
|
|
2018-11-02 23:50:44 +08:00
|
|
|
return *K >= Param;
|
2012-09-01 01:06:49 +08:00
|
|
|
}
|
[analyzer] Always include destructors in the analysis CFG.
While destructors will continue to not be inlined (unless the analyzer
config option 'c++-inlining' is set to 'destructors'), leaving them out
of the CFG is an incomplete model of the behavior of an object, and
can cause false positive warnings (like PR13751, now working).
Destructors for temporaries are still not on by default, since
(a) we haven't actually checked this code to be sure it's fully correct
(in particular, we probably need to be very careful with regard to
lifetime-extension when a temporary is bound to a reference,
C++11 [class.temporary]p5), and
(b) ExprEngine doesn't actually do anything when it sees a temporary
destructor in the CFG -- not even invalidate the object region.
To enable temporary destructors, set the 'cfg-temporary-dtors' analyzer
config option to '1'. The old -cfg-add-implicit-dtors cc1 option, which
controlled all implicit destructors, has been removed.
llvm-svn: 163264
2012-09-06 06:55:23 +08:00
|
|
|
|
[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
2018-11-05 11:50:37 +08:00
|
|
|
StringRef AnalyzerOptions::getCheckerStringOption(StringRef OptionName,
|
|
|
|
StringRef DefaultVal,
|
|
|
|
const CheckerBase *C,
|
|
|
|
bool SearchInParents) const {
|
|
|
|
assert(C);
|
2015-03-05 01:59:34 +08:00
|
|
|
// Search for a package option if the option for the checker is not specified
|
|
|
|
// and search in parents is enabled.
|
[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
2018-11-05 11:50:37 +08:00
|
|
|
StringRef CheckerName = C->getTagDescription();
|
|
|
|
|
|
|
|
assert(!CheckerName.empty() &&
|
|
|
|
"Empty checker name! Make sure the checker object (including it's "
|
|
|
|
"bases!) if fully initialized before calling this function!");
|
2015-03-05 01:59:34 +08:00
|
|
|
ConfigTable::const_iterator E = Config.end();
|
|
|
|
do {
|
|
|
|
ConfigTable::const_iterator I =
|
|
|
|
Config.find((Twine(CheckerName) + ":" + OptionName).str());
|
|
|
|
if (I != E)
|
|
|
|
return StringRef(I->getValue());
|
|
|
|
size_t Pos = CheckerName.rfind('.');
|
|
|
|
if (Pos == StringRef::npos)
|
[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
2018-11-05 11:50:37 +08:00
|
|
|
return DefaultVal;
|
2015-03-05 01:59:34 +08:00
|
|
|
CheckerName = CheckerName.substr(0, Pos);
|
|
|
|
} while (!CheckerName.empty() && SearchInParents);
|
[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
2018-11-05 11:50:37 +08:00
|
|
|
return DefaultVal;
|
2015-03-05 01:59:34 +08:00
|
|
|
}
|
|
|
|
|
[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
2018-11-05 11:50:37 +08:00
|
|
|
bool AnalyzerOptions::getCheckerBooleanOption(StringRef Name, bool DefaultVal,
|
|
|
|
const CheckerBase *C,
|
|
|
|
bool SearchInParents) const {
|
2012-09-11 05:27:35 +08:00
|
|
|
// FIXME: We should emit a warning here if the value is something other than
|
|
|
|
// "true", "false", or the empty string (meaning the default value),
|
|
|
|
// but the AnalyzerOptions doesn't have access to a diagnostic engine.
|
[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
2018-11-05 11:50:37 +08:00
|
|
|
assert(C);
|
|
|
|
return llvm::StringSwitch<bool>(
|
[analyzer] Evaluate all non-checker config options before analysis
In earlier patches regarding AnalyzerOptions, a lot of effort went into
gathering all config options, and changing the interface so that potential
misuse can be eliminited.
Up until this point, AnalyzerOptions only evaluated an option when it was
querried. For example, if we had a "-no-false-positives" flag, AnalyzerOptions
would store an Optional field for it that would be None up until somewhere in
the code until the flag's getter function is called.
However, now that we're confident that we've gathered all configs, we can
evaluate off of them before analysis, so we can emit a error on invalid input
even if that prticular flag will not matter in that particular run of the
analyzer. Another very big benefit of this is that debug.ConfigDumper will now
show the value of all configs every single time.
Also, almost all options related class have a similar interface, so uniformity
is also a benefit.
The implementation for errors on invalid input will be commited shorty.
Differential Revision: https://reviews.llvm.org/D53692
llvm-svn: 348031
2018-12-01 04:44:00 +08:00
|
|
|
getCheckerStringOption(Name, DefaultVal ? "true" : "false", C,
|
|
|
|
SearchInParents))
|
2012-10-02 02:28:19 +08:00
|
|
|
.Case("true", true)
|
|
|
|
.Case("false", false)
|
|
|
|
.Default(DefaultVal);
|
2012-09-11 05:27:35 +08:00
|
|
|
}
|
|
|
|
|
[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
2018-11-05 11:50:37 +08:00
|
|
|
int AnalyzerOptions::getCheckerIntegerOption(StringRef Name, int DefaultVal,
|
2015-03-05 01:59:34 +08:00
|
|
|
const CheckerBase *C,
|
[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered
One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.
This also forces developers who'd like to add a new option to register it
properly in the .def file.
This is done by
* making the third checker pointer parameter non-optional, and checked by an
assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
internal use,
* Renamed these methods accordingly (mind the consistent name for once with
getBooleanOption!):
- getOptionAsString -> getCheckerStringOption,
- getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
moved the logic to getStringOption and getCheckerStringOption. This did cause
some code duplication, but that's the only way I could do it, now that checker
and non-checker options are separated. Note that the non-checker version
inserts the new option to the ConfigTable with the default value, but the
checker version only attempts to find already existing entries. This is how
it always worked, but this is clunky and I might end reworking that too, so we
can eventually get a ConfigTable that contains the entire configuration of the
analyzer.
Differential Revision: https://reviews.llvm.org/D53483
llvm-svn: 346113
2018-11-05 11:50:37 +08:00
|
|
|
bool SearchInParents) const {
|
|
|
|
int Ret = DefaultVal;
|
|
|
|
bool HasFailed = getCheckerStringOption(Name, std::to_string(DefaultVal), C,
|
|
|
|
SearchInParents)
|
|
|
|
.getAsInteger(10, Ret);
|
|
|
|
assert(!HasFailed && "analyzer-config option should be numeric");
|
|
|
|
(void)HasFailed;
|
|
|
|
return Ret;
|
2015-09-12 00:55:01 +08:00
|
|
|
}
|