2018-03-07 08:17:48 +08:00
|
|
|
//===- BugReporter.cpp - Generate PathDiagnostics for bugs ----------------===//
|
2008-04-03 12:42:52 +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
|
2008-04-03 12:42:52 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines BugReporter, a utility class for generating
|
2009-06-26 08:05:51 +08:00
|
|
|
// PathDiagnostics.
|
2008-04-03 12:42:52 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2011-02-10 09:03:03 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "clang/AST/Decl.h"
|
|
|
|
#include "clang/AST/DeclBase.h"
|
2012-01-28 20:06:22 +08:00
|
|
|
#include "clang/AST/DeclObjC.h"
|
2008-04-03 12:42:52 +08:00
|
|
|
#include "clang/AST/Expr.h"
|
2013-06-17 20:56:08 +08:00
|
|
|
#include "clang/AST/ExprCXX.h"
|
2009-03-28 04:55:39 +08:00
|
|
|
#include "clang/AST/ParentMap.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "clang/AST/Stmt.h"
|
2013-06-17 20:56:08 +08:00
|
|
|
#include "clang/AST/StmtCXX.h"
|
2014-01-07 19:51:46 +08:00
|
|
|
#include "clang/AST/StmtObjC.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "clang/Analysis/AnalysisDeclContext.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "clang/Analysis/CFG.h"
|
2016-12-22 22:48:52 +08:00
|
|
|
#include "clang/Analysis/CFGStmtMap.h"
|
2008-04-03 12:42:52 +08:00
|
|
|
#include "clang/Analysis/ProgramPoint.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "clang/Basic/LLVM.h"
|
|
|
|
#include "clang/Basic/SourceLocation.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "clang/Basic/SourceManager.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
|
2011-02-10 09:03:03 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/Checker.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/CheckerManager.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
|
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h"
|
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2008-06-18 13:34:07 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "llvm/ADT/DenseSet.h"
|
|
|
|
#include "llvm/ADT/FoldingSet.h"
|
|
|
|
#include "llvm/ADT/None.h"
|
|
|
|
#include "llvm/ADT/Optional.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2013-03-16 05:41:53 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
#include "llvm/ADT/iterator_range.h"
|
|
|
|
#include "llvm/Support/Casting.h"
|
|
|
|
#include "llvm/Support/Compiler.h"
|
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2018-03-07 08:17:48 +08:00
|
|
|
#include <algorithm>
|
|
|
|
#include <cassert>
|
|
|
|
#include <cstddef>
|
|
|
|
#include <iterator>
|
2014-03-09 19:36:40 +08:00
|
|
|
#include <memory>
|
2009-03-13 07:41:59 +08:00
|
|
|
#include <queue>
|
2018-03-07 08:17:48 +08:00
|
|
|
#include <string>
|
|
|
|
#include <tuple>
|
|
|
|
#include <utility>
|
|
|
|
#include <vector>
|
2008-04-03 12:42:52 +08:00
|
|
|
|
|
|
|
using namespace clang;
|
2010-12-23 15:20:52 +08:00
|
|
|
using namespace ento;
|
2008-04-03 12:42:52 +08:00
|
|
|
|
2014-04-22 11:17:02 +08:00
|
|
|
#define DEBUG_TYPE "BugReporter"
|
|
|
|
|
2013-03-16 05:41:53 +08:00
|
|
|
STATISTIC(MaxBugClassSize,
|
|
|
|
"The maximum number of bug reports in the same equivalence class");
|
|
|
|
STATISTIC(MaxValidBugClassSize,
|
|
|
|
"The maximum number of bug reports in the same equivalence class "
|
|
|
|
"where at least one report is valid (not suppressed)");
|
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
BugReporterVisitor::~BugReporterVisitor() = default;
|
2010-03-21 02:01:57 +08:00
|
|
|
|
2011-12-20 10:48:34 +08:00
|
|
|
void BugReporterContext::anchor() {}
|
|
|
|
|
2009-02-05 07:49:09 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2009-04-01 07:00:32 +08:00
|
|
|
// Helper routines for walking the ExplodedGraph and fetching statements.
|
2009-02-05 07:49:09 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2008-04-03 12:42:52 +08:00
|
|
|
|
2011-08-13 07:37:29 +08:00
|
|
|
static const Stmt *GetPreviousStmt(const ExplodedNode *N) {
|
2013-04-24 07:57:43 +08:00
|
|
|
for (N = N->getFirstPred(); N; N = N->getFirstPred())
|
|
|
|
if (const Stmt *S = PathDiagnosticLocation::getStmt(N))
|
2009-02-24 06:44:26 +08:00
|
|
|
return S;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2014-05-27 10:45:47 +08:00
|
|
|
return nullptr;
|
2009-02-24 06:44:26 +08:00
|
|
|
}
|
|
|
|
|
2009-07-23 06:35:28 +08:00
|
|
|
static inline const Stmt*
|
2011-08-13 07:37:29 +08:00
|
|
|
GetCurrentOrPreviousStmt(const ExplodedNode *N) {
|
2013-04-24 07:57:43 +08:00
|
|
|
if (const Stmt *S = PathDiagnosticLocation::getStmt(N))
|
2009-02-24 06:44:26 +08:00
|
|
|
return S;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-02-24 06:44:26 +08:00
|
|
|
return GetPreviousStmt(N);
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2012-02-29 07:06:21 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Diagnostic cleanup.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2012-10-26 06:07:10 +08:00
|
|
|
static PathDiagnosticEventPiece *
|
|
|
|
eventsDescribeSameCondition(PathDiagnosticEventPiece *X,
|
|
|
|
PathDiagnosticEventPiece *Y) {
|
|
|
|
// Prefer diagnostics that come from ConditionBRVisitor over
|
2016-10-05 16:19:49 +08:00
|
|
|
// those that came from TrackConstraintBRVisitor,
|
|
|
|
// unless the one from ConditionBRVisitor is
|
|
|
|
// its generic fallback diagnostic.
|
2012-10-26 06:07:10 +08:00
|
|
|
const void *tagPreferred = ConditionBRVisitor::getTag();
|
|
|
|
const void *tagLesser = TrackConstraintBRVisitor::getTag();
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-10-26 06:07:10 +08:00
|
|
|
if (X->getLocation() != Y->getLocation())
|
2014-05-27 10:45:47 +08:00
|
|
|
return nullptr;
|
|
|
|
|
2012-10-26 06:07:10 +08:00
|
|
|
if (X->getTag() == tagPreferred && Y->getTag() == tagLesser)
|
2016-10-05 16:19:49 +08:00
|
|
|
return ConditionBRVisitor::isPieceMessageGeneric(X) ? Y : X;
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-10-26 06:07:10 +08:00
|
|
|
if (Y->getTag() == tagPreferred && X->getTag() == tagLesser)
|
2016-10-05 16:19:49 +08:00
|
|
|
return ConditionBRVisitor::isPieceMessageGeneric(Y) ? X : Y;
|
2014-05-27 10:45:47 +08:00
|
|
|
|
|
|
|
return nullptr;
|
2012-10-26 06:07:10 +08:00
|
|
|
}
|
|
|
|
|
2012-10-27 00:02:36 +08:00
|
|
|
/// An optimization pass over PathPieces that removes redundant diagnostics
|
|
|
|
/// generated by both ConditionBRVisitor and TrackConstraintBRVisitor. Both
|
|
|
|
/// BugReporterVisitors use different methods to generate diagnostics, with
|
|
|
|
/// one capable of emitting diagnostics in some cases but not in others. This
|
|
|
|
/// can lead to redundant diagnostic pieces at the same point in a path.
|
|
|
|
static void removeRedundantMsgs(PathPieces &path) {
|
2012-10-26 06:07:10 +08:00
|
|
|
unsigned N = path.size();
|
|
|
|
if (N < 2)
|
|
|
|
return;
|
2012-10-27 00:02:36 +08:00
|
|
|
// NOTE: this loop intentionally is not using an iterator. Instead, we
|
|
|
|
// are streaming the path and modifying it in place. This is done by
|
|
|
|
// grabbing the front, processing it, and if we decide to keep it append
|
|
|
|
// it to the end of the path. The entire path is processed in this way.
|
2012-10-26 06:07:10 +08:00
|
|
|
for (unsigned i = 0; i < N; ++i) {
|
2017-01-06 01:26:53 +08:00
|
|
|
auto piece = std::move(path.front());
|
2012-10-26 06:07:10 +08:00
|
|
|
path.pop_front();
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-10-26 06:07:10 +08:00
|
|
|
switch (piece->getKind()) {
|
2016-10-07 23:23:02 +08:00
|
|
|
case PathDiagnosticPiece::Call:
|
2017-01-06 01:26:53 +08:00
|
|
|
removeRedundantMsgs(cast<PathDiagnosticCallPiece>(*piece).path);
|
2012-10-26 06:07:10 +08:00
|
|
|
break;
|
2016-10-07 23:23:02 +08:00
|
|
|
case PathDiagnosticPiece::Macro:
|
2017-01-06 01:26:53 +08:00
|
|
|
removeRedundantMsgs(cast<PathDiagnosticMacroPiece>(*piece).subPieces);
|
2012-10-26 06:07:10 +08:00
|
|
|
break;
|
2016-10-07 23:23:02 +08:00
|
|
|
case PathDiagnosticPiece::ControlFlow:
|
2012-10-26 06:07:10 +08:00
|
|
|
break;
|
2016-10-07 23:23:02 +08:00
|
|
|
case PathDiagnosticPiece::Event: {
|
2012-10-26 06:07:10 +08:00
|
|
|
if (i == N-1)
|
|
|
|
break;
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
if (auto *nextEvent =
|
2014-07-05 11:08:06 +08:00
|
|
|
dyn_cast<PathDiagnosticEventPiece>(path.front().get())) {
|
2018-03-07 08:17:48 +08:00
|
|
|
auto *event = cast<PathDiagnosticEventPiece>(piece.get());
|
2012-10-26 06:07:10 +08:00
|
|
|
// Check to see if we should keep one of the two pieces. If we
|
|
|
|
// come up with a preference, record which piece to keep, and consume
|
|
|
|
// another piece from the path.
|
2017-01-06 01:26:53 +08:00
|
|
|
if (auto *pieceToKeep =
|
|
|
|
eventsDescribeSameCondition(event, nextEvent)) {
|
|
|
|
piece = std::move(pieceToKeep == event ? piece : path.front());
|
2012-10-26 06:07:10 +08:00
|
|
|
path.pop_front();
|
|
|
|
++i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2016-10-07 23:23:02 +08:00
|
|
|
case PathDiagnosticPiece::Note:
|
|
|
|
break;
|
2012-10-26 06:07:10 +08:00
|
|
|
}
|
2017-01-06 01:26:53 +08:00
|
|
|
path.push_back(std::move(piece));
|
2012-10-26 06:07:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-03 08:32:44 +08:00
|
|
|
/// A map from PathDiagnosticPiece to the LocationContext of the inlined
|
|
|
|
/// function call it represents.
|
2018-03-07 08:17:48 +08:00
|
|
|
using LocationContextMap =
|
|
|
|
llvm::DenseMap<const PathPieces *, const LocationContext *>;
|
2013-05-03 08:32:44 +08:00
|
|
|
|
2012-02-29 07:06:21 +08:00
|
|
|
/// Recursively scan through a path and prune out calls and macros pieces
|
|
|
|
/// that aren't needed. Return true if afterwards the path contains
|
2012-12-08 03:56:29 +08:00
|
|
|
/// "interesting stuff" which means it shouldn't be pruned from the parent path.
|
2013-05-03 08:32:44 +08:00
|
|
|
static bool removeUnneededCalls(PathPieces &pieces, BugReport *R,
|
2018-04-04 02:52:30 +08:00
|
|
|
LocationContextMap &LCM,
|
|
|
|
bool IsInteresting = false) {
|
|
|
|
bool containsSomethingInteresting = IsInteresting;
|
2012-02-29 07:06:21 +08:00
|
|
|
const unsigned N = pieces.size();
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-02-29 07:06:21 +08:00
|
|
|
for (unsigned i = 0 ; i < N ; ++i) {
|
|
|
|
// Remove the front piece from the path. If it is still something we
|
|
|
|
// want to keep once we are done, we will push it back on the end.
|
2017-01-06 01:26:53 +08:00
|
|
|
auto piece = std::move(pieces.front());
|
2012-02-29 07:06:21 +08:00
|
|
|
pieces.pop_front();
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-03-01 08:05:06 +08:00
|
|
|
switch (piece->getKind()) {
|
|
|
|
case PathDiagnosticPiece::Call: {
|
2017-01-06 01:26:53 +08:00
|
|
|
auto &call = cast<PathDiagnosticCallPiece>(*piece);
|
2012-08-30 05:22:37 +08:00
|
|
|
// Check if the location context is interesting.
|
2017-01-06 01:26:53 +08:00
|
|
|
assert(LCM.count(&call.path));
|
2018-04-04 02:52:30 +08:00
|
|
|
if (!removeUnneededCalls(call.path, R, LCM,
|
|
|
|
R->isInteresting(LCM[&call.path])))
|
2012-11-15 10:07:23 +08:00
|
|
|
continue;
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-03-01 08:05:06 +08:00
|
|
|
containsSomethingInteresting = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case PathDiagnosticPiece::Macro: {
|
2017-01-06 01:26:53 +08:00
|
|
|
auto ¯o = cast<PathDiagnosticMacroPiece>(*piece);
|
2018-04-04 02:52:30 +08:00
|
|
|
if (!removeUnneededCalls(macro.subPieces, R, LCM, IsInteresting))
|
2012-03-01 08:05:06 +08:00
|
|
|
continue;
|
2012-02-29 07:06:21 +08:00
|
|
|
containsSomethingInteresting = true;
|
2012-03-01 08:05:06 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case PathDiagnosticPiece::Event: {
|
2017-01-06 01:26:53 +08:00
|
|
|
auto &event = cast<PathDiagnosticEventPiece>(*piece);
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-03-01 08:05:06 +08:00
|
|
|
// We never throw away an event, but we do throw it away wholesale
|
|
|
|
// as part of a path if we throw the entire path away.
|
2017-01-06 01:26:53 +08:00
|
|
|
containsSomethingInteresting |= !event.isPrunable();
|
2012-03-01 08:05:06 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case PathDiagnosticPiece::ControlFlow:
|
|
|
|
break;
|
2016-10-07 23:23:02 +08:00
|
|
|
|
|
|
|
case PathDiagnosticPiece::Note:
|
|
|
|
break;
|
2012-02-29 07:06:21 +08:00
|
|
|
}
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2017-01-06 01:26:53 +08:00
|
|
|
pieces.push_back(std::move(piece));
|
2012-02-29 07:06:21 +08:00
|
|
|
}
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-02-29 07:06:21 +08:00
|
|
|
return containsSomethingInteresting;
|
|
|
|
}
|
|
|
|
|
2013-05-25 05:43:11 +08:00
|
|
|
/// Returns true if the given decl has been implicitly given a body, either by
|
|
|
|
/// the analyzer or by the compiler proper.
|
|
|
|
static bool hasImplicitBody(const Decl *D) {
|
|
|
|
assert(D);
|
|
|
|
return D->isImplicit() || !D->hasBody();
|
|
|
|
}
|
|
|
|
|
2012-12-08 03:56:29 +08:00
|
|
|
/// Recursively scan through a path and make sure that all call pieces have
|
2015-09-08 11:50:52 +08:00
|
|
|
/// valid locations.
|
2014-05-27 10:45:47 +08:00
|
|
|
static void
|
|
|
|
adjustCallLocations(PathPieces &Pieces,
|
|
|
|
PathDiagnosticLocation *LastCallLocation = nullptr) {
|
2018-03-07 08:17:48 +08:00
|
|
|
for (const auto &I : Pieces) {
|
|
|
|
auto *Call = dyn_cast<PathDiagnosticCallPiece>(I.get());
|
2012-12-08 03:56:29 +08:00
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
if (!Call)
|
2012-12-08 03:56:29 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (LastCallLocation) {
|
2013-05-25 05:43:11 +08:00
|
|
|
bool CallerIsImplicit = hasImplicitBody(Call->getCaller());
|
|
|
|
if (CallerIsImplicit || !Call->callEnter.asLocation().isValid())
|
2012-12-08 03:56:29 +08:00
|
|
|
Call->callEnter = *LastCallLocation;
|
2013-05-25 05:43:11 +08:00
|
|
|
if (CallerIsImplicit || !Call->callReturn.asLocation().isValid())
|
2012-12-08 03:56:29 +08:00
|
|
|
Call->callReturn = *LastCallLocation;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Recursively clean out the subclass. Keep this call around if
|
|
|
|
// it contains any informative diagnostics.
|
|
|
|
PathDiagnosticLocation *ThisCallLocation;
|
2013-01-22 02:28:30 +08:00
|
|
|
if (Call->callEnterWithin.asLocation().isValid() &&
|
2013-05-25 05:43:11 +08:00
|
|
|
!hasImplicitBody(Call->getCallee()))
|
2012-12-08 03:56:29 +08:00
|
|
|
ThisCallLocation = &Call->callEnterWithin;
|
|
|
|
else
|
|
|
|
ThisCallLocation = &Call->callEnter;
|
|
|
|
|
|
|
|
assert(ThisCallLocation && "Outermost call has an invalid location");
|
|
|
|
adjustCallLocations(Call->path, ThisCallLocation);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-17 01:45:35 +08:00
|
|
|
/// Remove edges in and out of C++ default initializer expressions. These are
|
|
|
|
/// for fields that have in-class initializers, as opposed to being initialized
|
|
|
|
/// explicitly in a constructor or braced list.
|
|
|
|
static void removeEdgesToDefaultInitializers(PathPieces &Pieces) {
|
|
|
|
for (PathPieces::iterator I = Pieces.begin(), E = Pieces.end(); I != E;) {
|
2017-01-06 01:26:53 +08:00
|
|
|
if (auto *C = dyn_cast<PathDiagnosticCallPiece>(I->get()))
|
2013-10-17 01:45:35 +08:00
|
|
|
removeEdgesToDefaultInitializers(C->path);
|
|
|
|
|
2017-01-06 01:26:53 +08:00
|
|
|
if (auto *M = dyn_cast<PathDiagnosticMacroPiece>(I->get()))
|
2013-10-17 01:45:35 +08:00
|
|
|
removeEdgesToDefaultInitializers(M->subPieces);
|
|
|
|
|
2017-01-06 01:26:53 +08:00
|
|
|
if (auto *CF = dyn_cast<PathDiagnosticControlFlowPiece>(I->get())) {
|
2013-10-17 01:45:35 +08:00
|
|
|
const Stmt *Start = CF->getStartLocation().asStmt();
|
|
|
|
const Stmt *End = CF->getEndLocation().asStmt();
|
|
|
|
if (Start && isa<CXXDefaultInitExpr>(Start)) {
|
|
|
|
I = Pieces.erase(I);
|
|
|
|
continue;
|
|
|
|
} else if (End && isa<CXXDefaultInitExpr>(End)) {
|
2014-03-02 20:20:24 +08:00
|
|
|
PathPieces::iterator Next = std::next(I);
|
2013-10-17 01:45:35 +08:00
|
|
|
if (Next != E) {
|
2017-01-06 01:26:53 +08:00
|
|
|
if (auto *NextCF =
|
|
|
|
dyn_cast<PathDiagnosticControlFlowPiece>(Next->get())) {
|
2013-10-17 01:45:35 +08:00
|
|
|
NextCF->setStartLocation(CF->getStartLocation());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
I = Pieces.erase(I);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
I++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-07 06:02:58 +08:00
|
|
|
/// Remove all pieces with invalid locations as these cannot be serialized.
|
|
|
|
/// We might have pieces with invalid locations as a result of inlining Body
|
|
|
|
/// Farm generated functions.
|
|
|
|
static void removePiecesWithInvalidLocations(PathPieces &Pieces) {
|
2013-06-07 06:32:11 +08:00
|
|
|
for (PathPieces::iterator I = Pieces.begin(), E = Pieces.end(); I != E;) {
|
2017-01-06 01:26:53 +08:00
|
|
|
if (auto *C = dyn_cast<PathDiagnosticCallPiece>(I->get()))
|
2013-06-07 06:02:58 +08:00
|
|
|
removePiecesWithInvalidLocations(C->path);
|
|
|
|
|
2017-01-06 01:26:53 +08:00
|
|
|
if (auto *M = dyn_cast<PathDiagnosticMacroPiece>(I->get()))
|
2013-06-07 06:02:58 +08:00
|
|
|
removePiecesWithInvalidLocations(M->subPieces);
|
|
|
|
|
|
|
|
if (!(*I)->getLocation().isValid() ||
|
|
|
|
!(*I)->getLocation().asLocation().isValid()) {
|
2013-06-07 06:32:11 +08:00
|
|
|
I = Pieces.erase(I);
|
2013-06-07 06:02:58 +08:00
|
|
|
continue;
|
|
|
|
}
|
2013-06-07 06:32:11 +08:00
|
|
|
I++;
|
2013-06-07 06:02:58 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-02-24 06:44:26 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2009-04-01 07:00:32 +08:00
|
|
|
// PathDiagnosticBuilder and its associated routines and helper objects.
|
2009-02-24 06:44:26 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2009-02-24 07:13:51 +08:00
|
|
|
|
2009-03-27 13:06:10 +08:00
|
|
|
namespace {
|
2018-03-07 08:17:48 +08:00
|
|
|
|
2009-11-28 14:07:30 +08:00
|
|
|
class PathDiagnosticBuilder : public BugReporterContext {
|
2009-04-01 04:22:36 +08:00
|
|
|
BugReport *R;
|
2011-09-26 08:51:36 +08:00
|
|
|
PathDiagnosticConsumer *PDC;
|
2018-03-07 08:17:48 +08:00
|
|
|
|
2009-09-09 23:08:12 +08:00
|
|
|
public:
|
2012-02-24 15:12:52 +08:00
|
|
|
const LocationContext *LC;
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2009-05-07 05:39:49 +08:00
|
|
|
PathDiagnosticBuilder(GRBugReporter &br,
|
2013-03-16 09:07:53 +08:00
|
|
|
BugReport *r, InterExplodedGraphMap &Backmap,
|
2011-09-26 08:51:36 +08:00
|
|
|
PathDiagnosticConsumer *pdc)
|
[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
|
|
|
: BugReporterContext(br, Backmap), R(r), PDC(pdc),
|
2018-03-07 08:17:48 +08:00
|
|
|
LC(r->getErrorNode()->getLocationContext()) {}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-08-13 07:37:29 +08:00
|
|
|
PathDiagnosticLocation ExecutionContinues(const ExplodedNode *N);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-08-13 07:37:29 +08:00
|
|
|
PathDiagnosticLocation ExecutionContinues(llvm::raw_string_ostream &os,
|
|
|
|
const ExplodedNode *N);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-08-19 06:37:56 +08:00
|
|
|
BugReport *getBugReport() { return R; }
|
|
|
|
|
2010-09-16 11:50:38 +08:00
|
|
|
Decl const &getCodeDecl() { return R->getErrorNode()->getCodeDecl(); }
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-02-24 15:12:52 +08:00
|
|
|
ParentMap& getParentMap() { return LC->getParentMap(); }
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-02 01:18:21 +08:00
|
|
|
const Stmt *getParent(const Stmt *S) {
|
|
|
|
return getParentMap().getParent(S);
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-03-28 05:16:25 +08:00
|
|
|
PathDiagnosticLocation getEnclosingStmtLocation(const Stmt *S);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2011-09-26 08:51:36 +08:00
|
|
|
PathDiagnosticConsumer::PathGenerationScheme getGenerationScheme() const {
|
2018-06-13 03:08:00 +08:00
|
|
|
return PDC ? PDC->getGenerationScheme() : PathDiagnosticConsumer::Minimal;
|
2009-04-01 04:22:36 +08:00
|
|
|
}
|
|
|
|
|
2009-03-27 13:06:10 +08:00
|
|
|
bool supportsLogicalOpControlFlow() const {
|
|
|
|
return PDC ? PDC->supportsLogicalOpControlFlow() : true;
|
2009-09-09 23:08:12 +08:00
|
|
|
}
|
2009-03-27 13:06:10 +08:00
|
|
|
};
|
2018-03-07 08:17:48 +08:00
|
|
|
|
|
|
|
} // namespace
|
2009-03-27 13:06:10 +08:00
|
|
|
|
2009-03-28 04:55:39 +08:00
|
|
|
PathDiagnosticLocation
|
2011-08-13 07:37:29 +08:00
|
|
|
PathDiagnosticBuilder::ExecutionContinues(const ExplodedNode *N) {
|
2013-04-24 07:57:43 +08:00
|
|
|
if (const Stmt *S = PathDiagnosticLocation::getNextStmt(N))
|
2012-02-24 15:12:52 +08:00
|
|
|
return PathDiagnosticLocation(S, getSourceManager(), LC);
|
2009-03-28 04:55:39 +08:00
|
|
|
|
2011-09-17 03:18:30 +08:00
|
|
|
return PathDiagnosticLocation::createDeclEnd(N->getLocationContext(),
|
|
|
|
getSourceManager());
|
2009-03-13 02:41:53 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-03-28 04:55:39 +08:00
|
|
|
PathDiagnosticLocation
|
2011-08-13 07:37:29 +08:00
|
|
|
PathDiagnosticBuilder::ExecutionContinues(llvm::raw_string_ostream &os,
|
|
|
|
const ExplodedNode *N) {
|
2008-05-07 02:11:09 +08:00
|
|
|
// Slow, but probably doesn't matter.
|
2009-02-24 06:44:26 +08:00
|
|
|
if (os.str().empty())
|
|
|
|
os << ' ';
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-03-28 04:55:39 +08:00
|
|
|
const PathDiagnosticLocation &Loc = ExecutionContinues(N);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-03-28 04:55:39 +08:00
|
|
|
if (Loc.asStmt())
|
2009-02-24 06:44:26 +08:00
|
|
|
os << "Execution continues on line "
|
2011-07-26 05:09:52 +08:00
|
|
|
<< getSourceManager().getExpansionLineNumber(Loc.asLocation())
|
2009-05-07 05:39:49 +08:00
|
|
|
<< '.';
|
2009-12-05 04:34:31 +08:00
|
|
|
else {
|
|
|
|
os << "Execution jumps to the end of the ";
|
|
|
|
const Decl *D = N->getLocationContext()->getDecl();
|
|
|
|
if (isa<ObjCMethodDecl>(D))
|
|
|
|
os << "method";
|
|
|
|
else if (isa<FunctionDecl>(D))
|
|
|
|
os << "function";
|
|
|
|
else {
|
|
|
|
assert(isa<BlockDecl>(D));
|
|
|
|
os << "anonymous block";
|
|
|
|
}
|
|
|
|
os << '.';
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-03-13 02:41:53 +08:00
|
|
|
return Loc;
|
2008-05-07 02:11:09 +08:00
|
|
|
}
|
|
|
|
|
2013-06-04 06:59:48 +08:00
|
|
|
static const Stmt *getEnclosingParent(const Stmt *S, const ParentMap &PM) {
|
2009-05-15 09:50:15 +08:00
|
|
|
if (isa<Expr>(S) && PM.isConsumedExpr(cast<Expr>(S)))
|
2013-06-04 06:59:48 +08:00
|
|
|
return PM.getParentIgnoreParens(S);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-05-15 09:50:15 +08:00
|
|
|
const Stmt *Parent = PM.getParentIgnoreParens(S);
|
2013-06-04 06:59:48 +08:00
|
|
|
if (!Parent)
|
2014-05-27 10:45:47 +08:00
|
|
|
return nullptr;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-06-04 06:59:48 +08:00
|
|
|
switch (Parent->getStmtClass()) {
|
|
|
|
case Stmt::ForStmtClass:
|
|
|
|
case Stmt::DoStmtClass:
|
|
|
|
case Stmt::WhileStmtClass:
|
|
|
|
case Stmt::ObjCForCollectionStmtClass:
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
case Stmt::CXXForRangeStmtClass:
|
2013-06-04 06:59:48 +08:00
|
|
|
return Parent;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2014-05-27 10:45:47 +08:00
|
|
|
return nullptr;
|
2009-05-15 09:50:15 +08:00
|
|
|
}
|
|
|
|
|
2013-06-04 06:59:48 +08:00
|
|
|
static PathDiagnosticLocation
|
|
|
|
getEnclosingStmtLocation(const Stmt *S, SourceManager &SMgr, const ParentMap &P,
|
2013-06-04 06:59:53 +08:00
|
|
|
const LocationContext *LC, bool allowNestedContexts) {
|
2013-06-04 06:59:48 +08:00
|
|
|
if (!S)
|
2018-03-07 08:17:48 +08:00
|
|
|
return {};
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-06-04 06:59:48 +08:00
|
|
|
while (const Stmt *Parent = getEnclosingParent(S, P)) {
|
2009-03-28 11:37:59 +08:00
|
|
|
switch (Parent->getStmtClass()) {
|
2009-04-01 14:13:56 +08:00
|
|
|
case Stmt::BinaryOperatorClass: {
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *B = cast<BinaryOperator>(Parent);
|
2009-04-01 14:13:56 +08:00
|
|
|
if (B->isLogicalOp())
|
2013-06-04 06:59:53 +08:00
|
|
|
return PathDiagnosticLocation(allowNestedContexts ? B : S, SMgr, LC);
|
2009-04-01 14:13:56 +08:00
|
|
|
break;
|
2009-09-09 23:08:12 +08:00
|
|
|
}
|
2009-03-28 11:37:59 +08:00
|
|
|
case Stmt::CompoundStmtClass:
|
|
|
|
case Stmt::StmtExprClass:
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(S, SMgr, LC);
|
2009-03-28 12:08:14 +08:00
|
|
|
case Stmt::ChooseExprClass:
|
|
|
|
// Similar to '?' if we are referring to condition, just have the edge
|
|
|
|
// point to the entire choose expression.
|
2013-06-04 06:59:53 +08:00
|
|
|
if (allowNestedContexts || cast<ChooseExpr>(Parent)->getCond() == S)
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(Parent, SMgr, LC);
|
2009-03-28 12:08:14 +08:00
|
|
|
else
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(S, SMgr, LC);
|
2011-02-17 18:25:35 +08:00
|
|
|
case Stmt::BinaryConditionalOperatorClass:
|
2009-03-28 12:08:14 +08:00
|
|
|
case Stmt::ConditionalOperatorClass:
|
|
|
|
// For '?', if we are referring to condition, just have the edge point
|
|
|
|
// to the entire '?' expression.
|
2013-06-04 06:59:53 +08:00
|
|
|
if (allowNestedContexts ||
|
|
|
|
cast<AbstractConditionalOperator>(Parent)->getCond() == S)
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(Parent, SMgr, LC);
|
2009-03-28 12:08:14 +08:00
|
|
|
else
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(S, SMgr, LC);
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
case Stmt::CXXForRangeStmtClass:
|
|
|
|
if (cast<CXXForRangeStmt>(Parent)->getBody() == S)
|
|
|
|
return PathDiagnosticLocation(S, SMgr, LC);
|
|
|
|
break;
|
2009-03-28 11:37:59 +08:00
|
|
|
case Stmt::DoStmtClass:
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(S, SMgr, LC);
|
2009-03-28 11:37:59 +08:00
|
|
|
case Stmt::ForStmtClass:
|
|
|
|
if (cast<ForStmt>(Parent)->getBody() == S)
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(S, SMgr, LC);
|
2009-09-09 23:08:12 +08:00
|
|
|
break;
|
2009-03-28 11:37:59 +08:00
|
|
|
case Stmt::IfStmtClass:
|
|
|
|
if (cast<IfStmt>(Parent)->getCond() != S)
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(S, SMgr, LC);
|
2009-04-28 12:23:15 +08:00
|
|
|
break;
|
2009-03-28 11:37:59 +08:00
|
|
|
case Stmt::ObjCForCollectionStmtClass:
|
|
|
|
if (cast<ObjCForCollectionStmt>(Parent)->getBody() == S)
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(S, SMgr, LC);
|
2009-03-28 11:37:59 +08:00
|
|
|
break;
|
|
|
|
case Stmt::WhileStmtClass:
|
|
|
|
if (cast<WhileStmt>(Parent)->getCond() != S)
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(S, SMgr, LC);
|
2009-03-28 11:37:59 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2009-03-28 05:16:25 +08:00
|
|
|
S = Parent;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-03-28 05:16:25 +08:00
|
|
|
assert(S && "Cannot have null Stmt for PathDiagnosticLocation");
|
2009-05-12 06:19:32 +08:00
|
|
|
|
2011-09-15 09:08:34 +08:00
|
|
|
return PathDiagnosticLocation(S, SMgr, LC);
|
2009-03-28 05:16:25 +08:00
|
|
|
}
|
|
|
|
|
2013-06-04 06:59:48 +08:00
|
|
|
PathDiagnosticLocation
|
|
|
|
PathDiagnosticBuilder::getEnclosingStmtLocation(const Stmt *S) {
|
|
|
|
assert(S && "Null Stmt passed to getEnclosingStmtLocation");
|
2013-06-04 06:59:53 +08:00
|
|
|
return ::getEnclosingStmtLocation(S, getSourceManager(), getParentMap(), LC,
|
|
|
|
/*allowNestedContexts=*/false);
|
2013-06-04 06:59:48 +08:00
|
|
|
}
|
|
|
|
|
2009-02-05 07:49:09 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2009-04-01 07:00:32 +08:00
|
|
|
// "Minimal" path diagnostic generation algorithm.
|
2009-02-05 07:49:09 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2018-03-07 08:17:48 +08:00
|
|
|
using StackDiagPair =
|
|
|
|
std::pair<PathDiagnosticCallPiece *, const ExplodedNode *>;
|
|
|
|
using StackDiagVector = SmallVector<StackDiagPair, 6>;
|
2012-03-17 07:24:20 +08:00
|
|
|
|
2017-01-06 01:26:53 +08:00
|
|
|
static void updateStackPiecesWithMessage(PathDiagnosticPiece &P,
|
2012-03-17 07:24:20 +08:00
|
|
|
StackDiagVector &CallStack) {
|
2012-03-16 05:13:02 +08:00
|
|
|
// If the piece contains a special message, add it to all the call
|
|
|
|
// pieces on the active stack.
|
2018-03-07 08:17:48 +08:00
|
|
|
if (auto *ep = dyn_cast<PathDiagnosticEventPiece>(&P)) {
|
2012-03-17 07:24:20 +08:00
|
|
|
if (ep->hasCallStackHint())
|
2018-03-07 08:17:48 +08:00
|
|
|
for (const auto &I : CallStack) {
|
|
|
|
PathDiagnosticCallPiece *CP = I.first;
|
|
|
|
const ExplodedNode *N = I.second;
|
2012-03-17 21:06:05 +08:00
|
|
|
std::string stackMsg = ep->getCallStackMessage(N);
|
2012-03-17 07:24:20 +08:00
|
|
|
|
2012-03-16 05:13:02 +08:00
|
|
|
// The last message on the path to final bug is the most important
|
|
|
|
// one. Since we traverse the path backwards, do not add the message
|
|
|
|
// if one has been previously added.
|
2012-03-17 07:24:20 +08:00
|
|
|
if (!CP->hasCallStackMessage())
|
|
|
|
CP->setCallStackMessage(stackMsg);
|
|
|
|
}
|
2012-03-16 05:13:02 +08:00
|
|
|
}
|
|
|
|
}
|
2009-02-05 07:49:09 +08:00
|
|
|
|
2018-10-31 22:54:27 +08:00
|
|
|
static void CompactMacroExpandedPieces(PathPieces &path,
|
|
|
|
const SourceManager& SM);
|
2009-04-07 07:06:54 +08:00
|
|
|
|
2012-03-16 05:13:02 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
std::shared_ptr<PathDiagnosticControlFlowPiece> generateDiagForSwitchOP(
|
|
|
|
const ExplodedNode *N,
|
|
|
|
const CFGBlock *Dst,
|
|
|
|
const SourceManager &SM,
|
|
|
|
const LocationContext *LC,
|
|
|
|
PathDiagnosticBuilder &PDB,
|
|
|
|
PathDiagnosticLocation &Start
|
|
|
|
) {
|
|
|
|
// Figure out what case arm we took.
|
|
|
|
std::string sbuf;
|
|
|
|
llvm::raw_string_ostream os(sbuf);
|
|
|
|
PathDiagnosticLocation End;
|
2012-03-16 05:13:02 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
if (const Stmt *S = Dst->getLabel()) {
|
|
|
|
End = PathDiagnosticLocation(S, SM, LC);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
switch (S->getStmtClass()) {
|
|
|
|
default:
|
|
|
|
os << "No cases match in the switch statement. "
|
|
|
|
"Control jumps to line "
|
|
|
|
<< End.asLocation().getExpansionLineNumber();
|
|
|
|
break;
|
|
|
|
case Stmt::DefaultStmtClass:
|
|
|
|
os << "Control jumps to the 'default' case at line "
|
|
|
|
<< End.asLocation().getExpansionLineNumber();
|
2018-02-08 03:56:52 +08:00
|
|
|
break;
|
2012-07-27 04:04:05 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
case Stmt::CaseStmtClass: {
|
|
|
|
os << "Control jumps to 'case ";
|
|
|
|
const auto *Case = cast<CaseStmt>(S);
|
|
|
|
const Expr *LHS = Case->getLHS()->IgnoreParenCasts();
|
2012-08-30 05:22:37 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
// Determine if it is an enum.
|
|
|
|
bool GetRawInt = true;
|
|
|
|
|
|
|
|
if (const auto *DR = dyn_cast<DeclRefExpr>(LHS)) {
|
|
|
|
// FIXME: Maybe this should be an assertion. Are there cases
|
|
|
|
// were it is not an EnumConstantDecl?
|
|
|
|
const auto *D = dyn_cast<EnumConstantDecl>(DR->getDecl());
|
|
|
|
|
|
|
|
if (D) {
|
|
|
|
GetRawInt = false;
|
|
|
|
os << *D;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (GetRawInt)
|
|
|
|
os << LHS->EvaluateKnownConstInt(PDB.getASTContext());
|
|
|
|
|
|
|
|
os << ":' at line " << End.asLocation().getExpansionLineNumber();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
os << "'Default' branch taken. ";
|
|
|
|
End = PDB.ExecutionContinues(os, N);
|
2018-02-08 03:56:52 +08:00
|
|
|
}
|
2018-06-13 03:08:00 +08:00
|
|
|
return std::make_shared<PathDiagnosticControlFlowPiece>(Start, End,
|
|
|
|
os.str());
|
|
|
|
}
|
2018-02-08 03:56:52 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
|
|
|
|
std::shared_ptr<PathDiagnosticControlFlowPiece> generateDiagForGotoOP(
|
|
|
|
const Stmt *S,
|
|
|
|
PathDiagnosticBuilder &PDB,
|
|
|
|
PathDiagnosticLocation &Start) {
|
2018-02-08 03:56:52 +08:00
|
|
|
std::string sbuf;
|
|
|
|
llvm::raw_string_ostream os(sbuf);
|
2018-06-13 03:08:00 +08:00
|
|
|
const PathDiagnosticLocation &End = PDB.getEnclosingStmtLocation(S);
|
|
|
|
os << "Control jumps to line " << End.asLocation().getExpansionLineNumber();
|
|
|
|
return std::make_shared<PathDiagnosticControlFlowPiece>(Start, End, os.str());
|
2018-02-08 03:56:52 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
}
|
2018-02-08 03:56:52 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
std::shared_ptr<PathDiagnosticControlFlowPiece> generateDiagForBinaryOP(
|
|
|
|
const ExplodedNode *N,
|
|
|
|
const Stmt *T,
|
|
|
|
const CFGBlock *Src,
|
|
|
|
const CFGBlock *Dst,
|
|
|
|
const SourceManager &SM,
|
|
|
|
PathDiagnosticBuilder &PDB,
|
|
|
|
const LocationContext *LC) {
|
|
|
|
const auto *B = cast<BinaryOperator>(T);
|
|
|
|
std::string sbuf;
|
|
|
|
llvm::raw_string_ostream os(sbuf);
|
|
|
|
os << "Left side of '";
|
|
|
|
PathDiagnosticLocation Start, End;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
if (B->getOpcode() == BO_LAnd) {
|
|
|
|
os << "&&"
|
|
|
|
<< "' is ";
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
if (*(Src->succ_begin() + 1) == Dst) {
|
|
|
|
os << "false";
|
|
|
|
End = PathDiagnosticLocation(B->getLHS(), SM, LC);
|
|
|
|
Start =
|
|
|
|
PathDiagnosticLocation::createOperatorLoc(B, SM);
|
|
|
|
} else {
|
|
|
|
os << "true";
|
|
|
|
Start = PathDiagnosticLocation(B->getLHS(), SM, LC);
|
|
|
|
End = PDB.ExecutionContinues(N);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
assert(B->getOpcode() == BO_LOr);
|
|
|
|
os << "||"
|
|
|
|
<< "' is ";
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
if (*(Src->succ_begin() + 1) == Dst) {
|
|
|
|
os << "false";
|
|
|
|
Start = PathDiagnosticLocation(B->getLHS(), SM, LC);
|
|
|
|
End = PDB.ExecutionContinues(N);
|
|
|
|
} else {
|
|
|
|
os << "true";
|
|
|
|
End = PathDiagnosticLocation(B->getLHS(), SM, LC);
|
|
|
|
Start =
|
|
|
|
PathDiagnosticLocation::createOperatorLoc(B, SM);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return std::make_shared<PathDiagnosticControlFlowPiece>(Start, End,
|
|
|
|
os.str());
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
void generateMinimalDiagForBlockEdge(const ExplodedNode *N, BlockEdge BE,
|
|
|
|
const SourceManager &SM,
|
|
|
|
PathDiagnosticBuilder &PDB,
|
|
|
|
PathDiagnostic &PD) {
|
|
|
|
const LocationContext *LC = N->getLocationContext();
|
|
|
|
const CFGBlock *Src = BE.getSrc();
|
|
|
|
const CFGBlock *Dst = BE.getDst();
|
2019-05-24 09:34:22 +08:00
|
|
|
const Stmt *T = Src->getTerminatorStmt();
|
2018-06-13 03:08:00 +08:00
|
|
|
if (!T)
|
|
|
|
return;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
auto Start = PathDiagnosticLocation::createBegin(T, SM, LC);
|
|
|
|
switch (T->getStmtClass()) {
|
|
|
|
default:
|
|
|
|
break;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
case Stmt::GotoStmtClass:
|
|
|
|
case Stmt::IndirectGotoStmtClass: {
|
|
|
|
if (const Stmt *S = PathDiagnosticLocation::getNextStmt(N))
|
|
|
|
PD.getActivePath().push_front(generateDiagForGotoOP(S, PDB, Start));
|
|
|
|
break;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
case Stmt::SwitchStmtClass: {
|
|
|
|
PD.getActivePath().push_front(
|
|
|
|
generateDiagForSwitchOP(N, Dst, SM, LC, PDB, Start));
|
2018-02-08 03:56:52 +08:00
|
|
|
break;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
case Stmt::BreakStmtClass:
|
|
|
|
case Stmt::ContinueStmtClass: {
|
|
|
|
std::string sbuf;
|
|
|
|
llvm::raw_string_ostream os(sbuf);
|
|
|
|
PathDiagnosticLocation End = PDB.ExecutionContinues(os, N);
|
|
|
|
PD.getActivePath().push_front(
|
|
|
|
std::make_shared<PathDiagnosticControlFlowPiece>(Start, End, os.str()));
|
|
|
|
break;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
// Determine control-flow for ternary '?'.
|
|
|
|
case Stmt::BinaryConditionalOperatorClass:
|
|
|
|
case Stmt::ConditionalOperatorClass: {
|
|
|
|
std::string sbuf;
|
|
|
|
llvm::raw_string_ostream os(sbuf);
|
|
|
|
os << "'?' condition is ";
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
if (*(Src->succ_begin() + 1) == Dst)
|
|
|
|
os << "false";
|
|
|
|
else
|
|
|
|
os << "true";
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
PathDiagnosticLocation End = PDB.ExecutionContinues(N);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
if (const Stmt *S = End.asStmt())
|
|
|
|
End = PDB.getEnclosingStmtLocation(S);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
PD.getActivePath().push_front(
|
|
|
|
std::make_shared<PathDiagnosticControlFlowPiece>(Start, End, os.str()));
|
|
|
|
break;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
// Determine control-flow for short-circuited '&&' and '||'.
|
|
|
|
case Stmt::BinaryOperatorClass: {
|
|
|
|
if (!PDB.supportsLogicalOpControlFlow())
|
|
|
|
break;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
std::shared_ptr<PathDiagnosticControlFlowPiece> Diag =
|
|
|
|
generateDiagForBinaryOP(N, T, Src, Dst, SM, PDB, LC);
|
|
|
|
PD.getActivePath().push_front(Diag);
|
2018-02-08 03:56:52 +08:00
|
|
|
break;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
case Stmt::DoStmtClass:
|
2018-02-08 03:56:52 +08:00
|
|
|
if (*(Src->succ_begin()) == Dst) {
|
|
|
|
std::string sbuf;
|
|
|
|
llvm::raw_string_ostream os(sbuf);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
os << "Loop condition is true. ";
|
|
|
|
PathDiagnosticLocation End = PDB.ExecutionContinues(os, N);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
if (const Stmt *S = End.asStmt())
|
|
|
|
End = PDB.getEnclosingStmtLocation(S);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
PD.getActivePath().push_front(
|
|
|
|
std::make_shared<PathDiagnosticControlFlowPiece>(Start, End,
|
|
|
|
os.str()));
|
|
|
|
} else {
|
|
|
|
PathDiagnosticLocation End = PDB.ExecutionContinues(N);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
if (const Stmt *S = End.asStmt())
|
|
|
|
End = PDB.getEnclosingStmtLocation(S);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
PD.getActivePath().push_front(
|
|
|
|
std::make_shared<PathDiagnosticControlFlowPiece>(
|
|
|
|
Start, End, "Loop condition is false. Exiting loop"));
|
|
|
|
}
|
|
|
|
break;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
case Stmt::WhileStmtClass:
|
2018-03-07 08:17:48 +08:00
|
|
|
case Stmt::ForStmtClass:
|
2018-02-08 03:56:52 +08:00
|
|
|
if (*(Src->succ_begin() + 1) == Dst) {
|
|
|
|
std::string sbuf;
|
|
|
|
llvm::raw_string_ostream os(sbuf);
|
|
|
|
|
|
|
|
os << "Loop condition is false. ";
|
|
|
|
PathDiagnosticLocation End = PDB.ExecutionContinues(os, N);
|
|
|
|
if (const Stmt *S = End.asStmt())
|
|
|
|
End = PDB.getEnclosingStmtLocation(S);
|
|
|
|
|
|
|
|
PD.getActivePath().push_front(
|
|
|
|
std::make_shared<PathDiagnosticControlFlowPiece>(Start, End,
|
|
|
|
os.str()));
|
|
|
|
} else {
|
|
|
|
PathDiagnosticLocation End = PDB.ExecutionContinues(N);
|
|
|
|
if (const Stmt *S = End.asStmt())
|
|
|
|
End = PDB.getEnclosingStmtLocation(S);
|
|
|
|
|
|
|
|
PD.getActivePath().push_front(
|
|
|
|
std::make_shared<PathDiagnosticControlFlowPiece>(
|
|
|
|
Start, End, "Loop condition is true. Entering loop body"));
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
break;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
case Stmt::IfStmtClass: {
|
|
|
|
PathDiagnosticLocation End = PDB.ExecutionContinues(N);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
if (const Stmt *S = End.asStmt())
|
|
|
|
End = PDB.getEnclosingStmtLocation(S);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
if (*(Src->succ_begin() + 1) == Dst)
|
|
|
|
PD.getActivePath().push_front(
|
|
|
|
std::make_shared<PathDiagnosticControlFlowPiece>(
|
|
|
|
Start, End, "Taking false branch"));
|
|
|
|
else
|
|
|
|
PD.getActivePath().push_front(
|
|
|
|
std::make_shared<PathDiagnosticControlFlowPiece>(
|
|
|
|
Start, End, "Taking true branch"));
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2012-05-02 08:31:29 +08:00
|
|
|
// Cone-of-influence: support the reverse propagation of "interesting" symbols
|
|
|
|
// and values by tracing interesting calculations backwards through evaluated
|
|
|
|
// expressions along a path. This is probably overly complicated, but the idea
|
|
|
|
// is that if an expression computed an "interesting" value, the child
|
Misc typos fixes in ./lib folder
Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned`
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D55475
llvm-svn: 348755
2018-12-10 20:37:46 +08:00
|
|
|
// expressions are also likely to be "interesting" as well (which then
|
2012-05-02 08:31:29 +08:00
|
|
|
// propagates to the values they in turn compute). This reverse propagation
|
|
|
|
// is needed to track interesting correlations across function call boundaries,
|
|
|
|
// where formal arguments bind to actual arguments, etc. This is also needed
|
|
|
|
// because the constraint solver sometimes simplifies certain symbolic values
|
|
|
|
// into constants when appropriate, and this complicates reasoning about
|
|
|
|
// interesting values.
|
2018-03-07 08:17:48 +08:00
|
|
|
using InterestingExprs = llvm::DenseSet<const Expr *>;
|
2012-05-02 08:31:29 +08:00
|
|
|
|
|
|
|
static void reversePropagateIntererstingSymbols(BugReport &R,
|
|
|
|
InterestingExprs &IE,
|
|
|
|
const ProgramState *State,
|
|
|
|
const Expr *Ex,
|
|
|
|
const LocationContext *LCtx) {
|
|
|
|
SVal V = State->getSVal(Ex, LCtx);
|
|
|
|
if (!(R.isInteresting(V) || IE.count(Ex)))
|
|
|
|
return;
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-05-02 08:31:29 +08:00
|
|
|
switch (Ex->getStmtClass()) {
|
|
|
|
default:
|
|
|
|
if (!isa<CastExpr>(Ex))
|
|
|
|
break;
|
Fix clang -Wimplicit-fallthrough warnings across llvm, NFC
This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
2018-11-02 03:54:45 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
2012-05-02 08:31:29 +08:00
|
|
|
case Stmt::BinaryOperatorClass:
|
|
|
|
case Stmt::UnaryOperatorClass: {
|
2015-07-03 23:12:24 +08:00
|
|
|
for (const Stmt *SubStmt : Ex->children()) {
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *child = dyn_cast_or_null<Expr>(SubStmt)) {
|
2012-05-02 08:31:29 +08:00
|
|
|
IE.insert(child);
|
|
|
|
SVal ChildV = State->getSVal(child, LCtx);
|
|
|
|
R.markInteresting(ChildV);
|
|
|
|
}
|
|
|
|
}
|
2014-03-21 02:47:47 +08:00
|
|
|
break;
|
2012-05-02 08:31:29 +08:00
|
|
|
}
|
|
|
|
}
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-05-02 08:31:29 +08:00
|
|
|
R.markInteresting(V);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void reversePropagateInterestingSymbols(BugReport &R,
|
|
|
|
InterestingExprs &IE,
|
|
|
|
const ProgramState *State,
|
2018-09-29 02:49:41 +08:00
|
|
|
const LocationContext *CalleeCtx)
|
2012-05-02 08:31:29 +08:00
|
|
|
{
|
2012-07-11 06:07:52 +08:00
|
|
|
// FIXME: Handle non-CallExpr-based CallEvents.
|
2018-06-27 09:51:55 +08:00
|
|
|
const StackFrameContext *Callee = CalleeCtx->getStackFrame();
|
2012-05-02 08:31:29 +08:00
|
|
|
const Stmt *CallSite = Callee->getCallSite();
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *CE = dyn_cast_or_null<CallExpr>(CallSite)) {
|
|
|
|
if (const auto *FD = dyn_cast<FunctionDecl>(CalleeCtx->getDecl())) {
|
2015-09-08 11:50:52 +08:00
|
|
|
FunctionDecl::param_const_iterator PI = FD->param_begin(),
|
2012-05-02 08:31:29 +08:00
|
|
|
PE = FD->param_end();
|
|
|
|
CallExpr::const_arg_iterator AI = CE->arg_begin(), AE = CE->arg_end();
|
|
|
|
for (; AI != AE && PI != PE; ++AI, ++PI) {
|
|
|
|
if (const Expr *ArgE = *AI) {
|
|
|
|
if (const ParmVarDecl *PD = *PI) {
|
|
|
|
Loc LV = State->getLValue(PD, CalleeCtx);
|
|
|
|
if (R.isInteresting(LV) || R.isInteresting(State->getRawSVal(LV)))
|
|
|
|
IE.insert(ArgE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2013-02-09 03:51:43 +08:00
|
|
|
|
2013-02-22 13:45:33 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Functions for determining if a loop was executed 0 times.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2013-05-07 09:18:10 +08:00
|
|
|
static bool isLoop(const Stmt *Term) {
|
2013-02-09 03:51:43 +08:00
|
|
|
switch (Term->getStmtClass()) {
|
|
|
|
case Stmt::ForStmtClass:
|
|
|
|
case Stmt::WhileStmtClass:
|
2013-03-14 04:03:31 +08:00
|
|
|
case Stmt::ObjCForCollectionStmtClass:
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
case Stmt::CXXForRangeStmtClass:
|
2013-05-07 09:18:10 +08:00
|
|
|
return true;
|
2013-02-09 03:51:43 +08:00
|
|
|
default:
|
|
|
|
// Note that we intentionally do not include do..while here.
|
|
|
|
return false;
|
|
|
|
}
|
2013-05-07 09:18:10 +08:00
|
|
|
}
|
2013-02-09 03:51:43 +08:00
|
|
|
|
2013-05-07 09:18:10 +08:00
|
|
|
static bool isJumpToFalseBranch(const BlockEdge *BE) {
|
2013-02-09 03:51:43 +08:00
|
|
|
const CFGBlock *Src = BE->getSrc();
|
|
|
|
assert(Src->succ_size() == 2);
|
|
|
|
return (*(Src->succ_begin()+1) == BE->getDst());
|
|
|
|
}
|
|
|
|
|
2013-02-22 13:45:33 +08:00
|
|
|
static bool isContainedByStmt(ParentMap &PM, const Stmt *S, const Stmt *SubS) {
|
|
|
|
while (SubS) {
|
|
|
|
if (SubS == S)
|
|
|
|
return true;
|
|
|
|
SubS = PM.getParent(SubS);
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const Stmt *getStmtBeforeCond(ParentMap &PM, const Stmt *Term,
|
|
|
|
const ExplodedNode *N) {
|
|
|
|
while (N) {
|
|
|
|
Optional<StmtPoint> SP = N->getLocation().getAs<StmtPoint>();
|
|
|
|
if (SP) {
|
|
|
|
const Stmt *S = SP->getStmt();
|
|
|
|
if (!isContainedByStmt(PM, Term, S))
|
|
|
|
return S;
|
|
|
|
}
|
2013-04-24 07:57:43 +08:00
|
|
|
N = N->getFirstPred();
|
2013-02-22 13:45:33 +08:00
|
|
|
}
|
2014-05-27 10:45:47 +08:00
|
|
|
return nullptr;
|
2013-02-22 13:45:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool isInLoopBody(ParentMap &PM, const Stmt *S, const Stmt *Term) {
|
2014-05-27 10:45:47 +08:00
|
|
|
const Stmt *LoopBody = nullptr;
|
2013-02-22 13:45:33 +08:00
|
|
|
switch (Term->getStmtClass()) {
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
case Stmt::CXXForRangeStmtClass: {
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *FR = cast<CXXForRangeStmt>(Term);
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
if (isContainedByStmt(PM, FR->getInc(), S))
|
|
|
|
return true;
|
|
|
|
if (isContainedByStmt(PM, FR->getLoopVarStmt(), S))
|
|
|
|
return true;
|
|
|
|
LoopBody = FR->getBody();
|
|
|
|
break;
|
|
|
|
}
|
2013-02-22 13:45:33 +08:00
|
|
|
case Stmt::ForStmtClass: {
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *FS = cast<ForStmt>(Term);
|
2013-02-22 13:45:33 +08:00
|
|
|
if (isContainedByStmt(PM, FS->getInc(), S))
|
|
|
|
return true;
|
|
|
|
LoopBody = FS->getBody();
|
|
|
|
break;
|
|
|
|
}
|
2013-03-14 04:03:31 +08:00
|
|
|
case Stmt::ObjCForCollectionStmtClass: {
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *FC = cast<ObjCForCollectionStmt>(Term);
|
2013-03-14 04:03:31 +08:00
|
|
|
LoopBody = FC->getBody();
|
|
|
|
break;
|
|
|
|
}
|
2013-02-22 13:45:33 +08:00
|
|
|
case Stmt::WhileStmtClass:
|
|
|
|
LoopBody = cast<WhileStmt>(Term)->getBody();
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return isContainedByStmt(PM, LoopBody, S);
|
|
|
|
}
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Adds a sanitized control-flow diagnostic edge to a path.
|
2013-05-04 02:25:33 +08:00
|
|
|
static void addEdgeToPath(PathPieces &path,
|
|
|
|
PathDiagnosticLocation &PrevLoc,
|
2018-09-29 02:49:41 +08:00
|
|
|
PathDiagnosticLocation NewLoc) {
|
2013-05-04 09:13:01 +08:00
|
|
|
if (!NewLoc.isValid())
|
2013-05-04 02:25:33 +08:00
|
|
|
return;
|
|
|
|
|
2013-05-04 09:13:01 +08:00
|
|
|
SourceLocation NewLocL = NewLoc.asLocation();
|
2013-06-08 08:29:24 +08:00
|
|
|
if (NewLocL.isInvalid())
|
2013-05-04 02:25:33 +08:00
|
|
|
return;
|
|
|
|
|
2013-05-31 05:30:17 +08:00
|
|
|
if (!PrevLoc.isValid() || !PrevLoc.asLocation().isValid()) {
|
2013-05-04 02:25:33 +08:00
|
|
|
PrevLoc = NewLoc;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-06-06 08:12:37 +08:00
|
|
|
// Ignore self-edges, which occur when there are multiple nodes at the same
|
|
|
|
// statement.
|
|
|
|
if (NewLoc.asStmt() && NewLoc.asStmt() == PrevLoc.asStmt())
|
2013-05-04 02:25:33 +08:00
|
|
|
return;
|
|
|
|
|
2017-01-06 01:26:53 +08:00
|
|
|
path.push_front(
|
|
|
|
std::make_shared<PathDiagnosticControlFlowPiece>(NewLoc, PrevLoc));
|
2013-05-04 02:25:33 +08:00
|
|
|
PrevLoc = NewLoc;
|
|
|
|
}
|
|
|
|
|
2013-05-21 08:34:40 +08:00
|
|
|
/// A customized wrapper for CFGBlock::getTerminatorCondition()
|
|
|
|
/// which returns the element for ObjCForCollectionStmts.
|
|
|
|
static const Stmt *getTerminatorCondition(const CFGBlock *B) {
|
|
|
|
const Stmt *S = B->getTerminatorCondition();
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *FS = dyn_cast_or_null<ObjCForCollectionStmt>(S))
|
2013-05-21 08:34:40 +08:00
|
|
|
return FS->getElement();
|
|
|
|
return S;
|
|
|
|
}
|
|
|
|
|
2013-07-17 02:27:27 +08:00
|
|
|
static const char StrEnteringLoop[] = "Entering loop body";
|
|
|
|
static const char StrLoopBodyZero[] = "Loop body executed 0 times";
|
2013-11-08 09:15:30 +08:00
|
|
|
static const char StrLoopRangeEmpty[] =
|
|
|
|
"Loop body skipped when range is empty";
|
|
|
|
static const char StrLoopCollectionEmpty[] =
|
|
|
|
"Loop body skipped when collection is empty";
|
2013-06-01 00:56:54 +08:00
|
|
|
|
[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
|
|
|
static std::unique_ptr<FilesToLineNumsMap>
|
|
|
|
findExecutedLines(SourceManager &SM, const ExplodedNode *N);
|
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
/// Generate diagnostics for the node \p N,
|
2018-02-08 03:56:52 +08:00
|
|
|
/// and write it into \p PD.
|
2018-06-13 03:08:00 +08:00
|
|
|
/// \p AddPathEdges Whether diagnostic consumer can generate path arrows
|
|
|
|
/// showing both row and column.
|
|
|
|
static void generatePathDiagnosticsForNode(const ExplodedNode *N,
|
2018-02-08 03:56:52 +08:00
|
|
|
PathDiagnostic &PD,
|
|
|
|
PathDiagnosticLocation &PrevLoc,
|
|
|
|
PathDiagnosticBuilder &PDB,
|
|
|
|
LocationContextMap &LCM,
|
|
|
|
StackDiagVector &CallStack,
|
2018-06-13 03:08:00 +08:00
|
|
|
InterestingExprs &IE,
|
|
|
|
bool AddPathEdges) {
|
2018-02-08 03:56:52 +08:00
|
|
|
ProgramPoint P = N->getLocation();
|
2013-05-04 02:25:33 +08:00
|
|
|
const SourceManager& SM = PDB.getSourceManager();
|
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
// Have we encountered an entrance to a call? It may be
|
|
|
|
// the case that we have not encountered a matching
|
|
|
|
// call exit before this point. This means that the path
|
|
|
|
// terminated within the call itself.
|
2018-06-13 03:08:00 +08:00
|
|
|
if (auto CE = P.getAs<CallEnter>()) {
|
|
|
|
|
|
|
|
if (AddPathEdges) {
|
|
|
|
// Add an edge to the start of the function.
|
|
|
|
const StackFrameContext *CalleeLC = CE->getCalleeContext();
|
|
|
|
const Decl *D = CalleeLC->getDecl();
|
|
|
|
// Add the edge only when the callee has body. We jump to the beginning
|
|
|
|
// of the *declaration*, however we expect it to be followed by the
|
|
|
|
// body. This isn't the case for autosynthesized property accessors in
|
|
|
|
// Objective-C. No need for a similar extra check for CallExit points
|
|
|
|
// because the exit edge comes from a statement (i.e. return),
|
|
|
|
// not from declaration.
|
|
|
|
if (D->hasBody())
|
|
|
|
addEdgeToPath(PD.getActivePath(), PrevLoc,
|
2018-09-29 02:49:41 +08:00
|
|
|
PathDiagnosticLocation::createBegin(D, SM));
|
2018-06-13 03:08:00 +08:00
|
|
|
}
|
2018-02-08 03:56:52 +08:00
|
|
|
|
|
|
|
// Did we visit an entire call?
|
|
|
|
bool VisitedEntireCall = PD.isWithinCall();
|
|
|
|
PD.popActivePath();
|
|
|
|
|
|
|
|
PathDiagnosticCallPiece *C;
|
|
|
|
if (VisitedEntireCall) {
|
2018-06-13 03:08:00 +08:00
|
|
|
C = cast<PathDiagnosticCallPiece>(PD.getActivePath().front().get());
|
2018-02-08 03:56:52 +08:00
|
|
|
} else {
|
|
|
|
const Decl *Caller = CE->getLocationContext()->getDecl();
|
|
|
|
C = PathDiagnosticCallPiece::construct(PD.getActivePath(), Caller);
|
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
if (AddPathEdges) {
|
|
|
|
// Since we just transferred the path over to the call piece,
|
|
|
|
// reset the mapping from active to location context.
|
|
|
|
assert(PD.getActivePath().size() == 1 &&
|
|
|
|
PD.getActivePath().front().get() == C);
|
|
|
|
LCM[&PD.getActivePath()] = nullptr;
|
|
|
|
}
|
2018-02-08 03:56:52 +08:00
|
|
|
|
|
|
|
// Record the location context mapping for the path within
|
|
|
|
// the call.
|
|
|
|
assert(LCM[&C->path] == nullptr ||
|
|
|
|
LCM[&C->path] == CE->getCalleeContext());
|
|
|
|
LCM[&C->path] = CE->getCalleeContext();
|
|
|
|
|
|
|
|
// If this is the first item in the active path, record
|
|
|
|
// the new mapping from active path to location context.
|
|
|
|
const LocationContext *&NewLC = LCM[&PD.getActivePath()];
|
|
|
|
if (!NewLC)
|
|
|
|
NewLC = N->getLocationContext();
|
|
|
|
|
|
|
|
PDB.LC = NewLC;
|
|
|
|
}
|
|
|
|
C->setCallee(*CE, SM);
|
2013-05-31 05:30:17 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
// Update the previous location in the active path.
|
|
|
|
PrevLoc = C->getLocation();
|
2013-05-08 05:12:06 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
if (!CallStack.empty()) {
|
|
|
|
assert(CallStack.back().first == C);
|
|
|
|
CallStack.pop_back();
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
2013-05-08 05:12:06 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
if (AddPathEdges) {
|
|
|
|
// Query the location context here and the previous location
|
|
|
|
// as processing CallEnter may change the active path.
|
|
|
|
PDB.LC = N->getLocationContext();
|
|
|
|
|
|
|
|
// Record the mapping from the active path to the location
|
|
|
|
// context.
|
|
|
|
assert(!LCM[&PD.getActivePath()] || LCM[&PD.getActivePath()] == PDB.LC);
|
|
|
|
LCM[&PD.getActivePath()] = PDB.LC;
|
|
|
|
}
|
2018-02-08 03:56:52 +08:00
|
|
|
|
|
|
|
// Have we encountered an exit from a function call?
|
|
|
|
if (Optional<CallExitEnd> CE = P.getAs<CallExitEnd>()) {
|
2013-05-25 05:43:05 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
// We are descending into a call (backwards). Construct
|
|
|
|
// a new call piece to contain the path pieces for that call.
|
2018-09-29 02:49:41 +08:00
|
|
|
auto C = PathDiagnosticCallPiece::construct(*CE, SM);
|
2018-06-13 03:08:00 +08:00
|
|
|
// Record the mapping from call piece to LocationContext.
|
2018-02-08 03:56:52 +08:00
|
|
|
LCM[&C->path] = CE->getCalleeContext();
|
|
|
|
|
2018-06-13 03:08:00 +08:00
|
|
|
if (AddPathEdges) {
|
|
|
|
const Stmt *S = CE->getCalleeContext()->getCallSite();
|
|
|
|
// Propagate the interesting symbols accordingly.
|
|
|
|
if (const auto *Ex = dyn_cast_or_null<Expr>(S)) {
|
|
|
|
reversePropagateIntererstingSymbols(*PDB.getBugReport(), IE,
|
|
|
|
N->getState().get(), Ex,
|
|
|
|
N->getLocationContext());
|
|
|
|
}
|
|
|
|
// Add the edge to the return site.
|
2018-09-29 02:49:41 +08:00
|
|
|
addEdgeToPath(PD.getActivePath(), PrevLoc, C->callReturn);
|
2018-06-13 03:08:00 +08:00
|
|
|
PrevLoc.invalidate();
|
|
|
|
}
|
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
auto *P = C.get();
|
|
|
|
PD.getActivePath().push_front(std::move(C));
|
|
|
|
|
|
|
|
// Make the contents of the call the active path for now.
|
|
|
|
PD.pushActivePath(&P->path);
|
|
|
|
CallStack.push_back(StackDiagPair(P, N));
|
2018-06-13 03:08:00 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (auto PS = P.getAs<PostStmt>()) {
|
|
|
|
if (!AddPathEdges)
|
|
|
|
return;
|
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
// For expressions, make sure we propagate the
|
|
|
|
// interesting symbols correctly.
|
|
|
|
if (const Expr *Ex = PS->getStmtAs<Expr>())
|
|
|
|
reversePropagateIntererstingSymbols(*PDB.getBugReport(), IE,
|
|
|
|
N->getState().get(), Ex,
|
|
|
|
N->getLocationContext());
|
|
|
|
|
|
|
|
// Add an edge. If this is an ObjCForCollectionStmt do
|
|
|
|
// not add an edge here as it appears in the CFG both
|
|
|
|
// as a terminator and as a terminator condition.
|
|
|
|
if (!isa<ObjCForCollectionStmt>(PS->getStmt())) {
|
|
|
|
PathDiagnosticLocation L =
|
|
|
|
PathDiagnosticLocation(PS->getStmt(), SM, PDB.LC);
|
2018-09-29 02:49:41 +08:00
|
|
|
addEdgeToPath(PD.getActivePath(), PrevLoc, L);
|
2018-02-08 03:56:52 +08:00
|
|
|
}
|
2018-06-13 03:08:00 +08:00
|
|
|
|
|
|
|
} else if (auto BE = P.getAs<BlockEdge>()) {
|
|
|
|
|
|
|
|
if (!AddPathEdges) {
|
|
|
|
generateMinimalDiagForBlockEdge(N, *BE, SM, PDB, PD);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
// Does this represent entering a call? If so, look at propagating
|
|
|
|
// interesting symbols across call boundaries.
|
2018-06-13 03:08:00 +08:00
|
|
|
if (const ExplodedNode *NextNode = N->getFirstPred()) {
|
2018-02-08 03:56:52 +08:00
|
|
|
const LocationContext *CallerCtx = NextNode->getLocationContext();
|
|
|
|
const LocationContext *CalleeCtx = PDB.LC;
|
2018-06-13 03:08:00 +08:00
|
|
|
if (CallerCtx != CalleeCtx && AddPathEdges) {
|
2018-02-08 03:56:52 +08:00
|
|
|
reversePropagateInterestingSymbols(*PDB.getBugReport(), IE,
|
2018-09-29 02:49:41 +08:00
|
|
|
N->getState().get(), CalleeCtx);
|
2013-05-04 02:25:33 +08:00
|
|
|
}
|
2018-02-08 03:56:52 +08:00
|
|
|
}
|
2013-05-04 02:25:33 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
// Are we jumping to the head of a loop? Add a special diagnostic.
|
|
|
|
if (const Stmt *Loop = BE->getSrc()->getLoopTarget()) {
|
|
|
|
PathDiagnosticLocation L(Loop, SM, PDB.LC);
|
|
|
|
const Stmt *Body = nullptr;
|
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *FS = dyn_cast<ForStmt>(Loop))
|
2018-02-08 03:56:52 +08:00
|
|
|
Body = FS->getBody();
|
2018-03-07 08:17:48 +08:00
|
|
|
else if (const auto *WS = dyn_cast<WhileStmt>(Loop))
|
2018-02-08 03:56:52 +08:00
|
|
|
Body = WS->getBody();
|
2018-03-07 08:17:48 +08:00
|
|
|
else if (const auto *OFS = dyn_cast<ObjCForCollectionStmt>(Loop)) {
|
2018-02-08 03:56:52 +08:00
|
|
|
Body = OFS->getBody();
|
2018-03-07 08:17:48 +08:00
|
|
|
} else if (const auto *FRS = dyn_cast<CXXForRangeStmt>(Loop)) {
|
2018-02-08 03:56:52 +08:00
|
|
|
Body = FRS->getBody();
|
|
|
|
}
|
|
|
|
// do-while statements are explicitly excluded here
|
2013-05-04 02:25:33 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
auto p = std::make_shared<PathDiagnosticEventPiece>(
|
|
|
|
L, "Looping back to the head "
|
|
|
|
"of the loop");
|
|
|
|
p->setPrunable(true);
|
2013-05-04 02:25:33 +08:00
|
|
|
|
2018-09-29 02:49:41 +08:00
|
|
|
addEdgeToPath(PD.getActivePath(), PrevLoc, p->getLocation());
|
2018-02-08 03:56:52 +08:00
|
|
|
PD.getActivePath().push_front(std::move(p));
|
2013-05-04 02:25:33 +08:00
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *CS = dyn_cast_or_null<CompoundStmt>(Body)) {
|
2018-02-08 03:56:52 +08:00
|
|
|
addEdgeToPath(PD.getActivePath(), PrevLoc,
|
2018-09-29 02:49:41 +08:00
|
|
|
PathDiagnosticLocation::createEndBrace(CS, SM));
|
2013-05-04 02:25:33 +08:00
|
|
|
}
|
2018-02-08 03:56:52 +08:00
|
|
|
}
|
2013-05-04 02:25:33 +08:00
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
const CFGBlock *BSrc = BE->getSrc();
|
|
|
|
ParentMap &PM = PDB.getParentMap();
|
|
|
|
|
2019-05-24 09:34:22 +08:00
|
|
|
if (const Stmt *Term = BSrc->getTerminatorStmt()) {
|
2018-02-08 03:56:52 +08:00
|
|
|
// Are we jumping past the loop body without ever executing the
|
|
|
|
// loop (because the condition was false)?
|
|
|
|
if (isLoop(Term)) {
|
|
|
|
const Stmt *TermCond = getTerminatorCondition(BSrc);
|
|
|
|
bool IsInLoopBody =
|
|
|
|
isInLoopBody(PM, getStmtBeforeCond(PM, TermCond, N), Term);
|
|
|
|
|
|
|
|
const char *str = nullptr;
|
|
|
|
|
|
|
|
if (isJumpToFalseBranch(&*BE)) {
|
|
|
|
if (!IsInLoopBody) {
|
|
|
|
if (isa<ObjCForCollectionStmt>(Term)) {
|
|
|
|
str = StrLoopCollectionEmpty;
|
|
|
|
} else if (isa<CXXForRangeStmt>(Term)) {
|
|
|
|
str = StrLoopRangeEmpty;
|
|
|
|
} else {
|
|
|
|
str = StrLoopBodyZero;
|
|
|
|
}
|
2013-05-04 02:25:33 +08:00
|
|
|
}
|
2018-02-08 03:56:52 +08:00
|
|
|
} else {
|
|
|
|
str = StrEnteringLoop;
|
2013-05-04 02:25:33 +08:00
|
|
|
}
|
|
|
|
|
2018-02-08 03:56:52 +08:00
|
|
|
if (str) {
|
|
|
|
PathDiagnosticLocation L(TermCond ? TermCond : Term, SM, PDB.LC);
|
|
|
|
auto PE = std::make_shared<PathDiagnosticEventPiece>(L, str);
|
|
|
|
PE->setPrunable(true);
|
|
|
|
addEdgeToPath(PD.getActivePath(), PrevLoc,
|
2018-09-29 02:49:41 +08:00
|
|
|
PE->getLocation());
|
2018-02-08 03:56:52 +08:00
|
|
|
PD.getActivePath().push_front(std::move(PE));
|
|
|
|
}
|
|
|
|
} else if (isa<BreakStmt>(Term) || isa<ContinueStmt>(Term) ||
|
|
|
|
isa<GotoStmt>(Term)) {
|
|
|
|
PathDiagnosticLocation L(Term, SM, PDB.LC);
|
2018-09-29 02:49:41 +08:00
|
|
|
addEdgeToPath(PD.getActivePath(), PrevLoc, L);
|
2018-02-08 03:56:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2013-05-04 02:25:33 +08:00
|
|
|
|
[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
|
|
|
static std::unique_ptr<PathDiagnostic>
|
|
|
|
generateEmptyDiagnosticForReport(BugReport *R, SourceManager &SM) {
|
2019-01-19 03:24:55 +08:00
|
|
|
const BugType &BT = R->getBugType();
|
[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
|
|
|
return llvm::make_unique<PathDiagnostic>(
|
|
|
|
R->getBugType().getCheckName(), R->getDeclWithIssue(),
|
|
|
|
R->getBugType().getName(), R->getDescription(),
|
|
|
|
R->getShortDescription(/*Fallback=*/false), BT.getCategory(),
|
|
|
|
R->getUniqueingLocation(), R->getUniqueingDecl(),
|
|
|
|
findExecutedLines(SM, R->getErrorNode()));
|
2013-05-04 02:25:33 +08:00
|
|
|
}
|
|
|
|
|
2013-06-04 06:59:48 +08:00
|
|
|
static const Stmt *getStmtParent(const Stmt *S, const ParentMap &PM) {
|
2013-05-04 09:13:01 +08:00
|
|
|
if (!S)
|
2014-05-27 10:45:47 +08:00
|
|
|
return nullptr;
|
2013-05-17 14:48:27 +08:00
|
|
|
|
|
|
|
while (true) {
|
|
|
|
S = PM.getParentIgnoreParens(S);
|
|
|
|
|
|
|
|
if (!S)
|
|
|
|
break;
|
|
|
|
|
2018-10-31 11:48:47 +08:00
|
|
|
if (isa<FullExpr>(S) ||
|
2013-05-22 05:38:02 +08:00
|
|
|
isa<CXXBindTemporaryExpr>(S) ||
|
|
|
|
isa<SubstNonTypeTemplateParmExpr>(S))
|
2013-05-17 14:48:27 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return S;
|
2013-05-04 09:13:01 +08:00
|
|
|
}
|
|
|
|
|
2013-05-04 09:13:22 +08:00
|
|
|
static bool isConditionForTerminator(const Stmt *S, const Stmt *Cond) {
|
|
|
|
switch (S->getStmtClass()) {
|
2013-05-08 05:11:57 +08:00
|
|
|
case Stmt::BinaryOperatorClass: {
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *BO = cast<BinaryOperator>(S);
|
2013-05-08 05:11:57 +08:00
|
|
|
if (!BO->isLogicalOp())
|
|
|
|
return false;
|
|
|
|
return BO->getLHS() == Cond || BO->getRHS() == Cond;
|
|
|
|
}
|
2013-05-07 15:30:07 +08:00
|
|
|
case Stmt::IfStmtClass:
|
|
|
|
return cast<IfStmt>(S)->getCond() == Cond;
|
2013-05-04 09:13:22 +08:00
|
|
|
case Stmt::ForStmtClass:
|
|
|
|
return cast<ForStmt>(S)->getCond() == Cond;
|
|
|
|
case Stmt::WhileStmtClass:
|
|
|
|
return cast<WhileStmt>(S)->getCond() == Cond;
|
|
|
|
case Stmt::DoStmtClass:
|
|
|
|
return cast<DoStmt>(S)->getCond() == Cond;
|
|
|
|
case Stmt::ChooseExprClass:
|
|
|
|
return cast<ChooseExpr>(S)->getCond() == Cond;
|
|
|
|
case Stmt::IndirectGotoStmtClass:
|
|
|
|
return cast<IndirectGotoStmt>(S)->getTarget() == Cond;
|
|
|
|
case Stmt::SwitchStmtClass:
|
|
|
|
return cast<SwitchStmt>(S)->getCond() == Cond;
|
|
|
|
case Stmt::BinaryConditionalOperatorClass:
|
|
|
|
return cast<BinaryConditionalOperator>(S)->getCond() == Cond;
|
2013-05-08 09:15:20 +08:00
|
|
|
case Stmt::ConditionalOperatorClass: {
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *CO = cast<ConditionalOperator>(S);
|
2013-05-08 09:15:20 +08:00
|
|
|
return CO->getCond() == Cond ||
|
|
|
|
CO->getLHS() == Cond ||
|
|
|
|
CO->getRHS() == Cond;
|
|
|
|
}
|
2013-05-04 09:13:22 +08:00
|
|
|
case Stmt::ObjCForCollectionStmtClass:
|
|
|
|
return cast<ObjCForCollectionStmt>(S)->getElement() == Cond;
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
case Stmt::CXXForRangeStmtClass: {
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *FRS = cast<CXXForRangeStmt>(S);
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
return FRS->getCond() == Cond || FRS->getRangeInit() == Cond;
|
|
|
|
}
|
2013-05-04 09:13:22 +08:00
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-08 05:11:49 +08:00
|
|
|
static bool isIncrementOrInitInForLoop(const Stmt *S, const Stmt *FL) {
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *FS = dyn_cast<ForStmt>(FL))
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
return FS->getInc() == S || FS->getInit() == S;
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *FRS = dyn_cast<CXXForRangeStmt>(FL))
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
return FRS->getInc() == S || FRS->getRangeStmt() == S ||
|
|
|
|
FRS->getLoopVarStmt() || FRS->getRangeInit() == S;
|
|
|
|
return false;
|
2013-05-08 01:02:41 +08:00
|
|
|
}
|
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
using OptimizedCallsSet = llvm::DenseSet<const PathDiagnosticCallPiece *>;
|
2013-05-04 09:13:22 +08:00
|
|
|
|
2013-06-04 06:59:48 +08:00
|
|
|
/// Adds synthetic edges from top-level statements to their subexpressions.
|
|
|
|
///
|
|
|
|
/// This avoids a "swoosh" effect, where an edge from a top-level statement A
|
|
|
|
/// points to a sub-expression B.1 that's not at the start of B. In these cases,
|
|
|
|
/// we'd like to see an edge from A to B, then another one from B to B.1.
|
|
|
|
static void addContextEdges(PathPieces &pieces, SourceManager &SM,
|
|
|
|
const ParentMap &PM, const LocationContext *LCtx) {
|
|
|
|
PathPieces::iterator Prev = pieces.end();
|
|
|
|
for (PathPieces::iterator I = pieces.begin(), E = Prev; I != E;
|
|
|
|
Prev = I, ++I) {
|
2018-03-07 08:17:48 +08:00
|
|
|
auto *Piece = dyn_cast<PathDiagnosticControlFlowPiece>(I->get());
|
2013-06-04 06:59:48 +08:00
|
|
|
|
|
|
|
if (!Piece)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
PathDiagnosticLocation SrcLoc = Piece->getStartLocation();
|
2013-06-04 06:59:53 +08:00
|
|
|
SmallVector<PathDiagnosticLocation, 4> SrcContexts;
|
|
|
|
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
PathDiagnosticLocation NextSrcContext = SrcLoc;
|
2014-05-27 10:45:47 +08:00
|
|
|
const Stmt *InnerStmt = nullptr;
|
2013-06-04 06:59:53 +08:00
|
|
|
while (NextSrcContext.isValid() && NextSrcContext.asStmt() != InnerStmt) {
|
|
|
|
SrcContexts.push_back(NextSrcContext);
|
|
|
|
InnerStmt = NextSrcContext.asStmt();
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
NextSrcContext = getEnclosingStmtLocation(InnerStmt, SM, PM, LCtx,
|
|
|
|
/*allowNested=*/true);
|
2013-06-04 06:59:53 +08:00
|
|
|
}
|
2013-06-04 06:59:48 +08:00
|
|
|
|
|
|
|
// Repeatedly split the edge as necessary.
|
|
|
|
// This is important for nested logical expressions (||, &&, ?:) where we
|
|
|
|
// want to show all the levels of context.
|
|
|
|
while (true) {
|
2018-06-13 04:51:01 +08:00
|
|
|
const Stmt *Dst = Piece->getEndLocation().getStmtOrNull();
|
2013-06-04 06:59:48 +08:00
|
|
|
|
|
|
|
// We are looking at an edge. Is the destination within a larger
|
|
|
|
// expression?
|
|
|
|
PathDiagnosticLocation DstContext =
|
2013-06-04 06:59:53 +08:00
|
|
|
getEnclosingStmtLocation(Dst, SM, PM, LCtx, /*allowNested=*/true);
|
2013-06-04 06:59:48 +08:00
|
|
|
if (!DstContext.isValid() || DstContext.asStmt() == Dst)
|
|
|
|
break;
|
|
|
|
|
|
|
|
// If the source is in the same context, we're already good.
|
2019-03-31 16:48:19 +08:00
|
|
|
if (llvm::find(SrcContexts, DstContext) != SrcContexts.end())
|
2013-06-04 06:59:48 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
// Update the subexpression node to point to the context edge.
|
|
|
|
Piece->setStartLocation(DstContext);
|
|
|
|
|
|
|
|
// Try to extend the previous edge if it's at the same level as the source
|
|
|
|
// context.
|
|
|
|
if (Prev != E) {
|
2017-01-06 01:26:53 +08:00
|
|
|
auto *PrevPiece = dyn_cast<PathDiagnosticControlFlowPiece>(Prev->get());
|
2013-06-04 06:59:48 +08:00
|
|
|
|
|
|
|
if (PrevPiece) {
|
2018-06-13 04:51:01 +08:00
|
|
|
if (const Stmt *PrevSrc =
|
|
|
|
PrevPiece->getStartLocation().getStmtOrNull()) {
|
2013-06-04 06:59:48 +08:00
|
|
|
const Stmt *PrevSrcParent = getStmtParent(PrevSrc, PM);
|
2018-06-13 04:51:01 +08:00
|
|
|
if (PrevSrcParent ==
|
|
|
|
getStmtParent(DstContext.getStmtOrNull(), PM)) {
|
2013-06-04 06:59:48 +08:00
|
|
|
PrevPiece->setEndLocation(DstContext);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, split the current edge into a context edge and a
|
|
|
|
// subexpression edge. Note that the context statement may itself have
|
|
|
|
// context.
|
2017-01-06 01:26:53 +08:00
|
|
|
auto P =
|
|
|
|
std::make_shared<PathDiagnosticControlFlowPiece>(SrcLoc, DstContext);
|
|
|
|
Piece = P.get();
|
|
|
|
I = pieces.insert(I, std::move(P));
|
2013-06-04 06:59:48 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Move edges from a branch condition to a branch target
|
2013-06-04 06:59:48 +08:00
|
|
|
/// when the condition is simple.
|
|
|
|
///
|
|
|
|
/// This restructures some of the work of addContextEdges. That function
|
|
|
|
/// creates edges this may destroy, but they work together to create a more
|
|
|
|
/// aesthetically set of edges around branches. After the call to
|
|
|
|
/// addContextEdges, we may have (1) an edge to the branch, (2) an edge from
|
|
|
|
/// the branch to the branch condition, and (3) an edge from the branch
|
|
|
|
/// condition to the branch target. We keep (1), but may wish to remove (2)
|
|
|
|
/// and move the source of (3) to the branch if the branch condition is simple.
|
|
|
|
static void simplifySimpleBranches(PathPieces &pieces) {
|
|
|
|
for (PathPieces::iterator I = pieces.begin(), E = pieces.end(); I != E; ++I) {
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *PieceI = dyn_cast<PathDiagnosticControlFlowPiece>(I->get());
|
2013-06-04 06:59:48 +08:00
|
|
|
|
|
|
|
if (!PieceI)
|
|
|
|
continue;
|
|
|
|
|
2018-06-13 04:51:01 +08:00
|
|
|
const Stmt *s1Start = PieceI->getStartLocation().getStmtOrNull();
|
|
|
|
const Stmt *s1End = PieceI->getEndLocation().getStmtOrNull();
|
2013-06-04 06:59:48 +08:00
|
|
|
|
|
|
|
if (!s1Start || !s1End)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
PathPieces::iterator NextI = I; ++NextI;
|
|
|
|
if (NextI == E)
|
|
|
|
break;
|
|
|
|
|
2014-05-27 10:45:47 +08:00
|
|
|
PathDiagnosticControlFlowPiece *PieceNextI = nullptr;
|
2013-06-04 06:59:48 +08:00
|
|
|
|
|
|
|
while (true) {
|
|
|
|
if (NextI == E)
|
|
|
|
break;
|
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *EV = dyn_cast<PathDiagnosticEventPiece>(NextI->get());
|
2013-06-04 06:59:48 +08:00
|
|
|
if (EV) {
|
|
|
|
StringRef S = EV->getString();
|
2013-11-08 09:15:30 +08:00
|
|
|
if (S == StrEnteringLoop || S == StrLoopBodyZero ||
|
|
|
|
S == StrLoopCollectionEmpty || S == StrLoopRangeEmpty) {
|
2013-06-04 06:59:48 +08:00
|
|
|
++NextI;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-01-06 01:26:53 +08:00
|
|
|
PieceNextI = dyn_cast<PathDiagnosticControlFlowPiece>(NextI->get());
|
2013-06-04 06:59:48 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!PieceNextI)
|
|
|
|
continue;
|
|
|
|
|
2018-06-13 04:51:01 +08:00
|
|
|
const Stmt *s2Start = PieceNextI->getStartLocation().getStmtOrNull();
|
|
|
|
const Stmt *s2End = PieceNextI->getEndLocation().getStmtOrNull();
|
2013-06-04 06:59:48 +08:00
|
|
|
|
|
|
|
if (!s2Start || !s2End || s1End != s2Start)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// We only perform this transformation for specific branch kinds.
|
|
|
|
// We don't want to do this for do..while, for example.
|
|
|
|
if (!(isa<ForStmt>(s1Start) || isa<WhileStmt>(s1Start) ||
|
[analyzer; new edges] Simplify edges in a C++11 for-range loop.
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
2013-06-07 05:53:45 +08:00
|
|
|
isa<IfStmt>(s1Start) || isa<ObjCForCollectionStmt>(s1Start) ||
|
|
|
|
isa<CXXForRangeStmt>(s1Start)))
|
2013-06-04 06:59:48 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
// Is s1End the branch condition?
|
|
|
|
if (!isConditionForTerminator(s1Start, s1End))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Perform the hoisting by eliminating (2) and changing the start
|
|
|
|
// location of (3).
|
|
|
|
PieceNextI->setStartLocation(PieceI->getStartLocation());
|
|
|
|
I = pieces.erase(I);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-04 07:00:09 +08:00
|
|
|
/// Returns the number of bytes in the given (character-based) SourceRange.
|
2013-06-04 07:00:05 +08:00
|
|
|
///
|
|
|
|
/// If the locations in the range are not on the same line, returns None.
|
|
|
|
///
|
|
|
|
/// Note that this does not do a precise user-visible character or column count.
|
|
|
|
static Optional<size_t> getLengthOnSingleLine(SourceManager &SM,
|
|
|
|
SourceRange Range) {
|
|
|
|
SourceRange ExpansionRange(SM.getExpansionLoc(Range.getBegin()),
|
2018-04-30 13:25:48 +08:00
|
|
|
SM.getExpansionRange(Range.getEnd()).getEnd());
|
2013-06-04 07:00:05 +08:00
|
|
|
|
|
|
|
FileID FID = SM.getFileID(ExpansionRange.getBegin());
|
|
|
|
if (FID != SM.getFileID(ExpansionRange.getEnd()))
|
|
|
|
return None;
|
|
|
|
|
|
|
|
bool Invalid;
|
|
|
|
const llvm::MemoryBuffer *Buffer = SM.getBuffer(FID, &Invalid);
|
|
|
|
if (Invalid)
|
|
|
|
return None;
|
|
|
|
|
|
|
|
unsigned BeginOffset = SM.getFileOffset(ExpansionRange.getBegin());
|
|
|
|
unsigned EndOffset = SM.getFileOffset(ExpansionRange.getEnd());
|
|
|
|
StringRef Snippet = Buffer->getBuffer().slice(BeginOffset, EndOffset);
|
|
|
|
|
|
|
|
// We're searching the raw bytes of the buffer here, which might include
|
|
|
|
// escaped newlines and such. That's okay; we're trying to decide whether the
|
|
|
|
// SourceRange is covering a large or small amount of space in the user's
|
|
|
|
// editor.
|
|
|
|
if (Snippet.find_first_of("\r\n") != StringRef::npos)
|
|
|
|
return None;
|
|
|
|
|
|
|
|
// This isn't Unicode-aware, but it doesn't need to be.
|
|
|
|
return Snippet.size();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \sa getLengthOnSingleLine(SourceManager, SourceRange)
|
|
|
|
static Optional<size_t> getLengthOnSingleLine(SourceManager &SM,
|
|
|
|
const Stmt *S) {
|
|
|
|
return getLengthOnSingleLine(SM, S->getSourceRange());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Eliminate two-edge cycles created by addContextEdges().
|
|
|
|
///
|
|
|
|
/// Once all the context edges are in place, there are plenty of cases where
|
|
|
|
/// there's a single edge from a top-level statement to a subexpression,
|
|
|
|
/// followed by a single path note, and then a reverse edge to get back out to
|
|
|
|
/// the top level. If the statement is simple enough, the subexpression edges
|
|
|
|
/// just add noise and make it harder to understand what's going on.
|
|
|
|
///
|
|
|
|
/// This function only removes edges in pairs, because removing only one edge
|
|
|
|
/// might leave other edges dangling.
|
|
|
|
///
|
|
|
|
/// This will not remove edges in more complicated situations:
|
|
|
|
/// - if there is more than one "hop" leading to or from a subexpression.
|
|
|
|
/// - if there is an inlined call between the edges instead of a single event.
|
|
|
|
/// - if the whole statement is large enough that having subexpression arrows
|
|
|
|
/// might be helpful.
|
2018-09-29 02:49:41 +08:00
|
|
|
static void removeContextCycles(PathPieces &Path, SourceManager &SM) {
|
2013-06-04 07:00:00 +08:00
|
|
|
for (PathPieces::iterator I = Path.begin(), E = Path.end(); I != E; ) {
|
|
|
|
// Pattern match the current piece and its successor.
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *PieceI = dyn_cast<PathDiagnosticControlFlowPiece>(I->get());
|
2013-06-04 07:00:00 +08:00
|
|
|
|
|
|
|
if (!PieceI) {
|
|
|
|
++I;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-06-13 04:51:01 +08:00
|
|
|
const Stmt *s1Start = PieceI->getStartLocation().getStmtOrNull();
|
|
|
|
const Stmt *s1End = PieceI->getEndLocation().getStmtOrNull();
|
2013-06-04 07:00:00 +08:00
|
|
|
|
|
|
|
PathPieces::iterator NextI = I; ++NextI;
|
|
|
|
if (NextI == E)
|
|
|
|
break;
|
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *PieceNextI =
|
2017-01-06 01:26:53 +08:00
|
|
|
dyn_cast<PathDiagnosticControlFlowPiece>(NextI->get());
|
2013-06-04 07:00:00 +08:00
|
|
|
|
|
|
|
if (!PieceNextI) {
|
2017-01-06 01:26:53 +08:00
|
|
|
if (isa<PathDiagnosticEventPiece>(NextI->get())) {
|
2013-06-04 07:00:00 +08:00
|
|
|
++NextI;
|
|
|
|
if (NextI == E)
|
|
|
|
break;
|
2017-01-06 01:26:53 +08:00
|
|
|
PieceNextI = dyn_cast<PathDiagnosticControlFlowPiece>(NextI->get());
|
2013-06-04 07:00:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!PieceNextI) {
|
|
|
|
++I;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-13 04:51:01 +08:00
|
|
|
const Stmt *s2Start = PieceNextI->getStartLocation().getStmtOrNull();
|
|
|
|
const Stmt *s2End = PieceNextI->getEndLocation().getStmtOrNull();
|
2013-06-04 07:00:00 +08:00
|
|
|
|
|
|
|
if (s1Start && s2Start && s1Start == s2End && s2Start == s1End) {
|
2013-06-04 07:00:05 +08:00
|
|
|
const size_t MAX_SHORT_LINE_LENGTH = 80;
|
|
|
|
Optional<size_t> s1Length = getLengthOnSingleLine(SM, s1Start);
|
|
|
|
if (s1Length && *s1Length <= MAX_SHORT_LINE_LENGTH) {
|
|
|
|
Optional<size_t> s2Length = getLengthOnSingleLine(SM, s2Start);
|
|
|
|
if (s2Length && *s2Length <= MAX_SHORT_LINE_LENGTH) {
|
|
|
|
Path.erase(I);
|
|
|
|
I = Path.erase(NextI);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
2013-06-04 07:00:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
++I;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-09 09:00:01 +08:00
|
|
|
/// Return true if X is contained by Y.
|
2018-03-07 08:17:48 +08:00
|
|
|
static bool lexicalContains(ParentMap &PM, const Stmt *X, const Stmt *Y) {
|
2013-05-22 05:38:05 +08:00
|
|
|
while (X) {
|
|
|
|
if (X == Y)
|
|
|
|
return true;
|
|
|
|
X = PM.getParent(X);
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-05-23 02:52:35 +08:00
|
|
|
// Remove short edges on the same line less than 3 columns in difference.
|
2018-03-07 08:17:48 +08:00
|
|
|
static void removePunyEdges(PathPieces &path, SourceManager &SM,
|
2013-05-23 02:52:35 +08:00
|
|
|
ParentMap &PM) {
|
|
|
|
bool erased = false;
|
|
|
|
|
|
|
|
for (PathPieces::iterator I = path.begin(), E = path.end(); I != E;
|
|
|
|
erased ? I : ++I) {
|
|
|
|
erased = false;
|
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *PieceI = dyn_cast<PathDiagnosticControlFlowPiece>(I->get());
|
2013-05-23 02:52:35 +08:00
|
|
|
|
|
|
|
if (!PieceI)
|
|
|
|
continue;
|
|
|
|
|
2018-06-13 04:51:01 +08:00
|
|
|
const Stmt *start = PieceI->getStartLocation().getStmtOrNull();
|
|
|
|
const Stmt *end = PieceI->getEndLocation().getStmtOrNull();
|
2013-05-23 02:52:35 +08:00
|
|
|
|
|
|
|
if (!start || !end)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
const Stmt *endParent = PM.getParent(end);
|
|
|
|
if (!endParent)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (isConditionForTerminator(end, endParent))
|
|
|
|
continue;
|
|
|
|
|
2018-08-10 05:08:08 +08:00
|
|
|
SourceLocation FirstLoc = start->getBeginLoc();
|
|
|
|
SourceLocation SecondLoc = end->getBeginLoc();
|
2013-05-23 02:52:35 +08:00
|
|
|
|
2013-08-22 08:27:10 +08:00
|
|
|
if (!SM.isWrittenInSameFile(FirstLoc, SecondLoc))
|
2013-05-23 02:52:35 +08:00
|
|
|
continue;
|
2013-06-04 07:00:05 +08:00
|
|
|
if (SM.isBeforeInTranslationUnit(SecondLoc, FirstLoc))
|
|
|
|
std::swap(SecondLoc, FirstLoc);
|
2013-05-23 02:52:35 +08:00
|
|
|
|
2013-06-04 07:00:05 +08:00
|
|
|
SourceRange EdgeRange(FirstLoc, SecondLoc);
|
|
|
|
Optional<size_t> ByteWidth = getLengthOnSingleLine(SM, EdgeRange);
|
2013-05-23 02:52:35 +08:00
|
|
|
|
2013-06-04 07:00:05 +08:00
|
|
|
// If the statements are on different lines, continue.
|
|
|
|
if (!ByteWidth)
|
2013-05-23 02:52:35 +08:00
|
|
|
continue;
|
|
|
|
|
2013-06-04 07:00:05 +08:00
|
|
|
const size_t MAX_PUNY_EDGE_LENGTH = 2;
|
|
|
|
if (*ByteWidth <= MAX_PUNY_EDGE_LENGTH) {
|
|
|
|
// FIXME: There are enough /bytes/ between the endpoints of the edge, but
|
|
|
|
// there might not be enough /columns/. A proper user-visible column count
|
|
|
|
// is probably too expensive, though.
|
2013-05-23 03:25:03 +08:00
|
|
|
I = path.erase(I);
|
2013-05-23 02:52:35 +08:00
|
|
|
erased = true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-23 03:10:41 +08:00
|
|
|
static void removeIdenticalEvents(PathPieces &path) {
|
|
|
|
for (PathPieces::iterator I = path.begin(), E = path.end(); I != E; ++I) {
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *PieceI = dyn_cast<PathDiagnosticEventPiece>(I->get());
|
2013-05-23 03:10:41 +08:00
|
|
|
|
|
|
|
if (!PieceI)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
PathPieces::iterator NextI = I; ++NextI;
|
|
|
|
if (NextI == E)
|
|
|
|
return;
|
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *PieceNextI = dyn_cast<PathDiagnosticEventPiece>(NextI->get());
|
2013-05-23 03:10:41 +08:00
|
|
|
|
|
|
|
if (!PieceNextI)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Erase the second piece if it has the same exact message text.
|
|
|
|
if (PieceI->getString() == PieceNextI->getString()) {
|
|
|
|
path.erase(NextI);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-04 09:13:22 +08:00
|
|
|
static bool optimizeEdges(PathPieces &path, SourceManager &SM,
|
|
|
|
OptimizedCallsSet &OCS,
|
2013-05-18 10:26:50 +08:00
|
|
|
LocationContextMap &LCM) {
|
2013-05-04 09:13:01 +08:00
|
|
|
bool hasChanges = false;
|
|
|
|
const LocationContext *LC = LCM[&path];
|
|
|
|
assert(LC);
|
2013-05-23 02:52:35 +08:00
|
|
|
ParentMap &PM = LC->getParentMap();
|
2013-05-04 09:13:01 +08:00
|
|
|
|
2013-05-07 05:59:37 +08:00
|
|
|
for (PathPieces::iterator I = path.begin(), E = path.end(); I != E; ) {
|
2013-05-04 09:13:01 +08:00
|
|
|
// Optimize subpaths.
|
2017-01-06 01:26:53 +08:00
|
|
|
if (auto *CallI = dyn_cast<PathDiagnosticCallPiece>(I->get())) {
|
2013-05-07 05:59:37 +08:00
|
|
|
// Record the fact that a call has been optimized so we only do the
|
|
|
|
// effort once.
|
2013-05-04 09:13:22 +08:00
|
|
|
if (!OCS.count(CallI)) {
|
2013-05-18 10:26:50 +08:00
|
|
|
while (optimizeEdges(CallI->path, SM, OCS, LCM)) {}
|
2013-05-04 09:13:22 +08:00
|
|
|
OCS.insert(CallI);
|
|
|
|
}
|
2013-05-07 05:59:37 +08:00
|
|
|
++I;
|
2013-05-04 09:13:01 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Pattern match the current piece and its successor.
|
2017-01-06 01:26:53 +08:00
|
|
|
auto *PieceI = dyn_cast<PathDiagnosticControlFlowPiece>(I->get());
|
2013-05-04 09:13:01 +08:00
|
|
|
|
2013-05-07 05:59:37 +08:00
|
|
|
if (!PieceI) {
|
|
|
|
++I;
|
2013-05-04 09:13:01 +08:00
|
|
|
continue;
|
2013-05-07 05:59:37 +08:00
|
|
|
}
|
2013-05-04 09:13:01 +08:00
|
|
|
|
2018-06-13 04:51:01 +08:00
|
|
|
const Stmt *s1Start = PieceI->getStartLocation().getStmtOrNull();
|
|
|
|
const Stmt *s1End = PieceI->getEndLocation().getStmtOrNull();
|
2013-05-04 09:13:08 +08:00
|
|
|
const Stmt *level1 = getStmtParent(s1Start, PM);
|
|
|
|
const Stmt *level2 = getStmtParent(s1End, PM);
|
|
|
|
|
2013-05-04 09:13:22 +08:00
|
|
|
PathPieces::iterator NextI = I; ++NextI;
|
|
|
|
if (NextI == E)
|
|
|
|
break;
|
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *PieceNextI = dyn_cast<PathDiagnosticControlFlowPiece>(NextI->get());
|
2013-05-04 09:13:01 +08:00
|
|
|
|
2013-05-07 05:59:37 +08:00
|
|
|
if (!PieceNextI) {
|
|
|
|
++I;
|
2013-05-04 09:13:01 +08:00
|
|
|
continue;
|
2013-05-07 05:59:37 +08:00
|
|
|
}
|
2013-05-04 09:13:01 +08:00
|
|
|
|
2018-06-13 04:51:01 +08:00
|
|
|
const Stmt *s2Start = PieceNextI->getStartLocation().getStmtOrNull();
|
|
|
|
const Stmt *s2End = PieceNextI->getEndLocation().getStmtOrNull();
|
2013-05-04 09:13:08 +08:00
|
|
|
const Stmt *level3 = getStmtParent(s2Start, PM);
|
|
|
|
const Stmt *level4 = getStmtParent(s2End, PM);
|
2013-05-04 09:13:01 +08:00
|
|
|
|
|
|
|
// Rule I.
|
|
|
|
//
|
|
|
|
// If we have two consecutive control edges whose end/begin locations
|
2013-05-07 05:59:37 +08:00
|
|
|
// are at the same level (e.g. statements or top-level expressions within
|
|
|
|
// a compound statement, or siblings share a single ancestor expression),
|
|
|
|
// then merge them if they have no interesting intermediate event.
|
2013-05-04 09:13:01 +08:00
|
|
|
//
|
|
|
|
// For example:
|
|
|
|
//
|
|
|
|
// (1.1 -> 1.2) -> (1.2 -> 1.3) becomes (1.1 -> 1.3) because the common
|
2013-05-07 05:59:37 +08:00
|
|
|
// parent is '1'. Here 'x.y.z' represents the hierarchy of statements.
|
2013-05-04 09:13:01 +08:00
|
|
|
//
|
|
|
|
// NOTE: this will be limited later in cases where we add barriers
|
|
|
|
// to prevent this optimization.
|
2013-05-07 05:59:37 +08:00
|
|
|
if (level1 && level1 == level2 && level1 == level3 && level1 == level4) {
|
2013-05-04 09:13:01 +08:00
|
|
|
PieceI->setEndLocation(PieceNextI->getEndLocation());
|
|
|
|
path.erase(NextI);
|
|
|
|
hasChanges = true;
|
|
|
|
continue;
|
|
|
|
}
|
2013-05-04 09:13:05 +08:00
|
|
|
|
|
|
|
// Rule II.
|
|
|
|
//
|
2013-05-07 15:30:07 +08:00
|
|
|
// Eliminate edges between subexpressions and parent expressions
|
|
|
|
// when the subexpression is consumed.
|
2013-05-04 09:13:08 +08:00
|
|
|
//
|
|
|
|
// NOTE: this will be limited later in cases where we add barriers
|
|
|
|
// to prevent this optimization.
|
2013-05-08 05:11:49 +08:00
|
|
|
if (s1End && s1End == s2Start && level2) {
|
2013-05-22 05:38:05 +08:00
|
|
|
bool removeEdge = false;
|
|
|
|
// Remove edges into the increment or initialization of a
|
|
|
|
// loop that have no interleaving event. This means that
|
|
|
|
// they aren't interesting.
|
|
|
|
if (isIncrementOrInitInForLoop(s1End, level2))
|
|
|
|
removeEdge = true;
|
|
|
|
// Next only consider edges that are not anchored on
|
|
|
|
// the condition of a terminator. This are intermediate edges
|
|
|
|
// that we might want to trim.
|
|
|
|
else if (!isConditionForTerminator(level2, s1End)) {
|
|
|
|
// Trim edges on expressions that are consumed by
|
|
|
|
// the parent expression.
|
|
|
|
if (isa<Expr>(s1End) && PM.isConsumedExpr(cast<Expr>(s1End))) {
|
2015-09-08 11:50:52 +08:00
|
|
|
removeEdge = true;
|
2013-05-22 05:38:05 +08:00
|
|
|
}
|
|
|
|
// Trim edges where a lexical containment doesn't exist.
|
|
|
|
// For example:
|
|
|
|
//
|
|
|
|
// X -> Y -> Z
|
|
|
|
//
|
|
|
|
// If 'Z' lexically contains Y (it is an ancestor) and
|
|
|
|
// 'X' does not lexically contain Y (it is a descendant OR
|
|
|
|
// it has no lexical relationship at all) then trim.
|
|
|
|
//
|
|
|
|
// This can eliminate edges where we dive into a subexpression
|
|
|
|
// and then pop back out, etc.
|
|
|
|
else if (s1Start && s2End &&
|
|
|
|
lexicalContains(PM, s2Start, s2End) &&
|
|
|
|
!lexicalContains(PM, s1End, s1Start)) {
|
|
|
|
removeEdge = true;
|
|
|
|
}
|
2013-06-04 07:00:09 +08:00
|
|
|
// Trim edges from a subexpression back to the top level if the
|
|
|
|
// subexpression is on a different line.
|
|
|
|
//
|
|
|
|
// A.1 -> A -> B
|
|
|
|
// becomes
|
|
|
|
// A.1 -> B
|
|
|
|
//
|
|
|
|
// These edges just look ugly and don't usually add anything.
|
|
|
|
else if (s1Start && s2End &&
|
|
|
|
lexicalContains(PM, s1Start, s1End)) {
|
|
|
|
SourceRange EdgeRange(PieceI->getEndLocation().asLocation(),
|
|
|
|
PieceI->getStartLocation().asLocation());
|
|
|
|
if (!getLengthOnSingleLine(SM, EdgeRange).hasValue())
|
|
|
|
removeEdge = true;
|
|
|
|
}
|
2013-05-22 05:38:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (removeEdge) {
|
2013-05-08 05:11:49 +08:00
|
|
|
PieceI->setEndLocation(PieceNextI->getEndLocation());
|
|
|
|
path.erase(NextI);
|
|
|
|
hasChanges = true;
|
|
|
|
continue;
|
|
|
|
}
|
2013-05-04 09:13:08 +08:00
|
|
|
}
|
2013-05-07 05:59:37 +08:00
|
|
|
|
2013-05-21 08:34:40 +08:00
|
|
|
// Optimize edges for ObjC fast-enumeration loops.
|
|
|
|
//
|
|
|
|
// (X -> collection) -> (collection -> element)
|
|
|
|
//
|
|
|
|
// becomes:
|
|
|
|
//
|
|
|
|
// (X -> element)
|
|
|
|
if (s1End == s2Start) {
|
2018-03-07 08:17:48 +08:00
|
|
|
const auto *FS = dyn_cast_or_null<ObjCForCollectionStmt>(level3);
|
2013-05-21 08:34:40 +08:00
|
|
|
if (FS && FS->getCollection()->IgnoreParens() == s2Start &&
|
|
|
|
s2End == FS->getElement()) {
|
|
|
|
PieceI->setEndLocation(PieceNextI->getEndLocation());
|
|
|
|
path.erase(NextI);
|
|
|
|
hasChanges = true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-07 05:59:37 +08:00
|
|
|
// No changes at this index? Move to the next one.
|
|
|
|
++I;
|
2013-05-04 09:13:01 +08:00
|
|
|
}
|
|
|
|
|
2013-05-23 02:52:35 +08:00
|
|
|
if (!hasChanges) {
|
2013-06-04 06:59:48 +08:00
|
|
|
// Adjust edges into subexpressions to make them more uniform
|
|
|
|
// and aesthetically pleasing.
|
|
|
|
addContextEdges(path, SM, PM, LC);
|
2013-06-04 07:00:00 +08:00
|
|
|
// Remove "cyclical" edges that include one or more context edges.
|
2018-09-29 02:49:41 +08:00
|
|
|
removeContextCycles(path, SM);
|
2013-06-04 06:59:48 +08:00
|
|
|
// Hoist edges originating from branch conditions to branches
|
|
|
|
// for simple branches.
|
|
|
|
simplifySimpleBranches(path);
|
2013-05-23 02:52:35 +08:00
|
|
|
// Remove any puny edges left over after primary optimization pass.
|
|
|
|
removePunyEdges(path, SM, PM);
|
2013-05-23 03:10:41 +08:00
|
|
|
// Remove identical events.
|
|
|
|
removeIdenticalEvents(path);
|
2013-05-23 02:52:35 +08:00
|
|
|
}
|
|
|
|
|
2013-05-04 09:13:01 +08:00
|
|
|
return hasChanges;
|
|
|
|
}
|
|
|
|
|
2013-06-04 06:59:45 +08:00
|
|
|
/// Drop the very first edge in a path, which should be a function entry edge.
|
2013-06-06 08:12:41 +08:00
|
|
|
///
|
|
|
|
/// If the first edge is not a function entry edge (say, because the first
|
|
|
|
/// statement had an invalid source location), this function does nothing.
|
|
|
|
// FIXME: We should just generate invalid edges anyway and have the optimizer
|
|
|
|
// deal with them.
|
2018-03-07 08:17:48 +08:00
|
|
|
static void dropFunctionEntryEdge(PathPieces &Path, LocationContextMap &LCM,
|
2013-06-04 06:59:45 +08:00
|
|
|
SourceManager &SM) {
|
2017-01-06 01:26:53 +08:00
|
|
|
const auto *FirstEdge =
|
|
|
|
dyn_cast<PathDiagnosticControlFlowPiece>(Path.front().get());
|
2013-06-06 08:12:41 +08:00
|
|
|
if (!FirstEdge)
|
|
|
|
return;
|
|
|
|
|
|
|
|
const Decl *D = LCM[&Path]->getDecl();
|
|
|
|
PathDiagnosticLocation EntryLoc = PathDiagnosticLocation::createBegin(D, SM);
|
|
|
|
if (FirstEdge->getStartLocation() != EntryLoc)
|
|
|
|
return;
|
2013-06-04 06:59:45 +08:00
|
|
|
|
|
|
|
Path.pop_front();
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
using VisitorsDiagnosticsTy = llvm::DenseMap<const ExplodedNode *,
|
|
|
|
std::vector<std::shared_ptr<PathDiagnosticPiece>>>;
|
|
|
|
|
2018-09-07 08:42:53 +08:00
|
|
|
/// Populate executes lines with lines containing at least one diagnostics.
|
|
|
|
static void updateExecutedLinesWithDiagnosticPieces(
|
|
|
|
PathDiagnostic &PD) {
|
|
|
|
|
|
|
|
PathPieces path = PD.path.flatten(/*ShouldFlattenMacros=*/true);
|
|
|
|
FilesToLineNumsMap &ExecutedLines = PD.getExecutedLines();
|
|
|
|
|
|
|
|
for (const auto &P : path) {
|
|
|
|
FullSourceLoc Loc = P->getLocation().asLocation().getExpansionLoc();
|
|
|
|
FileID FID = Loc.getFileID();
|
|
|
|
unsigned LineNo = Loc.getLineNumber();
|
2018-09-07 08:43:17 +08:00
|
|
|
assert(FID.isValid());
|
2018-09-07 08:43:37 +08:00
|
|
|
ExecutedLines[FID].insert(LineNo);
|
2018-09-07 08:42:53 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
/// This function is responsible for generating diagnostic pieces that are
|
|
|
|
/// *not* provided by bug report visitors.
|
|
|
|
/// These diagnostics may differ depending on the consumer's settings,
|
|
|
|
/// and are therefore constructed separately for each consumer.
|
|
|
|
///
|
|
|
|
/// There are two path diagnostics generation modes: with adding edges (used
|
|
|
|
/// for plists) and without (used for HTML and text).
|
|
|
|
/// When edges are added (\p ActiveScheme is Extensive),
|
|
|
|
/// the path is modified to insert artificially generated
|
|
|
|
/// edges.
|
|
|
|
/// Otherwise, more detailed diagnostics is emitted for block edges, explaining
|
|
|
|
/// the transitions in words.
|
|
|
|
static std::unique_ptr<PathDiagnostic> generatePathDiagnosticForConsumer(
|
|
|
|
PathDiagnosticConsumer::PathGenerationScheme ActiveScheme,
|
|
|
|
PathDiagnosticBuilder &PDB,
|
|
|
|
const ExplodedNode *ErrorNode,
|
|
|
|
const VisitorsDiagnosticsTy &VisitorsDiagnostics) {
|
|
|
|
|
|
|
|
bool GenerateDiagnostics = (ActiveScheme != PathDiagnosticConsumer::None);
|
|
|
|
bool AddPathEdges = (ActiveScheme == PathDiagnosticConsumer::Extensive);
|
|
|
|
SourceManager &SM = PDB.getSourceManager();
|
|
|
|
BugReport *R = PDB.getBugReport();
|
|
|
|
AnalyzerOptions &Opts = PDB.getBugReporter().getAnalyzerOptions();
|
|
|
|
StackDiagVector CallStack;
|
|
|
|
InterestingExprs IE;
|
|
|
|
LocationContextMap LCM;
|
|
|
|
std::unique_ptr<PathDiagnostic> PD = generateEmptyDiagnosticForReport(R, SM);
|
|
|
|
|
|
|
|
if (GenerateDiagnostics) {
|
|
|
|
auto EndNotes = VisitorsDiagnostics.find(ErrorNode);
|
|
|
|
std::shared_ptr<PathDiagnosticPiece> LastPiece;
|
|
|
|
if (EndNotes != VisitorsDiagnostics.end()) {
|
|
|
|
assert(!EndNotes->second.empty());
|
|
|
|
LastPiece = EndNotes->second[0];
|
|
|
|
} else {
|
|
|
|
LastPiece = BugReporterVisitor::getDefaultEndPath(PDB, ErrorNode, *R);
|
|
|
|
}
|
|
|
|
PD->setEndOfPath(LastPiece);
|
|
|
|
}
|
|
|
|
|
|
|
|
PathDiagnosticLocation PrevLoc = PD->getLocation();
|
|
|
|
const ExplodedNode *NextNode = ErrorNode->getFirstPred();
|
|
|
|
while (NextNode) {
|
|
|
|
if (GenerateDiagnostics)
|
|
|
|
generatePathDiagnosticsForNode(
|
|
|
|
NextNode, *PD, PrevLoc, PDB, LCM, CallStack, IE, AddPathEdges);
|
|
|
|
|
|
|
|
auto VisitorNotes = VisitorsDiagnostics.find(NextNode);
|
|
|
|
NextNode = NextNode->getFirstPred();
|
|
|
|
if (!GenerateDiagnostics || VisitorNotes == VisitorsDiagnostics.end())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// This is a workaround due to inability to put shared PathDiagnosticPiece
|
|
|
|
// into a FoldingSet.
|
|
|
|
std::set<llvm::FoldingSetNodeID> DeduplicationSet;
|
|
|
|
|
|
|
|
// Add pieces from custom visitors.
|
|
|
|
for (const auto &Note : VisitorNotes->second) {
|
|
|
|
llvm::FoldingSetNodeID ID;
|
|
|
|
Note->Profile(ID);
|
|
|
|
auto P = DeduplicationSet.insert(ID);
|
|
|
|
if (!P.second)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (AddPathEdges)
|
2018-09-29 02:49:41 +08:00
|
|
|
addEdgeToPath(PD->getActivePath(), PrevLoc, Note->getLocation());
|
[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
|
|
|
updateStackPiecesWithMessage(*Note, CallStack);
|
|
|
|
PD->getActivePath().push_front(Note);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (AddPathEdges) {
|
|
|
|
// Add an edge to the start of the function.
|
|
|
|
// We'll prune it out later, but it helps make diagnostics more uniform.
|
2018-06-27 09:51:55 +08:00
|
|
|
const StackFrameContext *CalleeLC = PDB.LC->getStackFrame();
|
[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
|
|
|
const Decl *D = CalleeLC->getDecl();
|
|
|
|
addEdgeToPath(PD->getActivePath(), PrevLoc,
|
2018-09-29 02:49:41 +08:00
|
|
|
PathDiagnosticLocation::createBegin(D, SM));
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// Finally, prune the diagnostic path of uninteresting stuff.
|
|
|
|
if (!PD->path.empty()) {
|
[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
|
|
|
if (R->shouldPrunePath() && Opts.ShouldPrunePaths) {
|
[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
|
|
|
bool stillHasNotes =
|
|
|
|
removeUnneededCalls(PD->getMutablePieces(), R, LCM);
|
|
|
|
assert(stillHasNotes);
|
|
|
|
(void)stillHasNotes;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Redirect all call pieces to have valid locations.
|
|
|
|
adjustCallLocations(PD->getMutablePieces());
|
|
|
|
removePiecesWithInvalidLocations(PD->getMutablePieces());
|
|
|
|
|
|
|
|
if (AddPathEdges) {
|
|
|
|
|
|
|
|
// Reduce the number of edges from a very conservative set
|
|
|
|
// to an aesthetically pleasing subset that conveys the
|
|
|
|
// necessary information.
|
|
|
|
OptimizedCallsSet OCS;
|
|
|
|
while (optimizeEdges(PD->getMutablePieces(), SM, OCS, LCM)) {}
|
|
|
|
|
|
|
|
// Drop the very first function-entry edge. It's not really necessary
|
|
|
|
// for top-level functions.
|
|
|
|
dropFunctionEntryEdge(PD->getMutablePieces(), LCM, SM);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Remove messages that are basically the same, and edges that may not
|
|
|
|
// make sense.
|
|
|
|
// We have to do this after edge optimization in the Extensive mode.
|
|
|
|
removeRedundantMsgs(PD->getMutablePieces());
|
|
|
|
removeEdgesToDefaultInitializers(PD->getMutablePieces());
|
|
|
|
}
|
2018-10-31 22:54:27 +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
|
|
|
if (GenerateDiagnostics && Opts.ShouldDisplayMacroExpansions)
|
2018-10-31 22:54:27 +08:00
|
|
|
CompactMacroExpandedPieces(PD->getMutablePieces(), SM);
|
|
|
|
|
[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
|
|
|
return PD;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Methods for BugType and subclasses.
|
|
|
|
//===----------------------------------------------------------------------===//
|
2018-03-07 08:17:48 +08:00
|
|
|
|
|
|
|
void BugType::anchor() {}
|
2011-02-23 08:16:01 +08:00
|
|
|
|
2011-12-20 10:48:34 +08:00
|
|
|
void BuiltinBug::anchor() {}
|
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Methods for BugReport and subclasses.
|
|
|
|
//===----------------------------------------------------------------------===//
|
2011-08-18 07:00:25 +08:00
|
|
|
|
2011-12-20 10:48:34 +08:00
|
|
|
void BugReport::NodeResolver::anchor() {}
|
|
|
|
|
2014-09-05 07:54:33 +08:00
|
|
|
void BugReport::addVisitor(std::unique_ptr<BugReporterVisitor> visitor) {
|
2011-08-19 06:37:56 +08:00
|
|
|
if (!visitor)
|
|
|
|
return;
|
|
|
|
|
|
|
|
llvm::FoldingSetNodeID ID;
|
|
|
|
visitor->Profile(ID);
|
|
|
|
|
[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
|
|
|
void *InsertPos = nullptr;
|
|
|
|
if (CallbacksSet.FindNodeOrInsertPos(ID, InsertPos)) {
|
2011-08-19 06:37:56 +08:00
|
|
|
return;
|
[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
|
|
|
}
|
2011-08-19 06:37:56 +08:00
|
|
|
|
2014-09-05 07:54:33 +08:00
|
|
|
Callbacks.push_back(std::move(visitor));
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
void BugReport::clearVisitors() {
|
|
|
|
Callbacks.clear();
|
2011-08-19 06:37:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
BugReport::~BugReport() {
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
while (!interestingSymbols.empty()) {
|
|
|
|
popInterestingSymbolsAndRegions();
|
|
|
|
}
|
2011-08-19 06:37:56 +08:00
|
|
|
}
|
2011-08-18 07:00:25 +08:00
|
|
|
|
2012-04-05 02:11:35 +08:00
|
|
|
const Decl *BugReport::getDeclWithIssue() const {
|
|
|
|
if (DeclWithIssue)
|
|
|
|
return DeclWithIssue;
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2012-04-05 02:11:35 +08:00
|
|
|
const ExplodedNode *N = getErrorNode();
|
|
|
|
if (!N)
|
2014-05-27 10:45:47 +08:00
|
|
|
return nullptr;
|
|
|
|
|
2012-04-05 02:11:35 +08:00
|
|
|
const LocationContext *LC = N->getLocationContext();
|
2018-06-27 09:51:55 +08:00
|
|
|
return LC->getStackFrame()->getDecl();
|
2012-04-05 02:11:35 +08:00
|
|
|
}
|
|
|
|
|
2011-08-18 07:00:25 +08:00
|
|
|
void BugReport::Profile(llvm::FoldingSetNodeID& hash) const {
|
|
|
|
hash.AddPointer(&BT);
|
|
|
|
hash.AddString(Description);
|
2013-01-08 08:25:29 +08:00
|
|
|
PathDiagnosticLocation UL = getUniqueingLocation();
|
|
|
|
if (UL.isValid()) {
|
|
|
|
UL.Profile(hash);
|
2012-02-24 05:38:21 +08:00
|
|
|
} else if (Location.isValid()) {
|
2011-09-21 05:38:35 +08:00
|
|
|
Location.Profile(hash);
|
|
|
|
} else {
|
|
|
|
assert(ErrorNode);
|
|
|
|
hash.AddPointer(GetCurrentOrPreviousStmt(ErrorNode));
|
|
|
|
}
|
2011-08-18 07:00:25 +08:00
|
|
|
|
2015-10-04 12:53:55 +08:00
|
|
|
for (SourceRange range : Ranges) {
|
2011-08-18 07:00:25 +08:00
|
|
|
if (!range.isValid())
|
|
|
|
continue;
|
|
|
|
hash.AddInteger(range.getBegin().getRawEncoding());
|
|
|
|
hash.AddInteger(range.getEnd().getRawEncoding());
|
|
|
|
}
|
|
|
|
}
|
2009-04-01 07:00:32 +08:00
|
|
|
|
2012-03-09 09:13:14 +08:00
|
|
|
void BugReport::markInteresting(SymbolRef sym) {
|
|
|
|
if (!sym)
|
|
|
|
return;
|
2012-03-24 11:03:29 +08:00
|
|
|
|
[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
|
|
|
getInterestingSymbols().insert(sym);
|
2012-03-16 06:45:29 +08:00
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *meta = dyn_cast<SymbolMetadata>(sym))
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
getInterestingRegions().insert(meta->getRegion());
|
2012-03-09 09:13:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void BugReport::markInteresting(const MemRegion *R) {
|
|
|
|
if (!R)
|
|
|
|
return;
|
2012-03-24 11:03:29 +08:00
|
|
|
|
2012-03-09 09:13:14 +08:00
|
|
|
R = R->getBaseRegion();
|
[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
|
|
|
getInterestingRegions().insert(R);
|
2012-03-16 06:45:29 +08:00
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *SR = dyn_cast<SymbolicRegion>(R))
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
getInterestingSymbols().insert(SR->getSymbol());
|
2012-03-09 09:13:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void BugReport::markInteresting(SVal V) {
|
|
|
|
markInteresting(V.getAsRegion());
|
|
|
|
markInteresting(V.getAsSymbol());
|
|
|
|
}
|
|
|
|
|
2012-08-30 05:22:37 +08:00
|
|
|
void BugReport::markInteresting(const LocationContext *LC) {
|
|
|
|
if (!LC)
|
|
|
|
return;
|
|
|
|
InterestingLocationContexts.insert(LC);
|
|
|
|
}
|
|
|
|
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
bool BugReport::isInteresting(SVal V) {
|
2012-03-09 09:13:14 +08:00
|
|
|
return isInteresting(V.getAsRegion()) || isInteresting(V.getAsSymbol());
|
|
|
|
}
|
|
|
|
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
bool BugReport::isInteresting(SymbolRef sym) {
|
2012-03-09 09:13:14 +08:00
|
|
|
if (!sym)
|
|
|
|
return false;
|
2012-03-16 06:45:29 +08:00
|
|
|
// We don't currently consider metadata symbols to be interesting
|
|
|
|
// even if we know their region is interesting. Is that correct behavior?
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
return getInterestingSymbols().count(sym);
|
2012-03-09 09:13:14 +08:00
|
|
|
}
|
|
|
|
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
bool BugReport::isInteresting(const MemRegion *R) {
|
2012-03-09 09:13:14 +08:00
|
|
|
if (!R)
|
|
|
|
return false;
|
|
|
|
R = R->getBaseRegion();
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
bool b = getInterestingRegions().count(R);
|
2012-03-09 09:13:14 +08:00
|
|
|
if (b)
|
|
|
|
return true;
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *SR = dyn_cast<SymbolicRegion>(R))
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
return getInterestingSymbols().count(SR->getSymbol());
|
2012-03-09 09:13:14 +08:00
|
|
|
return false;
|
|
|
|
}
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
|
2012-08-30 05:22:37 +08:00
|
|
|
bool BugReport::isInteresting(const LocationContext *LC) {
|
|
|
|
if (!LC)
|
|
|
|
return false;
|
|
|
|
return InterestingLocationContexts.count(LC);
|
|
|
|
}
|
|
|
|
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
void BugReport::lazyInitializeInterestingSets() {
|
|
|
|
if (interestingSymbols.empty()) {
|
|
|
|
interestingSymbols.push_back(new Symbols());
|
|
|
|
interestingRegions.push_back(new Regions());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
BugReport::Symbols &BugReport::getInterestingSymbols() {
|
|
|
|
lazyInitializeInterestingSets();
|
|
|
|
return *interestingSymbols.back();
|
|
|
|
}
|
|
|
|
|
|
|
|
BugReport::Regions &BugReport::getInterestingRegions() {
|
|
|
|
lazyInitializeInterestingSets();
|
|
|
|
return *interestingRegions.back();
|
|
|
|
}
|
|
|
|
|
|
|
|
void BugReport::pushInterestingSymbolsAndRegions() {
|
|
|
|
interestingSymbols.push_back(new Symbols(getInterestingSymbols()));
|
|
|
|
interestingRegions.push_back(new Regions(getInterestingRegions()));
|
|
|
|
}
|
|
|
|
|
|
|
|
void BugReport::popInterestingSymbolsAndRegions() {
|
2013-08-24 00:11:15 +08:00
|
|
|
delete interestingSymbols.pop_back_val();
|
|
|
|
delete interestingRegions.pop_back_val();
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
}
|
2012-03-09 09:13:14 +08:00
|
|
|
|
2011-08-13 07:37:29 +08:00
|
|
|
const Stmt *BugReport::getStmt() const {
|
2011-08-18 07:00:25 +08:00
|
|
|
if (!ErrorNode)
|
2014-05-27 10:45:47 +08:00
|
|
|
return nullptr;
|
2011-08-18 07:00:25 +08:00
|
|
|
|
2010-09-16 11:50:38 +08:00
|
|
|
ProgramPoint ProgP = ErrorNode->getLocation();
|
2014-05-27 10:45:47 +08:00
|
|
|
const Stmt *S = nullptr;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-02-22 06:23:56 +08:00
|
|
|
if (Optional<BlockEntrance> BE = ProgP.getAs<BlockEntrance>()) {
|
2009-08-20 09:23:34 +08:00
|
|
|
CFGBlock &Exit = ProgP.getLocationContext()->getCFG()->getExit();
|
2009-08-18 16:46:04 +08:00
|
|
|
if (BE->getBlock() == &Exit)
|
2010-09-16 11:50:38 +08:00
|
|
|
S = GetPreviousStmt(ErrorNode);
|
2009-04-01 07:00:32 +08:00
|
|
|
}
|
2009-07-23 06:35:28 +08:00
|
|
|
if (!S)
|
2013-04-24 07:57:43 +08:00
|
|
|
S = PathDiagnosticLocation::getStmt(ErrorNode);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
|
|
|
return S;
|
2009-04-01 07:00:32 +08:00
|
|
|
}
|
|
|
|
|
2015-02-07 01:25:10 +08:00
|
|
|
llvm::iterator_range<BugReport::ranges_iterator> BugReport::getRanges() {
|
|
|
|
// If no custom ranges, add the range of the statement corresponding to
|
|
|
|
// the error node.
|
|
|
|
if (Ranges.empty()) {
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *E = dyn_cast_or_null<Expr>(getStmt()))
|
2015-02-07 01:25:10 +08:00
|
|
|
addRange(E->getSourceRange());
|
|
|
|
else
|
|
|
|
return llvm::make_range(ranges_iterator(), ranges_iterator());
|
|
|
|
}
|
2011-08-18 07:00:25 +08:00
|
|
|
|
2015-02-07 01:25:10 +08:00
|
|
|
// User-specified absence of range info.
|
|
|
|
if (Ranges.size() == 1 && !Ranges.begin()->isValid())
|
|
|
|
return llvm::make_range(ranges_iterator(), ranges_iterator());
|
2011-08-25 04:31:06 +08:00
|
|
|
|
2015-12-06 13:07:12 +08:00
|
|
|
return llvm::make_range(Ranges.begin(), Ranges.end());
|
2009-04-01 07:00:32 +08:00
|
|
|
}
|
|
|
|
|
2011-09-21 05:38:35 +08:00
|
|
|
PathDiagnosticLocation BugReport::getLocation(const SourceManager &SM) const {
|
2011-08-18 07:21:23 +08:00
|
|
|
if (ErrorNode) {
|
2011-09-21 05:38:35 +08:00
|
|
|
assert(!Location.isValid() &&
|
2011-08-18 07:21:23 +08:00
|
|
|
"Either Location or ErrorNode should be specified but not both.");
|
2013-04-24 07:57:43 +08:00
|
|
|
return PathDiagnosticLocation::createEndOfPath(ErrorNode, SM);
|
2011-08-18 07:21:23 +08:00
|
|
|
}
|
|
|
|
|
2014-03-06 13:37:28 +08:00
|
|
|
assert(Location.isValid());
|
|
|
|
return Location;
|
2009-04-01 07:00:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Methods for BugReporter and subclasses.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
BugReportEquivClass::~BugReportEquivClass() = default;
|
|
|
|
|
|
|
|
GRBugReporter::~GRBugReporter() = default;
|
|
|
|
|
|
|
|
BugReporterData::~BugReporterData() = default;
|
2009-04-01 07:00:32 +08:00
|
|
|
|
2009-08-06 14:28:40 +08:00
|
|
|
ExplodedGraph &GRBugReporter::getGraph() { return Eng.getGraph(); }
|
2009-04-01 07:00:32 +08:00
|
|
|
|
2011-08-16 06:09:50 +08:00
|
|
|
ProgramStateManager&
|
2009-04-01 07:00:32 +08:00
|
|
|
GRBugReporter::getStateManager() { return Eng.getStateManager(); }
|
|
|
|
|
2011-08-19 09:57:09 +08:00
|
|
|
BugReporter::~BugReporter() {
|
|
|
|
FlushReports();
|
|
|
|
|
|
|
|
// Free the bug reports we are tracking.
|
2018-03-07 08:17:48 +08:00
|
|
|
for (const auto I : EQClassesVector)
|
|
|
|
delete I;
|
2011-08-19 09:57:09 +08:00
|
|
|
}
|
2009-04-01 07:00:32 +08:00
|
|
|
|
|
|
|
void BugReporter::FlushReports() {
|
|
|
|
if (BugTypes.isEmpty())
|
|
|
|
return;
|
|
|
|
|
2012-08-03 07:41:05 +08:00
|
|
|
// We need to flush reports in deterministic order to ensure the order
|
|
|
|
// of the reports is consistent between runs.
|
2018-03-07 08:17:48 +08:00
|
|
|
for (const auto EQ : EQClassesVector)
|
|
|
|
FlushReport(*EQ);
|
2009-04-01 07:00:32 +08:00
|
|
|
|
2011-02-23 08:16:01 +08:00
|
|
|
// BugReporter owns and deletes only BugTypes created implicitly through
|
|
|
|
// EmitBasicReport.
|
|
|
|
// FIXME: There are leaks from checkers that assume that the BugTypes they
|
|
|
|
// create will be destroyed by the BugReporter.
|
2014-02-20 07:44:52 +08:00
|
|
|
llvm::DeleteContainerSeconds(StrBugTypes);
|
2011-02-23 08:16:01 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// Remove all references to the BugType objects.
|
2010-11-24 08:54:37 +08:00
|
|
|
BugTypes = F.getEmptySet();
|
2009-04-01 07:00:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// PathDiagnostics generation.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2013-03-16 09:07:58 +08:00
|
|
|
namespace {
|
2018-03-07 08:17:48 +08:00
|
|
|
|
2013-03-16 09:07:58 +08:00
|
|
|
/// A wrapper around a report graph, which contains only a single path, and its
|
|
|
|
/// node maps.
|
|
|
|
class ReportGraph {
|
|
|
|
public:
|
|
|
|
InterExplodedGraphMap BackMap;
|
2014-03-08 04:03:18 +08:00
|
|
|
std::unique_ptr<ExplodedGraph> Graph;
|
2013-03-23 05:15:28 +08:00
|
|
|
const ExplodedNode *ErrorNode;
|
2013-03-16 09:07:58 +08:00
|
|
|
size_t Index;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// A wrapper around a trimmed graph and its node maps.
|
|
|
|
class TrimmedGraph {
|
|
|
|
InterExplodedGraphMap InverseMap;
|
2013-03-20 08:35:37 +08:00
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
using PriorityMapTy = llvm::DenseMap<const ExplodedNode *, unsigned>;
|
|
|
|
|
2013-03-20 08:35:37 +08:00
|
|
|
PriorityMapTy PriorityMap;
|
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
using NodeIndexPair = std::pair<const ExplodedNode *, size_t>;
|
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
SmallVector<NodeIndexPair, 32> ReportNodes;
|
|
|
|
|
2014-03-08 04:03:18 +08:00
|
|
|
std::unique_ptr<ExplodedGraph> G;
|
2013-03-23 05:15:28 +08:00
|
|
|
|
|
|
|
/// A helper class for sorting ExplodedNodes by priority.
|
|
|
|
template <bool Descending>
|
|
|
|
class PriorityCompare {
|
|
|
|
const PriorityMapTy &PriorityMap;
|
|
|
|
|
|
|
|
public:
|
|
|
|
PriorityCompare(const PriorityMapTy &M) : PriorityMap(M) {}
|
|
|
|
|
|
|
|
bool operator()(const ExplodedNode *LHS, const ExplodedNode *RHS) const {
|
|
|
|
PriorityMapTy::const_iterator LI = PriorityMap.find(LHS);
|
|
|
|
PriorityMapTy::const_iterator RI = PriorityMap.find(RHS);
|
|
|
|
PriorityMapTy::const_iterator E = PriorityMap.end();
|
|
|
|
|
|
|
|
if (LI == E)
|
|
|
|
return Descending;
|
|
|
|
if (RI == E)
|
|
|
|
return !Descending;
|
|
|
|
|
|
|
|
return Descending ? LI->second > RI->second
|
|
|
|
: LI->second < RI->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool operator()(const NodeIndexPair &LHS, const NodeIndexPair &RHS) const {
|
|
|
|
return (*this)(LHS.first, RHS.first);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-03-16 09:07:58 +08:00
|
|
|
public:
|
|
|
|
TrimmedGraph(const ExplodedGraph *OriginalGraph,
|
2013-03-20 08:35:37 +08:00
|
|
|
ArrayRef<const ExplodedNode *> Nodes);
|
2013-03-16 09:07:58 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
bool popNextReportGraph(ReportGraph &GraphWrapper);
|
2013-03-16 09:07:58 +08:00
|
|
|
};
|
2018-03-07 08:17:48 +08:00
|
|
|
|
|
|
|
} // namespace
|
2013-03-16 09:07:58 +08:00
|
|
|
|
2013-03-20 08:35:37 +08:00
|
|
|
TrimmedGraph::TrimmedGraph(const ExplodedGraph *OriginalGraph,
|
|
|
|
ArrayRef<const ExplodedNode *> Nodes) {
|
|
|
|
// The trimmed graph is created in the body of the constructor to ensure
|
|
|
|
// that the DenseMaps have been initialized already.
|
2013-03-23 05:15:28 +08:00
|
|
|
InterExplodedGraphMap ForwardMap;
|
2014-09-05 08:04:19 +08:00
|
|
|
G = OriginalGraph->trim(Nodes, &ForwardMap, &InverseMap);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// Find the (first) error node in the trimmed graph. We just need to consult
|
2013-03-16 09:07:58 +08:00
|
|
|
// the node map which maps from nodes in the original graph to nodes
|
2009-04-01 07:00:32 +08:00
|
|
|
// in the new graph.
|
2013-03-23 05:15:28 +08:00
|
|
|
llvm::SmallPtrSet<const ExplodedNode *, 32> RemainingNodes;
|
2009-04-01 07:00:32 +08:00
|
|
|
|
2013-03-16 09:07:58 +08:00
|
|
|
for (unsigned i = 0, count = Nodes.size(); i < count; ++i) {
|
2013-03-23 05:15:28 +08:00
|
|
|
if (const ExplodedNode *NewNode = ForwardMap.lookup(Nodes[i])) {
|
|
|
|
ReportNodes.push_back(std::make_pair(NewNode, i));
|
|
|
|
RemainingNodes.insert(NewNode);
|
2009-04-01 07:00:32 +08:00
|
|
|
}
|
2010-12-03 14:52:30 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
assert(!RemainingNodes.empty() && "No error node found in the trimmed graph");
|
|
|
|
|
|
|
|
// Perform a forward BFS to find all the shortest paths.
|
|
|
|
std::queue<const ExplodedNode *> WS;
|
|
|
|
|
|
|
|
assert(G->num_roots() == 1);
|
|
|
|
WS.push(*G->roots_begin());
|
|
|
|
unsigned Priority = 0;
|
2009-04-01 07:00:32 +08:00
|
|
|
|
|
|
|
while (!WS.empty()) {
|
2013-03-23 05:15:28 +08:00
|
|
|
const ExplodedNode *Node = WS.front();
|
2009-04-01 07:00:32 +08:00
|
|
|
WS.pop();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-03-20 08:35:37 +08:00
|
|
|
PriorityMapTy::iterator PriorityEntry;
|
|
|
|
bool IsNew;
|
2014-03-02 21:01:17 +08:00
|
|
|
std::tie(PriorityEntry, IsNew) =
|
2013-03-20 08:35:37 +08:00
|
|
|
PriorityMap.insert(std::make_pair(Node, Priority));
|
2013-03-23 05:15:28 +08:00
|
|
|
++Priority;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-03-20 08:35:37 +08:00
|
|
|
if (!IsNew) {
|
|
|
|
assert(PriorityEntry->second <= Priority);
|
|
|
|
continue;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
if (RemainingNodes.erase(Node))
|
|
|
|
if (RemainingNodes.empty())
|
|
|
|
break;
|
2013-03-19 07:34:37 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
for (ExplodedNode::const_pred_iterator I = Node->succ_begin(),
|
|
|
|
E = Node->succ_end();
|
2013-03-20 08:35:37 +08:00
|
|
|
I != E; ++I)
|
2013-03-23 05:15:28 +08:00
|
|
|
WS.push(*I);
|
2013-03-20 06:10:35 +08:00
|
|
|
}
|
2013-03-20 08:35:37 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
// Sort the error paths from longest to shortest.
|
2018-09-27 06:16:28 +08:00
|
|
|
llvm::sort(ReportNodes, PriorityCompare<true>(PriorityMap));
|
2013-03-23 05:15:28 +08:00
|
|
|
}
|
2013-03-20 08:35:37 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
bool TrimmedGraph::popNextReportGraph(ReportGraph &GraphWrapper) {
|
|
|
|
if (ReportNodes.empty())
|
|
|
|
return false;
|
2013-03-20 08:35:37 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
const ExplodedNode *OrigN;
|
2014-03-02 21:01:17 +08:00
|
|
|
std::tie(OrigN, GraphWrapper.Index) = ReportNodes.pop_back_val();
|
2013-03-23 05:15:28 +08:00
|
|
|
assert(PriorityMap.find(OrigN) != PriorityMap.end() &&
|
|
|
|
"error node not accessible from root");
|
2013-03-20 08:35:37 +08:00
|
|
|
|
|
|
|
// Create a new graph with a single path. This is the graph
|
|
|
|
// that will be returned to the caller.
|
2014-09-05 08:11:25 +08:00
|
|
|
auto GNew = llvm::make_unique<ExplodedGraph>();
|
2013-03-23 05:15:28 +08:00
|
|
|
GraphWrapper.BackMap.clear();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
// Now walk from the error node up the BFS path, always taking the
|
|
|
|
// predeccessor with the lowest number.
|
2014-05-27 10:45:47 +08:00
|
|
|
ExplodedNode *Succ = nullptr;
|
2013-03-23 05:15:28 +08:00
|
|
|
while (true) {
|
2009-04-01 07:00:32 +08:00
|
|
|
// Create the equivalent node in the new graph with the same state
|
|
|
|
// and location.
|
2016-06-23 23:47:12 +08:00
|
|
|
ExplodedNode *NewN = GNew->createUncachedNode(OrigN->getLocation(), OrigN->getState(),
|
2013-04-06 09:42:02 +08:00
|
|
|
OrigN->isSink());
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// Store the mapping to the original node.
|
2013-03-23 05:15:28 +08:00
|
|
|
InterExplodedGraphMap::const_iterator IMitr = InverseMap.find(OrigN);
|
2009-04-01 07:00:32 +08:00
|
|
|
assert(IMitr != InverseMap.end() && "No mapping to original node.");
|
2013-03-16 09:07:58 +08:00
|
|
|
GraphWrapper.BackMap[NewN] = IMitr->second;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// Link up the new node with the previous node.
|
2013-03-23 05:15:28 +08:00
|
|
|
if (Succ)
|
|
|
|
Succ->addPredecessor(NewN, *GNew);
|
|
|
|
else
|
|
|
|
GraphWrapper.ErrorNode = NewN;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
Succ = NewN;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// Are we at the final node?
|
2013-03-23 05:15:28 +08:00
|
|
|
if (OrigN->pred_empty()) {
|
|
|
|
GNew->addRoot(NewN);
|
2009-04-01 07:00:32 +08:00
|
|
|
break;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
// Find the next predeccessor node. We choose the node that is marked
|
2013-03-20 08:35:37 +08:00
|
|
|
// with the lowest BFS number.
|
2013-03-23 05:15:28 +08:00
|
|
|
OrigN = *std::min_element(OrigN->pred_begin(), OrigN->pred_end(),
|
|
|
|
PriorityCompare<false>(PriorityMap));
|
2013-03-20 08:35:37 +08:00
|
|
|
}
|
|
|
|
|
2014-09-05 08:11:25 +08:00
|
|
|
GraphWrapper.Graph = std::move(GNew);
|
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
return true;
|
2013-03-20 08:35:37 +08:00
|
|
|
}
|
|
|
|
|
2018-10-31 22:54:27 +08:00
|
|
|
/// CompactMacroExpandedPieces - This function postprocesses a PathDiagnostic
|
|
|
|
/// object and collapses PathDiagosticPieces that are expanded by macros.
|
|
|
|
static void CompactMacroExpandedPieces(PathPieces &path,
|
|
|
|
const SourceManager& SM) {
|
2018-03-07 08:17:48 +08:00
|
|
|
using MacroStackTy =
|
|
|
|
std::vector<
|
|
|
|
std::pair<std::shared_ptr<PathDiagnosticMacroPiece>, SourceLocation>>;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2018-03-07 08:17:48 +08:00
|
|
|
using PiecesTy = std::vector<std::shared_ptr<PathDiagnosticPiece>>;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
MacroStackTy MacroStack;
|
|
|
|
PiecesTy Pieces;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2013-04-30 07:12:59 +08:00
|
|
|
for (PathPieces::const_iterator I = path.begin(), E = path.end();
|
2018-03-07 08:17:48 +08:00
|
|
|
I != E; ++I) {
|
|
|
|
const auto &piece = *I;
|
2012-03-02 09:27:31 +08:00
|
|
|
|
|
|
|
// Recursively compact calls.
|
2017-01-06 01:26:53 +08:00
|
|
|
if (auto *call = dyn_cast<PathDiagnosticCallPiece>(&*piece)) {
|
2018-10-31 22:54:27 +08:00
|
|
|
CompactMacroExpandedPieces(call->path, SM);
|
2012-03-02 09:27:31 +08:00
|
|
|
}
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// Get the location of the PathDiagnosticPiece.
|
2012-03-02 09:27:31 +08:00
|
|
|
const FullSourceLoc Loc = piece->getLocation().asLocation();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// Determine the instantiation location, which is the location we group
|
|
|
|
// related PathDiagnosticPieces.
|
2009-09-09 23:08:12 +08:00
|
|
|
SourceLocation InstantiationLoc = Loc.isMacroID() ?
|
2011-07-26 00:49:02 +08:00
|
|
|
SM.getExpansionLoc(Loc) :
|
2009-04-01 07:00:32 +08:00
|
|
|
SourceLocation();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
if (Loc.isFileID()) {
|
|
|
|
MacroStack.clear();
|
2012-03-02 09:27:31 +08:00
|
|
|
Pieces.push_back(piece);
|
2009-04-01 07:00:32 +08:00
|
|
|
continue;
|
|
|
|
}
|
2008-04-08 07:35:17 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
assert(Loc.isMacroID());
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// Is the PathDiagnosticPiece within the same macro group?
|
|
|
|
if (!MacroStack.empty() && InstantiationLoc == MacroStack.back().second) {
|
2012-03-02 09:27:31 +08:00
|
|
|
MacroStack.back().first->subPieces.push_back(piece);
|
2009-04-01 07:00:32 +08:00
|
|
|
continue;
|
|
|
|
}
|
2009-03-28 05:16:25 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// We aren't in the same group. Are we descending into a new macro
|
|
|
|
// or are part of an old one?
|
2017-01-06 01:26:53 +08:00
|
|
|
std::shared_ptr<PathDiagnosticMacroPiece> MacroGroup;
|
2009-03-28 05:16:25 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
SourceLocation ParentInstantiationLoc = InstantiationLoc.isMacroID() ?
|
2011-07-26 00:49:02 +08:00
|
|
|
SM.getExpansionLoc(Loc) :
|
2009-04-01 07:00:32 +08:00
|
|
|
SourceLocation();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// Walk the entire macro stack.
|
|
|
|
while (!MacroStack.empty()) {
|
|
|
|
if (InstantiationLoc == MacroStack.back().second) {
|
|
|
|
MacroGroup = MacroStack.back().first;
|
|
|
|
break;
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
if (ParentInstantiationLoc == MacroStack.back().second) {
|
|
|
|
MacroGroup = MacroStack.back().first;
|
|
|
|
break;
|
2008-04-03 12:42:52 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
MacroStack.pop_back();
|
2008-04-09 08:20:43 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
if (!MacroGroup || ParentInstantiationLoc == MacroStack.back().second) {
|
|
|
|
// Create a new macro group and add it to the stack.
|
2017-01-06 01:26:53 +08:00
|
|
|
auto NewGroup = std::make_shared<PathDiagnosticMacroPiece>(
|
2012-03-02 09:27:31 +08:00
|
|
|
PathDiagnosticLocation::createSingleLocation(piece->getLocation()));
|
2008-04-24 07:35:07 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
if (MacroGroup)
|
2012-02-08 12:32:34 +08:00
|
|
|
MacroGroup->subPieces.push_back(NewGroup);
|
2009-04-01 07:00:32 +08:00
|
|
|
else {
|
|
|
|
assert(InstantiationLoc.isFileID());
|
|
|
|
Pieces.push_back(NewGroup);
|
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
MacroGroup = NewGroup;
|
|
|
|
MacroStack.push_back(std::make_pair(MacroGroup, InstantiationLoc));
|
2009-04-01 04:22:36 +08:00
|
|
|
}
|
2009-04-01 07:00:32 +08:00
|
|
|
|
|
|
|
// Finally, add the PathDiagnosticPiece to the group.
|
2012-03-02 09:27:31 +08:00
|
|
|
MacroGroup->subPieces.push_back(piece);
|
2009-04-01 07:00:32 +08:00
|
|
|
}
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-04-01 07:00:32 +08:00
|
|
|
// Now take the pieces and construct a new PathDiagnostic.
|
2012-03-02 09:27:31 +08:00
|
|
|
path.clear();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2015-02-18 00:48:30 +08:00
|
|
|
path.insert(path.end(), Pieces.begin(), Pieces.end());
|
2008-04-03 12:42:52 +08:00
|
|
|
}
|
|
|
|
|
[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
|
|
|
/// Generate notes from all visitors.
|
|
|
|
/// Notes associated with {@code ErrorNode} are generated using
|
|
|
|
/// {@code getEndPath}, and the rest are generated with {@code VisitNode}.
|
|
|
|
static std::unique_ptr<VisitorsDiagnosticsTy>
|
|
|
|
generateVisitorsDiagnostics(BugReport *R, const ExplodedNode *ErrorNode,
|
|
|
|
BugReporterContext &BRC) {
|
|
|
|
auto Notes = llvm::make_unique<VisitorsDiagnosticsTy>();
|
|
|
|
BugReport::VisitorList visitors;
|
2012-09-22 09:24:53 +08:00
|
|
|
|
[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
|
|
|
// Run visitors on all nodes starting from the node *before* the last one.
|
|
|
|
// The last node is reserved for notes generated with {@code getEndPath}.
|
|
|
|
const ExplodedNode *NextNode = ErrorNode->getFirstPred();
|
|
|
|
while (NextNode) {
|
|
|
|
|
|
|
|
// At each iteration, move all visitors from report to visitor list.
|
|
|
|
for (BugReport::visitor_iterator I = R->visitor_begin(),
|
|
|
|
E = R->visitor_end();
|
|
|
|
I != E; ++I) {
|
|
|
|
visitors.push_back(std::move(*I));
|
2013-03-16 09:07:47 +08:00
|
|
|
}
|
[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
|
|
|
R->clearVisitors();
|
2009-09-09 23:08:12 +08:00
|
|
|
|
[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
|
|
|
const ExplodedNode *Pred = NextNode->getFirstPred();
|
|
|
|
if (!Pred) {
|
|
|
|
std::shared_ptr<PathDiagnosticPiece> LastPiece;
|
|
|
|
for (auto &V : visitors) {
|
|
|
|
V->finalizeVisitor(BRC, ErrorNode, *R);
|
2013-03-16 09:07:47 +08:00
|
|
|
|
[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
|
|
|
if (auto Piece = V->getEndPath(BRC, ErrorNode, *R)) {
|
|
|
|
assert(!LastPiece &&
|
|
|
|
"There can only be one final piece in a diagnostic.");
|
|
|
|
LastPiece = std::move(Piece);
|
|
|
|
(*Notes)[ErrorNode].push_back(LastPiece);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2018-03-07 08:17:48 +08:00
|
|
|
|
[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
|
|
|
for (auto &V : visitors) {
|
2018-09-29 02:49:41 +08:00
|
|
|
auto P = V->VisitNode(NextNode, BRC, *R);
|
[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
|
|
|
if (P)
|
|
|
|
(*Notes)[NextNode].push_back(std::move(P));
|
|
|
|
}
|
2013-03-16 05:41:55 +08:00
|
|
|
|
[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
|
|
|
if (!R->isValid())
|
|
|
|
break;
|
|
|
|
|
|
|
|
NextNode = Pred;
|
|
|
|
}
|
|
|
|
|
|
|
|
return Notes;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Find a non-invalidated report for a given equivalence class,
|
|
|
|
/// and return together with a cache of visitors notes.
|
|
|
|
/// If none found, return a nullptr paired with an empty cache.
|
|
|
|
static
|
|
|
|
std::pair<BugReport*, std::unique_ptr<VisitorsDiagnosticsTy>> findValidReport(
|
|
|
|
TrimmedGraph &TrimG,
|
|
|
|
ReportGraph &ErrorGraph,
|
|
|
|
ArrayRef<BugReport *> &bugReports,
|
|
|
|
AnalyzerOptions &Opts,
|
|
|
|
GRBugReporter &Reporter) {
|
2013-03-16 09:07:58 +08:00
|
|
|
|
2013-03-23 05:15:28 +08:00
|
|
|
while (TrimG.popNextReportGraph(ErrorGraph)) {
|
2013-03-16 05:41:55 +08:00
|
|
|
// Find the BugReport with the original location.
|
2013-03-16 09:07:58 +08:00
|
|
|
assert(ErrorGraph.Index < bugReports.size());
|
|
|
|
BugReport *R = bugReports[ErrorGraph.Index];
|
2013-03-16 05:41:55 +08:00
|
|
|
assert(R && "No original report found for sliced graph.");
|
|
|
|
assert(R->isValid() && "Report selected by trimmed graph marked invalid.");
|
[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
|
|
|
const ExplodedNode *ErrorNode = ErrorGraph.ErrorNode;
|
2013-03-16 05:41:55 +08:00
|
|
|
|
[analyzer] False positive refutation with Z3
Summary: This is a prototype of a bug reporter visitor that invalidates bug reports by re-checking constraints of certain states on the bug path using the Z3 constraint manager backend. The functionality is available under the `crosscheck-with-z3` analyzer config flag.
Reviewers: george.karpenkov, NoQ, dcoughlin, rnkovacs
Reviewed By: george.karpenkov
Subscribers: rnkovacs, NoQ, george.karpenkov, dcoughlin, xbolva00, ddcc, mikhail.ramalho, MTC, fhahn, whisperity, baloghadamsoftware, szepet, a.sidorin, gsd, dkrupp, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D45517
llvm-svn: 333903
2018-06-04 22:40:44 +08:00
|
|
|
// Register refutation visitors first, if they mark the bug invalid no
|
|
|
|
// further analysis is required
|
|
|
|
R->addVisitor(llvm::make_unique<LikelyFalsePositiveSuppressionBRVisitor>());
|
|
|
|
|
2013-03-16 05:41:55 +08:00
|
|
|
// Register additional node visitors.
|
2014-09-05 07:54:33 +08:00
|
|
|
R->addVisitor(llvm::make_unique<NilReceiverBRVisitor>());
|
|
|
|
R->addVisitor(llvm::make_unique<ConditionBRVisitor>());
|
2019-04-20 04:23:29 +08:00
|
|
|
R->addVisitor(llvm::make_unique<TagVisitor>());
|
2013-03-16 05:41:55 +08:00
|
|
|
|
[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
|
|
|
BugReporterContext BRC(Reporter, ErrorGraph.BackMap);
|
2013-01-31 03:12:34 +08:00
|
|
|
|
[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
|
|
|
// Run all visitors on a given graph, once.
|
|
|
|
std::unique_ptr<VisitorsDiagnosticsTy> visitorNotes =
|
|
|
|
generateVisitorsDiagnostics(R, ErrorNode, BRC);
|
2012-03-24 11:03:29 +08:00
|
|
|
|
2018-07-25 20:49:32 +08:00
|
|
|
if (R->isValid()) {
|
[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
|
|
|
if (Opts.ShouldCrosscheckWithZ3) {
|
2018-07-25 20:49:32 +08:00
|
|
|
// If crosscheck is enabled, remove all visitors, add the refutation
|
|
|
|
// visitor and check again
|
|
|
|
R->clearVisitors();
|
|
|
|
R->addVisitor(llvm::make_unique<FalsePositiveRefutationBRVisitor>());
|
|
|
|
|
|
|
|
// We don't overrite the notes inserted by other visitors because the
|
|
|
|
// refutation manager does not add any new note to the path
|
|
|
|
generateVisitorsDiagnostics(R, ErrorGraph.ErrorNode, BRC);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check if the bug is still valid
|
|
|
|
if (R->isValid())
|
|
|
|
return std::make_pair(R, std::move(visitorNotes));
|
|
|
|
}
|
[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
|
|
|
}
|
2018-07-25 20:49:32 +08:00
|
|
|
|
[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
|
|
|
return std::make_pair(nullptr, llvm::make_unique<VisitorsDiagnosticsTy>());
|
|
|
|
}
|
2013-03-16 05:41:55 +08:00
|
|
|
|
[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
|
|
|
std::unique_ptr<DiagnosticForConsumerMapTy>
|
|
|
|
GRBugReporter::generatePathDiagnostics(
|
|
|
|
ArrayRef<PathDiagnosticConsumer *> consumers,
|
|
|
|
ArrayRef<BugReport *> &bugReports) {
|
|
|
|
assert(!bugReports.empty());
|
2013-06-07 06:02:58 +08:00
|
|
|
|
[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
|
|
|
auto Out = llvm::make_unique<DiagnosticForConsumerMapTy>();
|
|
|
|
bool HasValid = false;
|
|
|
|
SmallVector<const ExplodedNode *, 32> errorNodes;
|
|
|
|
for (const auto I : bugReports) {
|
|
|
|
if (I->isValid()) {
|
|
|
|
HasValid = true;
|
|
|
|
errorNodes.push_back(I->getErrorNode());
|
|
|
|
} else {
|
|
|
|
// Keep the errorNodes list in sync with the bugReports list.
|
|
|
|
errorNodes.push_back(nullptr);
|
|
|
|
}
|
|
|
|
}
|
2013-05-08 09:15:24 +08:00
|
|
|
|
[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
|
|
|
// If all the reports have been marked invalid by a previous path generation,
|
|
|
|
// we're done.
|
|
|
|
if (!HasValid)
|
|
|
|
return Out;
|
2013-05-08 09:15:24 +08:00
|
|
|
|
[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
|
|
|
TrimmedGraph TrimG(&getGraph(), errorNodes);
|
|
|
|
ReportGraph ErrorGraph;
|
|
|
|
auto ReportInfo = findValidReport(TrimG, ErrorGraph, bugReports,
|
|
|
|
getAnalyzerOptions(), *this);
|
|
|
|
BugReport *R = ReportInfo.first;
|
2013-06-06 08:12:37 +08:00
|
|
|
|
[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
|
|
|
if (R && R->isValid()) {
|
|
|
|
const ExplodedNode *ErrorNode = ErrorGraph.ErrorNode;
|
|
|
|
for (PathDiagnosticConsumer *PC : consumers) {
|
|
|
|
PathDiagnosticBuilder PDB(*this, R, ErrorGraph.BackMap, PC);
|
|
|
|
std::unique_ptr<PathDiagnostic> PD = generatePathDiagnosticForConsumer(
|
|
|
|
PC->getGenerationScheme(), PDB, ErrorNode, *ReportInfo.second);
|
|
|
|
(*Out)[PC] = std::move(PD);
|
2012-10-26 06:07:10 +08:00
|
|
|
}
|
2012-05-31 14:03:17 +08:00
|
|
|
}
|
2012-09-22 09:24:53 +08:00
|
|
|
|
[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
|
|
|
return Out;
|
2009-04-01 07:00:32 +08:00
|
|
|
}
|
2008-05-23 07:45:19 +08:00
|
|
|
|
2019-01-19 03:24:55 +08:00
|
|
|
void BugReporter::Register(const BugType *BT) {
|
2010-11-24 08:54:37 +08:00
|
|
|
BugTypes = F.add(BugTypes, BT);
|
2008-05-17 02:33:14 +08:00
|
|
|
}
|
|
|
|
|
2015-06-23 21:15:32 +08:00
|
|
|
void BugReporter::emitReport(std::unique_ptr<BugReport> R) {
|
2013-08-02 06:16:30 +08:00
|
|
|
if (const ExplodedNode *E = R->getErrorNode()) {
|
2015-09-17 06:03:05 +08:00
|
|
|
// An error node must either be a sink or have a tag, otherwise
|
|
|
|
// it could get reclaimed before the path diagnostic is created.
|
|
|
|
assert((E->isSink() || E->getLocation().getTag()) &&
|
|
|
|
"Error node must either be a sink or have a tag");
|
|
|
|
|
Add support for the static analyzer to synthesize function implementations from external model files.
Currently the analyzer lazily models some functions using 'BodyFarm',
which constructs a fake function implementation that the analyzer
can simulate that approximates the semantics of the function when
it is called. BodyFarm does this by constructing the AST for
such definitions on-the-fly. One strength of BodyFarm
is that all symbols and types referenced by synthesized function
bodies are contextual adapted to the containing translation unit.
The downside is that these ASTs are hardcoded in Clang's own
source code.
A more scalable model is to allow these models to be defined as source
code in separate "model" files and have the analyzer use those
definitions lazily when a function body is needed. Among other things,
it will allow more customization of the analyzer for specific APIs
and platforms.
This patch provides the initial infrastructure for this feature.
It extends BodyFarm to use an abstract API 'CodeInjector' that can be
used to synthesize function bodies. That 'CodeInjector' is
implemented using a new 'ModelInjector' in libFrontend, which lazily
parses a model file and injects the ASTs into the current translation
unit.
Models are currently found by specifying a 'model-path' as an
analyzer option; if no path is specified the CodeInjector is not
used, thus defaulting to the current behavior in the analyzer.
Models currently contain a single function definition, and can
be found by finding the file <function name>.model. This is an
initial starting point for something more rich, but it bootstraps
this feature for future evolution.
This patch was contributed by Gábor Horváth as part of his
Google Summer of Code project.
Some notes:
- This introduces the notion of a "model file" into
FrontendAction and the Preprocessor. This nomenclature
is specific to the static analyzer, but possibly could be
generalized. Essentially these are sources pulled in
exogenously from the principal translation.
Preprocessor gets a 'InitializeForModelFile' and
'FinalizeForModelFile' which could possibly be hoisted out
of Preprocessor if Preprocessor exposed a new API to
change the PragmaHandlers and some other internal pieces. This
can be revisited.
FrontendAction gets a 'isModelParsingAction()' predicate function
used to allow a new FrontendAction to recycle the Preprocessor
and ASTContext. This name could probably be made something
more general (i.e., not tied to 'model files') at the expense
of losing the intent of why it exists. This can be revisited.
- This is a moderate sized patch; it has gone through some amount of
offline code review. Most of the changes to the non-analyzer
parts are fairly small, and would make little sense without
the analyzer changes.
- Most of the analyzer changes are plumbing, with the interesting
behavior being introduced by ModelInjector.cpp and
ModelConsumer.cpp.
- The new functionality introduced by this change is off-by-default.
It requires an analyzer config option to enable.
llvm-svn: 216550
2014-08-27 23:14:15 +08:00
|
|
|
const AnalysisDeclContext *DeclCtx =
|
|
|
|
E->getLocationContext()->getAnalysisDeclContext();
|
|
|
|
// The source of autosynthesized body can be handcrafted AST or a model
|
|
|
|
// file. The locations from handcrafted ASTs have no valid source locations
|
|
|
|
// and have to be discarded. Locations from model files should be preserved
|
|
|
|
// for processing and reporting.
|
|
|
|
if (DeclCtx->isBodyAutosynthesized() &&
|
|
|
|
!DeclCtx->isBodyAutosynthesizedFromModelFile())
|
2013-08-02 06:16:30 +08:00
|
|
|
return;
|
|
|
|
}
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2013-08-02 06:16:30 +08:00
|
|
|
bool ValidSourceLoc = R->getLocation(getSourceManager()).isValid();
|
|
|
|
assert(ValidSourceLoc);
|
|
|
|
// If we mess up in a release build, we'd still prefer to just drop the bug
|
|
|
|
// instead of trying to go on.
|
|
|
|
if (!ValidSourceLoc)
|
|
|
|
return;
|
|
|
|
|
2009-02-05 07:49:09 +08:00
|
|
|
// Compute the bug report's hash to determine its equivalence class.
|
|
|
|
llvm::FoldingSetNodeID ID;
|
|
|
|
R->Profile(ID);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
|
|
|
// Lookup the equivance class. If there isn't one, create it.
|
2019-01-19 03:24:55 +08:00
|
|
|
const BugType& BT = R->getBugType();
|
2009-02-05 07:49:09 +08:00
|
|
|
Register(&BT);
|
|
|
|
void *InsertPos;
|
2011-02-23 08:16:01 +08:00
|
|
|
BugReportEquivClass* EQ = EQClasses.FindNodeOrInsertPos(ID, InsertPos);
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-02-05 07:49:09 +08:00
|
|
|
if (!EQ) {
|
2015-06-23 21:15:32 +08:00
|
|
|
EQ = new BugReportEquivClass(std::move(R));
|
2011-02-23 08:16:01 +08:00
|
|
|
EQClasses.InsertNode(EQ, InsertPos);
|
2011-08-19 09:57:09 +08:00
|
|
|
EQClassesVector.push_back(EQ);
|
2014-08-30 03:57:52 +08:00
|
|
|
} else
|
2015-06-23 21:15:32 +08:00
|
|
|
EQ->AddReport(std::move(R));
|
2008-04-03 12:42:52 +08:00
|
|
|
}
|
|
|
|
|
2009-09-15 06:01:32 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Emitting reports in equivalence classes.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
namespace {
|
2018-03-07 08:17:48 +08:00
|
|
|
|
2009-11-28 14:07:30 +08:00
|
|
|
struct FRIEC_WLItem {
|
2009-09-15 06:01:32 +08:00
|
|
|
const ExplodedNode *N;
|
|
|
|
ExplodedNode::const_succ_iterator I, E;
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2009-09-15 06:01:32 +08:00
|
|
|
FRIEC_WLItem(const ExplodedNode *n)
|
2018-03-07 08:17:48 +08:00
|
|
|
: N(n), I(N->succ_begin()), E(N->succ_end()) {}
|
2015-09-08 11:50:52 +08:00
|
|
|
};
|
2018-03-07 08:17:48 +08:00
|
|
|
|
|
|
|
} // namespace
|
2009-09-15 06:01:32 +08:00
|
|
|
|
2016-12-22 22:48:52 +08:00
|
|
|
static const CFGBlock *findBlockForNode(const ExplodedNode *N) {
|
|
|
|
ProgramPoint P = N->getLocation();
|
|
|
|
if (auto BEP = P.getAs<BlockEntrance>())
|
|
|
|
return BEP->getBlock();
|
|
|
|
|
|
|
|
// Find the node's current statement in the CFG.
|
|
|
|
if (const Stmt *S = PathDiagnosticLocation::getStmt(N))
|
|
|
|
return N->getLocationContext()->getAnalysisDeclContext()
|
|
|
|
->getCFGStmtMap()->getBlock(S);
|
|
|
|
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2017-08-14 16:38:47 +08:00
|
|
|
// Returns true if by simply looking at the block, we can be sure that it
|
|
|
|
// results in a sink during analysis. This is useful to know when the analysis
|
|
|
|
// was interrupted, and we try to figure out if it would sink eventually.
|
|
|
|
// There may be many more reasons why a sink would appear during analysis
|
|
|
|
// (eg. checkers may generate sinks arbitrarily), but here we only consider
|
|
|
|
// sinks that would be obvious by looking at the CFG.
|
|
|
|
static bool isImmediateSinkBlock(const CFGBlock *Blk) {
|
2017-07-25 17:44:02 +08:00
|
|
|
if (Blk->hasNoReturnElement())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// FIXME: Throw-expressions are currently generating sinks during analysis:
|
|
|
|
// they're not supported yet, and also often used for actually terminating
|
|
|
|
// the program. So we should treat them as sinks in this analysis as well,
|
|
|
|
// at least for now, but once we have better support for exceptions,
|
|
|
|
// we'd need to carefully handle the case when the throw is being
|
|
|
|
// immediately caught.
|
|
|
|
if (std::any_of(Blk->begin(), Blk->end(), [](const CFGElement &Elm) {
|
|
|
|
if (Optional<CFGStmt> StmtElm = Elm.getAs<CFGStmt>())
|
|
|
|
if (isa<CXXThrowExpr>(StmtElm->getStmt()))
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-08-14 16:38:47 +08:00
|
|
|
// Returns true if by looking at the CFG surrounding the node's program
|
|
|
|
// point, we can be sure that any analysis starting from this point would
|
|
|
|
// eventually end with a sink. We scan the child CFG blocks in a depth-first
|
|
|
|
// manner and see if all paths eventually end up in an immediate sink block.
|
|
|
|
static bool isInevitablySinking(const ExplodedNode *N) {
|
2017-07-25 17:25:10 +08:00
|
|
|
const CFG &Cfg = N->getCFG();
|
|
|
|
|
|
|
|
const CFGBlock *StartBlk = findBlockForNode(N);
|
|
|
|
if (!StartBlk)
|
|
|
|
return false;
|
2017-08-14 16:38:47 +08:00
|
|
|
if (isImmediateSinkBlock(StartBlk))
|
2017-07-25 17:25:10 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
llvm::SmallVector<const CFGBlock *, 32> DFSWorkList;
|
|
|
|
llvm::SmallPtrSet<const CFGBlock *, 32> Visited;
|
|
|
|
|
|
|
|
DFSWorkList.push_back(StartBlk);
|
|
|
|
while (!DFSWorkList.empty()) {
|
|
|
|
const CFGBlock *Blk = DFSWorkList.back();
|
|
|
|
DFSWorkList.pop_back();
|
|
|
|
Visited.insert(Blk);
|
|
|
|
|
2018-09-22 04:36:01 +08:00
|
|
|
// If at least one path reaches the CFG exit, it means that control is
|
|
|
|
// returned to the caller. For now, say that we are not sure what
|
|
|
|
// happens next. If necessary, this can be improved to analyze
|
|
|
|
// the parent StackFrameContext's call site in a similar manner.
|
|
|
|
if (Blk == &Cfg.getExit())
|
|
|
|
return false;
|
|
|
|
|
2017-07-25 17:25:10 +08:00
|
|
|
for (const auto &Succ : Blk->succs()) {
|
|
|
|
if (const CFGBlock *SuccBlk = Succ.getReachableBlock()) {
|
2017-08-14 16:38:47 +08:00
|
|
|
if (!isImmediateSinkBlock(SuccBlk) && !Visited.count(SuccBlk)) {
|
2017-07-25 17:25:10 +08:00
|
|
|
// If the block has reachable child blocks that aren't no-return,
|
|
|
|
// add them to the worklist.
|
|
|
|
DFSWorkList.push_back(SuccBlk);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Nothing reached the exit. It can only mean one thing: there's no return.
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2010-09-10 03:05:34 +08:00
|
|
|
static BugReport *
|
|
|
|
FindReportInEquivalenceClass(BugReportEquivClass& EQ,
|
2011-07-23 18:55:15 +08:00
|
|
|
SmallVectorImpl<BugReport*> &bugReports) {
|
2009-09-15 06:01:32 +08:00
|
|
|
BugReportEquivClass::iterator I = EQ.begin(), E = EQ.end();
|
|
|
|
assert(I != E);
|
2019-01-19 03:24:55 +08:00
|
|
|
const BugType& BT = I->getBugType();
|
2010-09-10 03:05:34 +08:00
|
|
|
|
2010-12-03 14:52:30 +08:00
|
|
|
// If we don't need to suppress any of the nodes because they are
|
|
|
|
// post-dominated by a sink, simply add all the nodes in the equivalence class
|
|
|
|
// to 'Nodes'. Any of the reports will serve as a "representative" report.
|
2010-09-10 03:05:34 +08:00
|
|
|
if (!BT.isSuppressOnSink()) {
|
2015-11-07 07:04:58 +08:00
|
|
|
BugReport *R = &*I;
|
2018-03-07 08:17:48 +08:00
|
|
|
for (auto &I : EQ) {
|
|
|
|
const ExplodedNode *N = I.getErrorNode();
|
2010-09-10 03:05:34 +08:00
|
|
|
if (N) {
|
2018-03-07 08:17:48 +08:00
|
|
|
R = &I;
|
2010-12-03 14:52:30 +08:00
|
|
|
bugReports.push_back(R);
|
2010-09-10 03:05:34 +08:00
|
|
|
}
|
|
|
|
}
|
2009-09-15 06:01:32 +08:00
|
|
|
return R;
|
2010-09-10 03:05:34 +08:00
|
|
|
}
|
|
|
|
|
2009-09-15 06:01:32 +08:00
|
|
|
// For bug reports that should be suppressed when all paths are post-dominated
|
|
|
|
// by a sink node, iterate through the reports in the equivalence class
|
|
|
|
// until we find one that isn't post-dominated (if one exists). We use a
|
|
|
|
// DFS traversal of the ExplodedGraph to find a non-sink node. We could write
|
|
|
|
// this as a recursive function, but we don't want to risk blowing out the
|
|
|
|
// stack for very long paths.
|
2014-05-27 10:45:47 +08:00
|
|
|
BugReport *exampleReport = nullptr;
|
2010-09-10 03:05:34 +08:00
|
|
|
|
2009-09-15 06:01:32 +08:00
|
|
|
for (; I != E; ++I) {
|
2012-04-02 03:30:51 +08:00
|
|
|
const ExplodedNode *errorNode = I->getErrorNode();
|
2009-09-15 06:01:32 +08:00
|
|
|
|
2010-12-03 14:52:30 +08:00
|
|
|
if (!errorNode)
|
2009-09-15 06:01:32 +08:00
|
|
|
continue;
|
2010-12-03 14:52:30 +08:00
|
|
|
if (errorNode->isSink()) {
|
2011-09-23 13:06:16 +08:00
|
|
|
llvm_unreachable(
|
2009-09-15 06:01:32 +08:00
|
|
|
"BugType::isSuppressSink() should not be 'true' for sink end nodes");
|
|
|
|
}
|
2010-09-10 03:05:34 +08:00
|
|
|
// No successors? By definition this nodes isn't post-dominated by a sink.
|
2010-12-03 14:52:30 +08:00
|
|
|
if (errorNode->succ_empty()) {
|
2015-11-07 07:04:58 +08:00
|
|
|
bugReports.push_back(&*I);
|
2010-12-03 14:52:30 +08:00
|
|
|
if (!exampleReport)
|
2015-11-07 07:04:58 +08:00
|
|
|
exampleReport = &*I;
|
2010-09-10 03:05:34 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-12-22 22:48:52 +08:00
|
|
|
// See if we are in a no-return CFG block. If so, treat this similarly
|
|
|
|
// to being post-dominated by a sink. This works better when the analysis
|
2017-08-14 16:38:47 +08:00
|
|
|
// is incomplete and we have never reached the no-return function call(s)
|
|
|
|
// that we'd inevitably bump into on this path.
|
|
|
|
if (isInevitablySinking(errorNode))
|
2017-07-25 17:25:10 +08:00
|
|
|
continue;
|
2016-12-22 22:48:52 +08:00
|
|
|
|
2009-09-15 06:01:32 +08:00
|
|
|
// At this point we know that 'N' is not a sink and it has at least one
|
2015-09-08 11:50:52 +08:00
|
|
|
// successor. Use a DFS worklist to find a non-sink end-of-path node.
|
2018-03-07 08:17:48 +08:00
|
|
|
using WLItem = FRIEC_WLItem;
|
|
|
|
using DFSWorkList = SmallVector<WLItem, 10>;
|
|
|
|
|
2009-09-15 06:01:32 +08:00
|
|
|
llvm::DenseMap<const ExplodedNode *, unsigned> Visited;
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2009-09-15 06:01:32 +08:00
|
|
|
DFSWorkList WL;
|
2010-12-03 14:52:30 +08:00
|
|
|
WL.push_back(errorNode);
|
|
|
|
Visited[errorNode] = 1;
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2009-09-15 06:01:32 +08:00
|
|
|
while (!WL.empty()) {
|
|
|
|
WLItem &WI = WL.back();
|
|
|
|
assert(!WI.N->succ_empty());
|
2015-09-08 11:50:52 +08:00
|
|
|
|
2009-09-15 06:01:32 +08:00
|
|
|
for (; WI.I != WI.E; ++WI.I) {
|
2015-09-08 11:50:52 +08:00
|
|
|
const ExplodedNode *Succ = *WI.I;
|
2009-09-15 06:01:32 +08:00
|
|
|
// End-of-path node?
|
|
|
|
if (Succ->succ_empty()) {
|
2010-09-10 03:05:34 +08:00
|
|
|
// If we found an end-of-path node that is not a sink.
|
|
|
|
if (!Succ->isSink()) {
|
2015-11-07 07:04:58 +08:00
|
|
|
bugReports.push_back(&*I);
|
2010-12-03 14:52:30 +08:00
|
|
|
if (!exampleReport)
|
2015-11-07 07:04:58 +08:00
|
|
|
exampleReport = &*I;
|
2010-09-10 03:05:34 +08:00
|
|
|
WL.clear();
|
|
|
|
break;
|
|
|
|
}
|
2009-09-15 06:01:32 +08:00
|
|
|
// Found a sink? Continue on to the next successor.
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// Mark the successor as visited. If it hasn't been explored,
|
|
|
|
// enqueue it to the DFS worklist.
|
|
|
|
unsigned &mark = Visited[Succ];
|
|
|
|
if (!mark) {
|
|
|
|
mark = 1;
|
|
|
|
WL.push_back(Succ);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2010-09-10 03:05:34 +08:00
|
|
|
|
|
|
|
// The worklist may have been cleared at this point. First
|
|
|
|
// check if it is empty before checking the last item.
|
|
|
|
if (!WL.empty() && &WL.back() == &WI)
|
2009-09-15 06:01:32 +08:00
|
|
|
WL.pop_back();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-09-10 03:05:34 +08:00
|
|
|
// ExampleReport will be NULL if all the nodes in the equivalence class
|
|
|
|
// were post-dominated by sinks.
|
2010-12-03 14:52:30 +08:00
|
|
|
return exampleReport;
|
2010-09-10 03:05:34 +08:00
|
|
|
}
|
2009-09-19 06:37:37 +08:00
|
|
|
|
2009-02-05 07:49:09 +08:00
|
|
|
void BugReporter::FlushReport(BugReportEquivClass& EQ) {
|
2011-07-23 18:55:15 +08:00
|
|
|
SmallVector<BugReport*, 10> bugReports;
|
[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
|
|
|
BugReport *report = FindReportInEquivalenceClass(EQ, bugReports);
|
|
|
|
if (!report)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ArrayRef<PathDiagnosticConsumer*> Consumers = getPathDiagnosticConsumers();
|
|
|
|
std::unique_ptr<DiagnosticForConsumerMapTy> Diagnostics =
|
|
|
|
generateDiagnosticForConsumerMap(report, Consumers, bugReports);
|
|
|
|
|
|
|
|
for (auto &P : *Diagnostics) {
|
|
|
|
PathDiagnosticConsumer *Consumer = P.first;
|
|
|
|
std::unique_ptr<PathDiagnostic> &PD = P.second;
|
|
|
|
|
|
|
|
// If the path is empty, generate a single step path with the location
|
|
|
|
// of the issue.
|
|
|
|
if (PD->path.empty()) {
|
|
|
|
PathDiagnosticLocation L = report->getLocation(getSourceManager());
|
|
|
|
auto piece = llvm::make_unique<PathDiagnosticEventPiece>(
|
|
|
|
L, report->getDescription());
|
|
|
|
for (SourceRange Range : report->getRanges())
|
|
|
|
piece->addRange(Range);
|
|
|
|
PD->setEndOfPath(std::move(piece));
|
|
|
|
}
|
|
|
|
|
|
|
|
PathPieces &Pieces = PD->getMutablePieces();
|
[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
|
|
|
if (getAnalyzerOptions().ShouldDisplayNotesAsEvents) {
|
[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
|
|
|
// For path diagnostic consumers that don't support extra notes,
|
|
|
|
// we may optionally convert those to path notes.
|
|
|
|
for (auto I = report->getNotes().rbegin(),
|
|
|
|
E = report->getNotes().rend(); I != E; ++I) {
|
|
|
|
PathDiagnosticNotePiece *Piece = I->get();
|
|
|
|
auto ConvertedPiece = std::make_shared<PathDiagnosticEventPiece>(
|
|
|
|
Piece->getLocation(), Piece->getString());
|
|
|
|
for (const auto &R: Piece->getRanges())
|
|
|
|
ConvertedPiece->addRange(R);
|
|
|
|
|
|
|
|
Pieces.push_front(std::move(ConvertedPiece));
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
for (auto I = report->getNotes().rbegin(),
|
|
|
|
E = report->getNotes().rend(); I != E; ++I)
|
|
|
|
Pieces.push_front(*I);
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
}
|
[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
|
|
|
|
|
|
|
// Get the meta data.
|
|
|
|
const BugReport::ExtraTextList &Meta = report->getExtraText();
|
|
|
|
for (const auto &i : Meta)
|
|
|
|
PD->addMeta(i);
|
|
|
|
|
2018-09-07 08:42:53 +08:00
|
|
|
updateExecutedLinesWithDiagnosticPieces(*PD);
|
[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
|
|
|
Consumer->HandlePathDiagnostic(std::move(PD));
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-01-17 10:59:11 +08:00
|
|
|
/// Insert all lines participating in the function signature \p Signature
|
|
|
|
/// into \p ExecutedLines.
|
|
|
|
static void populateExecutedLinesWithFunctionSignature(
|
|
|
|
const Decl *Signature, SourceManager &SM,
|
2018-09-07 08:43:55 +08:00
|
|
|
FilesToLineNumsMap &ExecutedLines) {
|
2018-01-17 10:59:11 +08:00
|
|
|
SourceRange SignatureSourceRange;
|
|
|
|
const Stmt* Body = Signature->getBody();
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto FD = dyn_cast<FunctionDecl>(Signature)) {
|
2018-01-17 10:59:11 +08:00
|
|
|
SignatureSourceRange = FD->getSourceRange();
|
2018-03-07 08:17:48 +08:00
|
|
|
} else if (const auto OD = dyn_cast<ObjCMethodDecl>(Signature)) {
|
2018-01-17 10:59:11 +08:00
|
|
|
SignatureSourceRange = OD->getSourceRange();
|
|
|
|
} else {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
SourceLocation Start = SignatureSourceRange.getBegin();
|
|
|
|
SourceLocation End = Body ? Body->getSourceRange().getBegin()
|
|
|
|
: SignatureSourceRange.getEnd();
|
2018-09-07 08:43:17 +08:00
|
|
|
if (!Start.isValid() || !End.isValid())
|
|
|
|
return;
|
2018-01-17 10:59:11 +08:00
|
|
|
unsigned StartLine = SM.getExpansionLineNumber(Start);
|
|
|
|
unsigned EndLine = SM.getExpansionLineNumber(End);
|
|
|
|
|
|
|
|
FileID FID = SM.getFileID(SM.getExpansionLoc(Start));
|
|
|
|
for (unsigned Line = StartLine; Line <= EndLine; Line++)
|
2018-09-07 08:43:55 +08:00
|
|
|
ExecutedLines[FID].insert(Line);
|
2018-01-17 10:59:11 +08:00
|
|
|
}
|
|
|
|
|
2018-02-24 07:26:54 +08:00
|
|
|
static void populateExecutedLinesWithStmt(
|
|
|
|
const Stmt *S, SourceManager &SM,
|
2018-09-07 08:43:55 +08:00
|
|
|
FilesToLineNumsMap &ExecutedLines) {
|
2018-02-24 07:26:54 +08:00
|
|
|
SourceLocation Loc = S->getSourceRange().getBegin();
|
2018-09-07 08:43:17 +08:00
|
|
|
if (!Loc.isValid())
|
|
|
|
return;
|
2018-02-24 07:26:54 +08:00
|
|
|
SourceLocation ExpansionLoc = SM.getExpansionLoc(Loc);
|
|
|
|
FileID FID = SM.getFileID(ExpansionLoc);
|
|
|
|
unsigned LineNo = SM.getExpansionLineNumber(ExpansionLoc);
|
2018-09-07 08:43:55 +08:00
|
|
|
ExecutedLines[FID].insert(LineNo);
|
2018-02-24 07:26:54 +08:00
|
|
|
}
|
|
|
|
|
2018-01-17 10:59:11 +08:00
|
|
|
/// \return all executed lines including function signatures on the path
|
|
|
|
/// starting from \p N.
|
|
|
|
static std::unique_ptr<FilesToLineNumsMap>
|
|
|
|
findExecutedLines(SourceManager &SM, const ExplodedNode *N) {
|
|
|
|
auto ExecutedLines = llvm::make_unique<FilesToLineNumsMap>();
|
|
|
|
|
|
|
|
while (N) {
|
|
|
|
if (N->getFirstPred() == nullptr) {
|
|
|
|
// First node: show signature of the entrance point.
|
|
|
|
const Decl *D = N->getLocationContext()->getDecl();
|
2018-09-07 08:43:55 +08:00
|
|
|
populateExecutedLinesWithFunctionSignature(D, SM, *ExecutedLines);
|
2018-01-17 10:59:11 +08:00
|
|
|
} else if (auto CE = N->getLocationAs<CallEnter>()) {
|
|
|
|
// Inlined function: show signature.
|
|
|
|
const Decl* D = CE->getCalleeContext()->getDecl();
|
2018-09-07 08:43:55 +08:00
|
|
|
populateExecutedLinesWithFunctionSignature(D, SM, *ExecutedLines);
|
2018-01-17 10:59:11 +08:00
|
|
|
} else if (const Stmt *S = PathDiagnosticLocation::getStmt(N)) {
|
2018-09-07 08:43:55 +08:00
|
|
|
populateExecutedLinesWithStmt(S, SM, *ExecutedLines);
|
2018-02-24 07:26:54 +08:00
|
|
|
|
|
|
|
// Show extra context for some parent kinds.
|
|
|
|
const Stmt *P = N->getParentMap().getParent(S);
|
|
|
|
|
|
|
|
// The path exploration can die before the node with the associated
|
|
|
|
// return statement is generated, but we do want to show the whole
|
|
|
|
// return.
|
2018-03-07 08:17:48 +08:00
|
|
|
if (const auto *RS = dyn_cast_or_null<ReturnStmt>(P)) {
|
2018-09-07 08:43:55 +08:00
|
|
|
populateExecutedLinesWithStmt(RS, SM, *ExecutedLines);
|
2018-02-24 07:26:54 +08:00
|
|
|
P = N->getParentMap().getParent(RS);
|
|
|
|
}
|
2018-01-17 10:59:11 +08:00
|
|
|
|
2018-02-24 07:26:54 +08:00
|
|
|
if (P && (isa<SwitchCase>(P) || isa<LabelStmt>(P)))
|
2018-09-07 08:43:55 +08:00
|
|
|
populateExecutedLinesWithStmt(P, SM, *ExecutedLines);
|
2018-01-17 10:59:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
N = N->getFirstPred();
|
|
|
|
}
|
|
|
|
return ExecutedLines;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
std::unique_ptr<DiagnosticForConsumerMapTy>
|
|
|
|
BugReporter::generateDiagnosticForConsumerMap(
|
|
|
|
BugReport *report, ArrayRef<PathDiagnosticConsumer *> consumers,
|
|
|
|
ArrayRef<BugReport *> bugReports) {
|
2009-04-30 05:58:13 +08:00
|
|
|
|
[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
|
|
|
if (!report->isPathSensitive()) {
|
|
|
|
auto Out = llvm::make_unique<DiagnosticForConsumerMapTy>();
|
|
|
|
for (auto *Consumer : consumers)
|
|
|
|
(*Out)[Consumer] = generateEmptyDiagnosticForReport(report,
|
|
|
|
getSourceManager());
|
|
|
|
return Out;
|
|
|
|
}
|
2016-10-08 03:25:10 +08:00
|
|
|
|
[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
|
|
|
// Generate the full path sensitive diagnostic, using the generation scheme
|
|
|
|
// specified by the PathDiagnosticConsumer. Note that we have to generate
|
|
|
|
// path diagnostics even for consumers which do not support paths, because
|
|
|
|
// the BugReporterVisitors may mark this bug as a false positive.
|
|
|
|
assert(!bugReports.empty());
|
|
|
|
MaxBugClassSize.updateMax(bugReports.size());
|
|
|
|
std::unique_ptr<DiagnosticForConsumerMapTy> Out =
|
|
|
|
generatePathDiagnostics(consumers, bugReports);
|
2016-10-08 03:25:10 +08:00
|
|
|
|
[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
|
|
|
if (Out->empty())
|
|
|
|
return Out;
|
2009-01-24 08:55:43 +08:00
|
|
|
|
[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
|
|
|
MaxValidBugClassSize.updateMax(bugReports.size());
|
2013-03-16 05:41:53 +08:00
|
|
|
|
[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
|
|
|
// Examine the report and see if the last piece is in a header. Reset the
|
|
|
|
// report location to the last piece in the main source file.
|
|
|
|
AnalyzerOptions &Opts = getAnalyzerOptions();
|
|
|
|
for (auto const &P : *Out)
|
[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
|
|
|
if (Opts.ShouldReportIssuesInMainSourceFile && !Opts.AnalyzeAll)
|
[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
|
|
|
P.second->resetDiagnosticLocationToMainFile();
|
Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the same time.
This fixes several issues:
- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.
- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).
As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now
the tests have higher fidelity with what users will see.
There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular
consumer expects.
llvm-svn: 162028
2012-08-17 01:45:23 +08:00
|
|
|
|
[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
|
|
|
return Out;
|
2008-04-03 12:42:52 +08:00
|
|
|
}
|
2008-07-15 01:40:50 +08:00
|
|
|
|
2012-04-05 02:11:35 +08:00
|
|
|
void BugReporter::EmitBasicReport(const Decl *DeclWithIssue,
|
2014-02-12 05:49:21 +08:00
|
|
|
const CheckerBase *Checker,
|
|
|
|
StringRef Name, StringRef Category,
|
|
|
|
StringRef Str, PathDiagnosticLocation Loc,
|
|
|
|
ArrayRef<SourceRange> Ranges) {
|
|
|
|
EmitBasicReport(DeclWithIssue, Checker->getCheckName(), Name, Category, Str,
|
|
|
|
Loc, Ranges);
|
|
|
|
}
|
2018-03-07 08:17:48 +08:00
|
|
|
|
2014-02-12 05:49:21 +08:00
|
|
|
void BugReporter::EmitBasicReport(const Decl *DeclWithIssue,
|
|
|
|
CheckName CheckName,
|
|
|
|
StringRef name, StringRef category,
|
2011-09-21 05:38:35 +08:00
|
|
|
StringRef str, PathDiagnosticLocation Loc,
|
2013-10-08 01:16:59 +08:00
|
|
|
ArrayRef<SourceRange> Ranges) {
|
2011-02-23 08:16:01 +08:00
|
|
|
// 'BT' is owned by BugReporter.
|
2014-02-12 05:49:21 +08:00
|
|
|
BugType *BT = getBugTypeForName(CheckName, name, category);
|
2015-06-23 21:15:32 +08:00
|
|
|
auto R = llvm::make_unique<BugReport>(*BT, str, Loc);
|
2012-04-05 02:11:35 +08:00
|
|
|
R->setDeclWithIssue(DeclWithIssue);
|
2013-10-08 01:16:59 +08:00
|
|
|
for (ArrayRef<SourceRange>::iterator I = Ranges.begin(), E = Ranges.end();
|
|
|
|
I != E; ++I)
|
|
|
|
R->addRange(*I);
|
2015-06-23 21:15:32 +08:00
|
|
|
emitReport(std::move(R));
|
2009-01-24 04:28:53 +08:00
|
|
|
}
|
2011-02-23 08:16:01 +08:00
|
|
|
|
2014-02-12 05:49:21 +08:00
|
|
|
BugType *BugReporter::getBugTypeForName(CheckName CheckName, StringRef name,
|
2011-07-23 18:55:15 +08:00
|
|
|
StringRef category) {
|
2012-02-05 10:13:05 +08:00
|
|
|
SmallString<136> fullDesc;
|
2014-02-12 05:49:21 +08:00
|
|
|
llvm::raw_svector_ostream(fullDesc) << CheckName.getName() << ":" << name
|
|
|
|
<< ":" << category;
|
2014-11-19 11:06:06 +08:00
|
|
|
BugType *&BT = StrBugTypes[fullDesc];
|
|
|
|
if (!BT)
|
2014-02-12 05:49:21 +08:00
|
|
|
BT = new BugType(CheckName, name, category);
|
2011-02-23 08:16:01 +08:00
|
|
|
return BT;
|
|
|
|
}
|