2010-07-19 01:31:21 +00:00
|
|
|
//===-- AnalysisManager.cpp -------------------------------------*- C++ -*-===//
|
|
|
|
|
//
|
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
|
//
|
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2011-02-10 01:03:03 +00:00
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
|
2010-07-19 01:31:21 +00:00
|
|
|
|
|
|
|
|
using namespace clang;
|
2010-12-23 07:20:52 +00:00
|
|
|
using namespace ento;
|
2010-07-19 01:31:21 +00:00
|
|
|
|
2011-12-20 02:48:34 +00:00
|
|
|
void AnalysisManager::anchor() { }
|
|
|
|
|
|
2017-10-23 23:59:52 +00:00
|
|
|
AnalysisManager::AnalysisManager(
|
|
|
|
|
ASTContext &ASTCtx, DiagnosticsEngine &diags, const LangOptions &lang,
|
|
|
|
|
const PathDiagnosticConsumers &PDC, StoreManagerCreator storemgr,
|
|
|
|
|
ConstraintManagerCreator constraintmgr, CheckerManager *checkerMgr,
|
|
|
|
|
AnalyzerOptions &Options, CodeInjector *injector)
|
|
|
|
|
: AnaCtxMgr(ASTCtx, Options.UnoptimizedCFG,
|
|
|
|
|
Options.includeImplicitDtorsInCFG(),
|
|
|
|
|
/*AddInitializers=*/true, Options.includeTemporaryDtorsInCFG(),
|
|
|
|
|
Options.includeLifetimeInCFG(),
|
|
|
|
|
// Adding LoopExit elements to the CFG is a requirement for loop
|
|
|
|
|
// unrolling.
|
|
|
|
|
Options.includeLoopExitInCFG() || Options.shouldUnrollLoops(),
|
2018-03-12 12:26:15 +00:00
|
|
|
Options.includeScopesInCFG(),
|
2017-10-23 23:59:52 +00:00
|
|
|
Options.shouldSynthesizeBodies(),
|
|
|
|
|
Options.shouldConditionalizeStaticInitializers(),
|
|
|
|
|
/*addCXXNewAllocator=*/true,
|
[CFG] Add extra context to C++ constructor statement elements.
This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional
information to provide regarding what sort of object is being constructed.
It is useful for figuring out what memory is initialized in client of the
CFG such as the Static Analyzer, which do not operate by recursive AST
traversal, but instead rely on the CFG to provide all the information when they
need it. Otherwise, the statement that triggers the construction and defines
what memory is being initialized would normally occur after the
construct-expression, and the client would need to peek to the next CFG element
or use statement parent map to understand the necessary facts about
the construct-expression.
As a proof of concept, CFGConstructors are added for new-expressions
and the respective test cases are provided to demonstrate how it works.
For now, the only additional data contained in the CFGConstructor element is
the "trigger statement", such as new-expression, which is the parent of the
constructor. It will be significantly expanded in later commits. The additional
data is organized as an auxiliary structure - the "construction context",
which is allocated separately from the CFGElement.
Differential Revision: https://reviews.llvm.org/D42672
llvm-svn: 324668
2018-02-08 22:58:15 +00:00
|
|
|
Options.includeRichConstructorsInCFG(),
|
2017-10-23 23:59:52 +00:00
|
|
|
injector),
|
|
|
|
|
Ctx(ASTCtx), Diags(diags), LangOpts(lang), PathConsumers(PDC),
|
|
|
|
|
CreateStoreMgr(storemgr), CreateConstraintMgr(constraintmgr),
|
|
|
|
|
CheckerMgr(checkerMgr), options(Options) {
|
2011-07-28 23:07:59 +00:00
|
|
|
AnaCtxMgr.getCFGBuildOptions().setAllAlwaysAdd();
|
2011-07-21 05:22:52 +00: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-16 17:45:23 +00:00
|
|
|
AnalysisManager::~AnalysisManager() {
|
|
|
|
|
FlushDiagnostics();
|
|
|
|
|
for (PathDiagnosticConsumers::iterator I = PathConsumers.begin(),
|
|
|
|
|
E = PathConsumers.end(); I != E; ++I) {
|
|
|
|
|
delete *I;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void AnalysisManager::FlushDiagnostics() {
|
|
|
|
|
PathDiagnosticConsumer::FilesMade filesMade;
|
|
|
|
|
for (PathDiagnosticConsumers::iterator I = PathConsumers.begin(),
|
|
|
|
|
E = PathConsumers.end();
|
|
|
|
|
I != E; ++I) {
|
|
|
|
|
(*I)->FlushDiagnostics(&filesMade);
|
|
|
|
|
}
|
2011-09-30 02:03:00 +00:00
|
|
|
}
|