2018-06-27 22:56:12 +08:00
|
|
|
//===- unittest/StaticAnalyzer/AnalyzerOptionsTest.cpp - SA Options test --===//
|
2015-03-05 01:59:34 +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
|
2015-03-05 01:59:34 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/Checker.h"
|
|
|
|
#include "gtest/gtest.h"
|
|
|
|
|
|
|
|
namespace clang {
|
|
|
|
namespace ento {
|
|
|
|
|
2016-11-08 15:23:32 +08:00
|
|
|
TEST(StaticAnalyzerOptions, getRegisteredCheckers) {
|
|
|
|
auto IsDebugChecker = [](StringRef CheckerName) {
|
|
|
|
return CheckerName.startswith("debug");
|
|
|
|
};
|
|
|
|
auto IsAlphaChecker = [](StringRef CheckerName) {
|
|
|
|
return CheckerName.startswith("alpha");
|
|
|
|
};
|
|
|
|
const auto &AllCheckers =
|
|
|
|
AnalyzerOptions::getRegisteredCheckers(/*IncludeExperimental=*/true);
|
|
|
|
EXPECT_FALSE(llvm::any_of(AllCheckers, IsDebugChecker));
|
|
|
|
EXPECT_TRUE(llvm::any_of(AllCheckers, IsAlphaChecker));
|
|
|
|
|
|
|
|
const auto &StableCheckers = AnalyzerOptions::getRegisteredCheckers();
|
|
|
|
EXPECT_FALSE(llvm::any_of(StableCheckers, IsDebugChecker));
|
|
|
|
EXPECT_FALSE(llvm::any_of(StableCheckers, IsAlphaChecker));
|
|
|
|
}
|
|
|
|
|
2015-03-05 01:59:34 +08:00
|
|
|
TEST(StaticAnalyzerOptions, SearchInParentPackageTests) {
|
|
|
|
AnalyzerOptions Opts;
|
|
|
|
Opts.Config["Outer.Inner.CheckerOne:Option"] = "true";
|
|
|
|
Opts.Config["Outer.Inner:Option"] = "false";
|
|
|
|
Opts.Config["Outer.Inner:Option2"] = "true";
|
|
|
|
Opts.Config["Outer:Option2"] = "false";
|
|
|
|
|
|
|
|
struct CheckerOneMock : CheckerBase {
|
|
|
|
StringRef getTagDescription() const override {
|
|
|
|
return "Outer.Inner.CheckerOne";
|
|
|
|
}
|
|
|
|
};
|
|
|
|
struct CheckerTwoMock : CheckerBase {
|
|
|
|
StringRef getTagDescription() const override {
|
|
|
|
return "Outer.Inner.CheckerTwo";
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
// Checker one has Option specified as true. It should read true regardless of
|
|
|
|
// search mode.
|
|
|
|
CheckerOneMock CheckerOne;
|
[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
|
|
|
EXPECT_TRUE(Opts.getCheckerBooleanOption("Option", false, &CheckerOne));
|
2018-02-06 21:12:29 +08:00
|
|
|
// The package option is overridden with a checker option.
|
[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
|
|
|
EXPECT_TRUE(Opts.getCheckerBooleanOption("Option", false, &CheckerOne,
|
|
|
|
true));
|
2018-02-06 21:12:29 +08:00
|
|
|
// The Outer package option is overridden by the Inner package option. No
|
2015-03-05 01:59:34 +08:00
|
|
|
// package option is specified.
|
[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
|
|
|
EXPECT_TRUE(Opts.getCheckerBooleanOption("Option2", false, &CheckerOne,
|
|
|
|
true));
|
2015-03-05 01:59:34 +08:00
|
|
|
// No package option is specified and search in packages is turned off. The
|
|
|
|
// default value should be returned.
|
[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
|
|
|
EXPECT_FALSE(Opts.getCheckerBooleanOption("Option2", false, &CheckerOne));
|
|
|
|
EXPECT_TRUE(Opts.getCheckerBooleanOption("Option2", true, &CheckerOne));
|
2015-03-05 01:59:34 +08:00
|
|
|
|
|
|
|
// Checker true has no option specified. It should get the default value when
|
|
|
|
// search in parents turned off and false when search in parents turned on.
|
|
|
|
CheckerTwoMock CheckerTwo;
|
[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
|
|
|
EXPECT_FALSE(Opts.getCheckerBooleanOption("Option", false, &CheckerTwo));
|
|
|
|
EXPECT_TRUE(Opts.getCheckerBooleanOption("Option", true, &CheckerTwo));
|
|
|
|
EXPECT_FALSE(Opts.getCheckerBooleanOption("Option", true, &CheckerTwo, true));
|
2015-03-05 01:59:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST(StaticAnalyzerOptions, StringOptions) {
|
|
|
|
AnalyzerOptions Opts;
|
|
|
|
Opts.Config["Outer.Inner.CheckerOne:Option"] = "StringValue";
|
|
|
|
|
|
|
|
struct CheckerOneMock : CheckerBase {
|
|
|
|
StringRef getTagDescription() const override {
|
|
|
|
return "Outer.Inner.CheckerOne";
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
CheckerOneMock CheckerOne;
|
|
|
|
EXPECT_TRUE("StringValue" ==
|
[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
|
|
|
Opts.getCheckerStringOption("Option", "DefaultValue", &CheckerOne));
|
2015-03-05 01:59:34 +08:00
|
|
|
EXPECT_TRUE("DefaultValue" ==
|
[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
|
|
|
Opts.getCheckerStringOption("Option2", "DefaultValue", &CheckerOne));
|
2015-03-05 01:59:34 +08:00
|
|
|
}
|
|
|
|
} // end namespace ento
|
|
|
|
} // end namespace clang
|