2018-03-07 08:17:48 +08:00
|
|
|
//===- AnalyzerOptions.cpp - Analysis Engine Options ----------------------===//
|
2012-09-01 01:06:49 +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
|
2012-09-01 01:06:49 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// 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
|
[analyzer] Don't display implementation checkers under -analyzer-checker-help, but do under the new flag -analyzer-checker-help-hidden
During my work on analyzer dependencies, I created a great amount of new
checkers that emitted no diagnostics at all, and were purely modeling some
function or another.
However, the user shouldn't really disable/enable these by hand, hence this
patch, which hides these by default. I intentionally chose not to hide alpha
checkers, because they have a scary enough name, in my opinion, to cause no
surprise when they emit false positives or cause crashes.
The patch introduces the Hidden bit into the TableGen files (you may remember
it before I removed it in D53995), and checkers that are either marked as
hidden, or are in a package that is marked hidden won't be displayed under
-analyzer-checker-help. -analyzer-checker-help-hidden, a new flag meant for
developers only, displays the full list.
Differential Revision: https://reviews.llvm.org/D60925
llvm-svn: 359720
2019-05-02 03:56:47 +08:00
|
|
|
#define CHECKER(FULLNAME, CLASS, HELPTEXT, DOC_URI, IS_HIDDEN) \
|
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
|
|
|
|
2019-03-04 08:28:16 +08:00
|
|
|
StringRef AnalyzerOptions::getCheckerStringOption(StringRef CheckerName,
|
|
|
|
StringRef OptionName,
|
[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 DefaultVal,
|
2019-03-04 08:28:16 +08:00
|
|
|
bool SearchInParents ) const {
|
[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(!CheckerName.empty() &&
|
|
|
|
"Empty checker name! Make sure the checker object (including it's "
|
|
|
|
"bases!) if fully initialized before calling this function!");
|
2019-03-04 08:28:16 +08:00
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2019-03-04 08:28:16 +08:00
|
|
|
StringRef AnalyzerOptions::getCheckerStringOption(const ento::CheckerBase *C,
|
|
|
|
StringRef OptionName,
|
|
|
|
StringRef DefaultVal,
|
|
|
|
bool SearchInParents ) const {
|
|
|
|
return getCheckerStringOption(
|
|
|
|
C->getTagDescription(), OptionName, DefaultVal, SearchInParents);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool AnalyzerOptions::getCheckerBooleanOption(StringRef CheckerName,
|
|
|
|
StringRef OptionName,
|
|
|
|
bool DefaultVal,
|
|
|
|
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
|
|
|
return llvm::StringSwitch<bool>(
|
2019-03-04 08:28:16 +08:00
|
|
|
getCheckerStringOption(CheckerName, OptionName,
|
|
|
|
DefaultVal ? "true" : "false",
|
[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
|
|
|
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
|
|
|
}
|
|
|
|
|
2019-03-04 08:28:16 +08:00
|
|
|
bool AnalyzerOptions::getCheckerBooleanOption(const ento::CheckerBase *C,
|
|
|
|
StringRef OptionName,
|
|
|
|
bool DefaultVal,
|
|
|
|
bool SearchInParents ) const {
|
|
|
|
return getCheckerBooleanOption(
|
|
|
|
C->getTagDescription(), OptionName, DefaultVal, SearchInParents);
|
|
|
|
}
|
|
|
|
|
|
|
|
int AnalyzerOptions::getCheckerIntegerOption(StringRef CheckerName,
|
|
|
|
StringRef OptionName,
|
|
|
|
int DefaultVal,
|
|
|
|
bool SearchInParents ) const {
|
[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 Ret = DefaultVal;
|
2019-03-04 08:28:16 +08:00
|
|
|
bool HasFailed = getCheckerStringOption(CheckerName, OptionName,
|
|
|
|
std::to_string(DefaultVal),
|
[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
|
|
|
SearchInParents)
|
|
|
|
.getAsInteger(10, Ret);
|
|
|
|
assert(!HasFailed && "analyzer-config option should be numeric");
|
|
|
|
(void)HasFailed;
|
|
|
|
return Ret;
|
2015-09-12 00:55:01 +08:00
|
|
|
}
|
2019-03-04 08:28:16 +08:00
|
|
|
|
|
|
|
int AnalyzerOptions::getCheckerIntegerOption(const ento::CheckerBase *C,
|
|
|
|
StringRef OptionName,
|
|
|
|
int DefaultVal,
|
|
|
|
bool SearchInParents ) const {
|
|
|
|
return getCheckerIntegerOption(
|
|
|
|
C->getTagDescription(), OptionName, DefaultVal, SearchInParents);
|
|
|
|
}
|