maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/StaticAnalyzer/Checkers/TestAfterDivZeroChecker.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

267 lines
8.2 KiB
C++
Raw Normal View History

[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
//== TestAfterDivZeroChecker.cpp - Test after division by zero checker --*--==//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
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
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
//
//===----------------------------------------------------------------------===//
//
// This defines TestAfterDivZeroChecker, a builtin check that performs checks
// for division by zero where the division occurs before comparison with zero.
//
//===----------------------------------------------------------------------===//
[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept. It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend, whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can imagine, used to circumvent the problem that the registry functions of the checkers are located in the clangStaticAnalyzerCheckers library, but that library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend depends on both of those libraries. One can make the observation however, that CheckerRegistry has no place in Core, it isn't used there at all! The only place where it is used is Frontend, which is where it ultimately belongs. This move implies that since include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function: class CheckerRegistry; void registerBuiltinCheckers(CheckerRegistry &registry); it had to re purposed, as CheckerRegistry is no longer available to clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h, which actually describes it a lot better -- it does not contain the registration functions for checkers, but only those generated by the tblgen files. Differential Revision: https://reviews.llvm.org/D54436 llvm-svn: 349275
2018-12-16 00:23:51 +08:00
#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
#include "clang/StaticAnalyzer/Core/Checker.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
#include "llvm/ADT/FoldingSet.h"
using namespace clang;
using namespace ento;
namespace {
class ZeroState {
private:
SymbolRef ZeroSymbol;
unsigned BlockID;
const StackFrameContext *SFC;
public:
ZeroState(SymbolRef S, unsigned B, const StackFrameContext *SFC)
: ZeroSymbol(S), BlockID(B), SFC(SFC) {}
const StackFrameContext *getStackFrameContext() const { return SFC; }
bool operator==(const ZeroState &X) const {
return BlockID == X.BlockID && SFC == X.SFC && ZeroSymbol == X.ZeroSymbol;
}
bool operator<(const ZeroState &X) const {
if (BlockID != X.BlockID)
return BlockID < X.BlockID;
if (SFC != X.SFC)
return SFC < X.SFC;
return ZeroSymbol < X.ZeroSymbol;
}
void Profile(llvm::FoldingSetNodeID &ID) const {
ID.AddInteger(BlockID);
ID.AddPointer(SFC);
ID.AddPointer(ZeroSymbol);
}
};
[analyzer] Do not run visitors until the fixpoint, run only once. In the current implementation, we run visitors until the fixed point is reached. That is, if a visitor adds another visitor, the currently processed path is destroyed, all diagnostics is discarded, and it is regenerated again, until it's no longer modified. This pattern has a few negative implications: - This loop does not even guarantee to terminate. E.g. just imagine two visitors bouncing a diagnostics around. - Performance-wise, e.g. for sqlite3 all visitors are being re-run at least 10 times for some bugs. We have already seen a few reports where it leads to timeouts. - If we want to add more computationally intense visitors, this will become worse. - From architectural standpoint, the current layout requires copying visitors, which is conceptually wrong, and can be annoying (e.g. no unique_ptr on visitors allowed). The proposed change is a much simpler architecture: the outer loop processes nodes upwards, and whenever the visitor is added it only processes current nodes and above, thus guaranteeing termination. Differential Revision: https://reviews.llvm.org/D47856 llvm-svn: 335666
2018-06-27 05:12:08 +08:00
class DivisionBRVisitor : public BugReporterVisitor {
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
private:
SymbolRef ZeroSymbol;
const StackFrameContext *SFC;
TestAfterDivZeroChecker.cpp: Avoid member initializer. It is unsupported in msc17. llvm-svn: 212789
2014-07-11 08:32:35 +08:00
bool Satisfied;
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
public:
DivisionBRVisitor(SymbolRef ZeroSymbol, const StackFrameContext *SFC)
TestAfterDivZeroChecker.cpp: Avoid member initializer. It is unsupported in msc17. llvm-svn: 212789
2014-07-11 08:32:35 +08:00
: ZeroSymbol(ZeroSymbol), SFC(SFC), Satisfied(false) {}
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
void Profile(llvm::FoldingSetNodeID &ID) const override {
ID.Add(ZeroSymbol);
ID.Add(SFC);
}
[analyzer][NFC] Refactoring BugReporter.cpp P3.: std::shared_pointer<PathDiagnosticPiece> -> PathDiagnosticPieceRef find clang/ -type f -exec sed -i 's/std::shared_ptr<PathDiagnosticPiece>/PathDiagnosticPieceRef/g' {} \; git diff -U3 --no-color HEAD^ | clang-format-diff-6.0 -p1 -i Just as C++ is meant to be refactored, right? Differential Revision: https://reviews.llvm.org/D65381 llvm-svn: 368717
2019-08-14 00:45:48 +08:00
PathDiagnosticPieceRef VisitNode(const ExplodedNode *Succ,
BugReporterContext &BRC,
[analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports. Checkers are now required to specify whether they're creating a path-sensitive report or a path-insensitive report by constructing an object of the respective type. This makes BugReporter more independent from the rest of the Static Analyzer because all Analyzer-specific code is now in sub-classes. Differential Revision: https://reviews.llvm.org/D66572 llvm-svn: 371450
2019-09-10 04:34:40 +08:00
PathSensitiveBugReport &BR) override;
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
};
class TestAfterDivZeroChecker
: public Checker<check::PreStmt<BinaryOperator>, check::BranchCondition,
check::EndFunction> {
mutable std::unique_ptr<BuiltinBug> DivZeroBug;
void reportBug(SVal Val, CheckerContext &C) const;
public:
void checkPreStmt(const BinaryOperator *B, CheckerContext &C) const;
void checkBranchCondition(const Stmt *Condition, CheckerContext &C) const;
[analyzer] Make checkEndFunction() give access to the return statement. Differential Revision: https://reviews.llvm.org/D49387 llvm-svn: 337215
2018-07-17 04:47:45 +08:00
void checkEndFunction(const ReturnStmt *RS, CheckerContext &C) const;
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
void setDivZeroMap(SVal Var, CheckerContext &C) const;
bool hasDivZeroMap(SVal Var, const CheckerContext &C) const;
bool isZero(SVal S, CheckerContext &C) const;
};
} // end anonymous namespace
REGISTER_SET_WITH_PROGRAMSTATE(DivZeroMap, ZeroState)
[analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports. Checkers are now required to specify whether they're creating a path-sensitive report or a path-insensitive report by constructing an object of the respective type. This makes BugReporter more independent from the rest of the Static Analyzer because all Analyzer-specific code is now in sub-classes. Differential Revision: https://reviews.llvm.org/D66572 llvm-svn: 371450
2019-09-10 04:34:40 +08:00
PathDiagnosticPieceRef
DivisionBRVisitor::VisitNode(const ExplodedNode *Succ, BugReporterContext &BRC,
PathSensitiveBugReport &BR) {
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
if (Satisfied)
return nullptr;
const Expr *E = nullptr;
if (Optional<PostStmt> P = Succ->getLocationAs<PostStmt>())
if (const BinaryOperator *BO = P->getStmtAs<BinaryOperator>()) {
BinaryOperator::Opcode Op = BO->getOpcode();
if (Op == BO_Div || Op == BO_Rem || Op == BO_DivAssign ||
Op == BO_RemAssign) {
E = BO->getRHS();
}
}
if (!E)
return nullptr;
[analyzer] introduce getSVal(Stmt *) helper on ExplodedNode, make sure the helper is used consistently In most cases using `N->getState()->getSVal(E, N->getLocationContext())` is ugly, verbose, and also opens up more surface area for bugs if an inconsistent location context is used. This patch introduces a helper on an exploded node, and ensures consistent usage of either `ExplodedNode::getSVal` or `CheckContext::getSVal` across the codebase. As a result, a large number of redundant lines is removed. Differential Revision: https://reviews.llvm.org/D42155 llvm-svn: 322753
2018-01-18 04:27:29 +08:00
SVal S = Succ->getSVal(E);
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
if (ZeroSymbol == S.getAsSymbol() && SFC == Succ->getStackFrame()) {
Satisfied = true;
// Construct a new PathDiagnosticPiece.
ProgramPoint P = Succ->getLocation();
PathDiagnosticLocation L =
PathDiagnosticLocation::create(P, BRC.getSourceManager());
if (!L.isValid() || !L.asLocation().isValid())
return nullptr;
Migrate PathDiagnosticPiece to std::shared_ptr Simplifies and makes explicit the memory ownership model rather than implicitly passing/acquiring ownership. llvm-svn: 291143
2017-01-06 01:26:53 +08:00
return std::make_shared<PathDiagnosticEventPiece>(
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
L, "Division with compared value made here");
}
return nullptr;
}
bool TestAfterDivZeroChecker::isZero(SVal S, CheckerContext &C) const {
Optional<DefinedSVal> DSV = S.getAs<DefinedSVal>();
if (!DSV)
return false;
ConstraintManager &CM = C.getConstraintManager();
return !CM.assume(C.getState(), *DSV, true);
}
void TestAfterDivZeroChecker::setDivZeroMap(SVal Var, CheckerContext &C) const {
SymbolRef SR = Var.getAsSymbol();
if (!SR)
return;
ProgramStateRef State = C.getState();
State =
State->add<DivZeroMap>(ZeroState(SR, C.getBlockID(), C.getStackFrame()));
C.addTransition(State);
}
bool TestAfterDivZeroChecker::hasDivZeroMap(SVal Var,
const CheckerContext &C) const {
SymbolRef SR = Var.getAsSymbol();
if (!SR)
return false;
ZeroState ZS(SR, C.getBlockID(), C.getStackFrame());
return C.getState()->contains<DivZeroMap>(ZS);
}
void TestAfterDivZeroChecker::reportBug(SVal Val, CheckerContext &C) const {
[analyzer] Add generateErrorNode() APIs to CheckerContext. The analyzer trims unnecessary nodes from the exploded graph before reporting path diagnostics. However, in some cases it can trim all nodes (including the error node), leading to an assertion failure (see https://llvm.org/bugs/show_bug.cgi?id=24184). This commit addresses the issue by adding two new APIs to CheckerContext to explicitly create error nodes. Unless the client provides a custom tag, these APIs tag the node with the checker's tag -- preventing it from being trimmed. The generateErrorNode() method creates a sink error node, while generateNonFatalErrorNode() creates an error node for a path that should continue being explored. The intent is that one of these two methods should be used whenever a checker creates an error node. This commit updates the checkers to use these APIs. These APIs (unlike addTransition() and generateSink()) do not take an explicit Pred node. This is because there are not any error nodes in the checkers that were created with an explicit different than the default (the CheckerContext's Pred node). It also changes generateSink() to require state and pred nodes (previously these were optional) to reduce confusion. Additionally, there were several cases where checkers did check whether a generated node could be null; we now explicitly check for null in these places. This commit also includes a test case written by Ying Yi as part of http://reviews.llvm.org/D12163 (that patch originally addressed this issue but was reverted because it introduced false positive regressions). Differential Revision: http://reviews.llvm.org/D12780 llvm-svn: 247859
2015-09-17 06:03:05 +08:00
if (ExplodedNode *N = C.generateErrorNode(C.getState())) {
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
if (!DivZeroBug)
DivZeroBug.reset(new BuiltinBug(this, "Division by zero"));
[analyzer] NFC: Introduce sub-classes for path-sensitive and basic reports. Checkers are now required to specify whether they're creating a path-sensitive report or a path-insensitive report by constructing an object of the respective type. This makes BugReporter more independent from the rest of the Static Analyzer because all Analyzer-specific code is now in sub-classes. Differential Revision: https://reviews.llvm.org/D66572 llvm-svn: 371450
2019-09-10 04:34:40 +08:00
auto R = std::make_unique<PathSensitiveBugReport>(
Clarify pointer ownership semantics by hoisting the std::unique_ptr creation to the caller instead of hiding it in emitReport. NFC. llvm-svn: 240400
2015-06-23 21:15:32 +08:00
*DivZeroBug, "Value being compared against zero has already been used "
"for division",
N);
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
[Clang] Migrate llvm::make_unique to std::make_unique Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
2019-08-15 07:04:18 +08:00
R->addVisitor(std::make_unique<DivisionBRVisitor>(Val.getAsSymbol(),
unique_ptrify BugReporter::visitors llvm-svn: 217205
2014-09-05 07:54:33 +08:00
C.getStackFrame()));
Clarify pointer ownership semantics by hoisting the std::unique_ptr creation to the caller instead of hiding it in emitReport. NFC. llvm-svn: 240400
2015-06-23 21:15:32 +08:00
C.emitReport(std::move(R));
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
}
}
[analyzer] [NFC] Remove unused parameters, as found by -Wunused-parameter Differential Revision: https://reviews.llvm.org/D52640 llvm-svn: 343353
2018-09-29 02:49:41 +08:00
void TestAfterDivZeroChecker::checkEndFunction(const ReturnStmt *,
[analyzer] Make checkEndFunction() give access to the return statement. Differential Revision: https://reviews.llvm.org/D49387 llvm-svn: 337215
2018-07-17 04:47:45 +08:00
CheckerContext &C) const {
[analyzer] Check for code testing a variable for 0 after using it as a denominator. This new checker, alpha.core.TestAfterDivZero, catches issues like this: int sum = ... int avg = sum / count; // potential division by zero... if (count == 0) { ... } // ...caught here Because the analyzer does not necessarily explore /all/ paths through a program, this check is restricted to only work on zero checks that immediately follow a division operation (/ % /= %=). This could later be expanded to handle checks dominated by a division operation but not necessarily in the same CFG block. Patch by Anders Rönnholm! (with very minor modifications by me) llvm-svn: 212731
2014-07-11 00:10:52 +08:00
ProgramStateRef State = C.getState();
DivZeroMapTy DivZeroes = State->get<DivZeroMap>();
if (DivZeroes.isEmpty())
return;
DivZeroMapTy::Factory &F = State->get_context<DivZeroMap>();
for (llvm::ImmutableSet<ZeroState>::iterator I = DivZeroes.begin(),
E = DivZeroes.end();
I != E; ++I) {
ZeroState ZS = *I;
if (ZS.getStackFrameContext() == C.getStackFrame())
DivZeroes = F.remove(DivZeroes, ZS);
}
C.addTransition(State->set<DivZeroMap>(DivZeroes));
}
void TestAfterDivZeroChecker::checkPreStmt(const BinaryOperator *B,
CheckerContext &C) const {
BinaryOperator::Opcode Op = B->getOpcode();
if (Op == BO_Div || Op == BO_Rem || Op == BO_DivAssign ||
Op == BO_RemAssign) {
SVal S = C.getSVal(B->getRHS());
if (!isZero(S, C))
setDivZeroMap(S, C);
}
}
void TestAfterDivZeroChecker::checkBranchCondition(const Stmt *Condition,
CheckerContext &C) const {
if (const BinaryOperator *B = dyn_cast<BinaryOperator>(Condition)) {
if (B->isComparisonOp()) {
const IntegerLiteral *IntLiteral = dyn_cast<IntegerLiteral>(B->getRHS());
bool LRHS = true;
if (!IntLiteral) {
IntLiteral = dyn_cast<IntegerLiteral>(B->getLHS());
LRHS = false;
}
if (!IntLiteral || IntLiteral->getValue() != 0)
return;
SVal Val = C.getSVal(LRHS ? B->getLHS() : B->getRHS());
if (hasDivZeroMap(Val, C))
reportBug(Val, C);
}
} else if (const UnaryOperator *U = dyn_cast<UnaryOperator>(Condition)) {
if (U->getOpcode() == UO_LNot) {
SVal Val;
if (const ImplicitCastExpr *I =
dyn_cast<ImplicitCastExpr>(U->getSubExpr()))
Val = C.getSVal(I->getSubExpr());
if (hasDivZeroMap(Val, C))
reportBug(Val, C);
else {
Val = C.getSVal(U->getSubExpr());
if (hasDivZeroMap(Val, C))
reportBug(Val, C);
}
}
} else if (const ImplicitCastExpr *IE =
dyn_cast<ImplicitCastExpr>(Condition)) {
SVal Val = C.getSVal(IE->getSubExpr());
if (hasDivZeroMap(Val, C))
reportBug(Val, C);
else {
SVal Val = C.getSVal(Condition);
if (hasDivZeroMap(Val, C))
reportBug(Val, C);
}
}
}
void ento::registerTestAfterDivZeroChecker(CheckerManager &mgr) {
mgr.registerChecker<TestAfterDivZeroChecker>();
}
[analyzer] Supply all checkers with a shouldRegister function Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. This will force every checker to implement this function, but maybe it isn't that bad: I saw a lot of ObjC or C++ specific checkers that should probably not register themselves based on some LangOptions (mine too), but they do anyways. A big benefit of this is that all registry functions now register their checker, once it is called, registration is guaranteed. This patch is a part of a greater effort to reinvent checker registration, more info here: D54438#1315953 Differential Revision: https://reviews.llvm.org/D55424 llvm-svn: 352277
2019-01-26 22:23:08 +08:00
[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions Some checkers may not only depend on language options but also analyzer options. To make this possible this patch changes the parameter of the shouldRegister* function to CheckerManager to be able to query the analyzer options when deciding whether the checker should be registered. Differential Revision: https://reviews.llvm.org/D75271
2020-03-27 21:29:31 +08:00
bool ento::shouldRegisterTestAfterDivZeroChecker(const CheckerManager &mgr) {
[analyzer] Supply all checkers with a shouldRegister function Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. This will force every checker to implement this function, but maybe it isn't that bad: I saw a lot of ObjC or C++ specific checkers that should probably not register themselves based on some LangOptions (mine too), but they do anyways. A big benefit of this is that all registry functions now register their checker, once it is called, registration is guaranteed. This patch is a part of a greater effort to reinvent checker registration, more info here: D54438#1315953 Differential Revision: https://reviews.llvm.org/D55424 llvm-svn: 352277
2019-01-26 22:23:08 +08:00
return true;
}