2012-05-17 00:01:07 +08:00
|
|
|
//==- ExprInspectionChecker.cpp - Used for regression tests ------*- C++ -*-==//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "ClangSACheckers.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/Checker.h"
|
2012-05-17 00:01:07 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
|
2012-12-02 00:35:25 +08:00
|
|
|
#include "llvm/ADT/StringSwitch.h"
|
2012-05-17 00:01:07 +08:00
|
|
|
|
|
|
|
using namespace clang;
|
|
|
|
using namespace ento;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
class ExprInspectionChecker : public Checker< eval::Call > {
|
2014-03-08 04:03:18 +08:00
|
|
|
mutable std::unique_ptr<BugType> BT;
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
|
|
|
|
void analyzerEval(const CallExpr *CE, CheckerContext &C) const;
|
|
|
|
void analyzerCheckInlined(const CallExpr *CE, CheckerContext &C) const;
|
2013-10-04 00:57:03 +08:00
|
|
|
void analyzerWarnIfReached(const CallExpr *CE, CheckerContext &C) const;
|
2013-07-19 08:59:08 +08:00
|
|
|
void analyzerCrash(const CallExpr *CE, CheckerContext &C) const;
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
|
|
|
|
typedef void (ExprInspectionChecker::*FnCheck)(const CallExpr *,
|
|
|
|
CheckerContext &C) const;
|
|
|
|
|
2012-05-17 00:01:07 +08:00
|
|
|
public:
|
|
|
|
bool evalCall(const CallExpr *CE, CheckerContext &C) const;
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ExprInspectionChecker::evalCall(const CallExpr *CE,
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
CheckerContext &C) const {
|
2012-05-17 00:01:07 +08:00
|
|
|
// These checks should have no effect on the surrounding environment
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
// (globals should not be invalidated, etc), hence the use of evalCall.
|
|
|
|
FnCheck Handler = llvm::StringSwitch<FnCheck>(C.getCalleeName(CE))
|
|
|
|
.Case("clang_analyzer_eval", &ExprInspectionChecker::analyzerEval)
|
|
|
|
.Case("clang_analyzer_checkInlined",
|
|
|
|
&ExprInspectionChecker::analyzerCheckInlined)
|
2013-07-19 08:59:08 +08:00
|
|
|
.Case("clang_analyzer_crash", &ExprInspectionChecker::analyzerCrash)
|
2013-10-04 00:57:03 +08:00
|
|
|
.Case("clang_analyzer_warnIfReached", &ExprInspectionChecker::analyzerWarnIfReached)
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
.Default(0);
|
|
|
|
|
|
|
|
if (!Handler)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
(this->*Handler)(CE, C);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *getArgumentValueString(const CallExpr *CE,
|
|
|
|
CheckerContext &C) {
|
|
|
|
if (CE->getNumArgs() == 0)
|
|
|
|
return "Missing assertion argument";
|
|
|
|
|
2012-05-17 00:01:07 +08:00
|
|
|
ExplodedNode *N = C.getPredecessor();
|
|
|
|
const LocationContext *LC = N->getLocationContext();
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
ProgramStateRef State = N->getState();
|
|
|
|
|
|
|
|
const Expr *Assertion = CE->getArg(0);
|
|
|
|
SVal AssertionVal = State->getSVal(Assertion, LC);
|
|
|
|
|
|
|
|
if (AssertionVal.isUndef())
|
|
|
|
return "UNDEFINED";
|
|
|
|
|
|
|
|
ProgramStateRef StTrue, StFalse;
|
2014-03-02 21:01:17 +08:00
|
|
|
std::tie(StTrue, StFalse) =
|
2013-02-20 13:52:05 +08:00
|
|
|
State->assume(AssertionVal.castAs<DefinedOrUnknownSVal>());
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
|
|
|
|
if (StTrue) {
|
|
|
|
if (StFalse)
|
|
|
|
return "UNKNOWN";
|
|
|
|
else
|
|
|
|
return "TRUE";
|
|
|
|
} else {
|
|
|
|
if (StFalse)
|
|
|
|
return "FALSE";
|
|
|
|
else
|
|
|
|
llvm_unreachable("Invalid constraint; neither true or false.");
|
|
|
|
}
|
|
|
|
}
|
2012-05-17 00:01:07 +08:00
|
|
|
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
void ExprInspectionChecker::analyzerEval(const CallExpr *CE,
|
|
|
|
CheckerContext &C) const {
|
|
|
|
ExplodedNode *N = C.getPredecessor();
|
|
|
|
const LocationContext *LC = N->getLocationContext();
|
2012-05-17 00:01:07 +08:00
|
|
|
|
|
|
|
// A specific instantiation of an inlined function may have more constrained
|
|
|
|
// values than can generally be assumed. Skip the check.
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
if (LC->getCurrentStackFrame()->getParent() != 0)
|
|
|
|
return;
|
2012-05-17 00:01:07 +08:00
|
|
|
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
if (!BT)
|
2014-02-12 05:49:21 +08:00
|
|
|
BT.reset(new BugType(this, "Checking analyzer assumptions", "debug"));
|
2012-05-17 00:01:07 +08:00
|
|
|
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
BugReport *R = new BugReport(*BT, getArgumentValueString(CE, C), N);
|
2012-11-02 09:53:40 +08:00
|
|
|
C.emitReport(R);
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
}
|
|
|
|
|
2013-10-04 00:57:03 +08:00
|
|
|
void ExprInspectionChecker::analyzerWarnIfReached(const CallExpr *CE,
|
|
|
|
CheckerContext &C) const {
|
|
|
|
ExplodedNode *N = C.getPredecessor();
|
|
|
|
|
|
|
|
if (!BT)
|
2014-02-12 05:49:21 +08:00
|
|
|
BT.reset(new BugType(this, "Checking analyzer assumptions", "debug"));
|
2013-10-04 00:57:03 +08:00
|
|
|
|
|
|
|
BugReport *R = new BugReport(*BT, "REACHABLE", N);
|
|
|
|
C.emitReport(R);
|
|
|
|
}
|
|
|
|
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
void ExprInspectionChecker::analyzerCheckInlined(const CallExpr *CE,
|
|
|
|
CheckerContext &C) const {
|
|
|
|
ExplodedNode *N = C.getPredecessor();
|
|
|
|
const LocationContext *LC = N->getLocationContext();
|
2012-05-17 00:01:07 +08:00
|
|
|
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
// An inlined function could conceivably also be analyzed as a top-level
|
|
|
|
// function. We ignore this case and only emit a message (TRUE or FALSE)
|
|
|
|
// when we are analyzing it as an inlined function. This means that
|
|
|
|
// clang_analyzer_checkInlined(true) should always print TRUE, but
|
|
|
|
// clang_analyzer_checkInlined(false) should never actually print anything.
|
|
|
|
if (LC->getCurrentStackFrame()->getParent() == 0)
|
|
|
|
return;
|
2012-05-17 00:01:07 +08:00
|
|
|
|
|
|
|
if (!BT)
|
2014-02-12 05:49:21 +08:00
|
|
|
BT.reset(new BugType(this, "Checking analyzer assumptions", "debug"));
|
2012-05-17 00:01:07 +08:00
|
|
|
|
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
2012-08-11 06:26:29 +08:00
|
|
|
BugReport *R = new BugReport(*BT, getArgumentValueString(CE, C), N);
|
2012-11-02 09:53:40 +08:00
|
|
|
C.emitReport(R);
|
2012-05-17 00:01:07 +08:00
|
|
|
}
|
|
|
|
|
2013-07-19 08:59:08 +08:00
|
|
|
void ExprInspectionChecker::analyzerCrash(const CallExpr *CE,
|
|
|
|
CheckerContext &C) const {
|
|
|
|
LLVM_BUILTIN_TRAP;
|
|
|
|
}
|
|
|
|
|
2012-05-17 00:01:07 +08:00
|
|
|
void ento::registerExprInspectionChecker(CheckerManager &Mgr) {
|
|
|
|
Mgr.registerChecker<ExprInspectionChecker>();
|
|
|
|
}
|
|
|
|
|