2010-07-19 09:31:21 +08:00
|
|
|
//===-- AnalysisManager.cpp -------------------------------------*- C++ -*-===//
|
|
|
|
//
|
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
|
2010-07-19 09:31:21 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2011-02-10 09:03:03 +08:00
|
|
|
#include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
|
2010-07-19 09:31:21 +08:00
|
|
|
|
|
|
|
using namespace clang;
|
2010-12-23 15:20:52 +08:00
|
|
|
using namespace ento;
|
2010-07-19 09:31:21 +08:00
|
|
|
|
2011-12-20 10:48:34 +08:00
|
|
|
void AnalysisManager::anchor() { }
|
|
|
|
|
2020-01-31 00:00:49 +08:00
|
|
|
AnalysisManager::AnalysisManager(ASTContext &ASTCtx, Preprocessor &PP,
|
2018-08-07 07:09:07 +08:00
|
|
|
const PathDiagnosticConsumers &PDC,
|
|
|
|
StoreManagerCreator storemgr,
|
|
|
|
ConstraintManagerCreator constraintmgr,
|
|
|
|
CheckerManager *checkerMgr,
|
|
|
|
AnalyzerOptions &Options,
|
|
|
|
CodeInjector *injector)
|
|
|
|
: AnaCtxMgr(
|
[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
|
|
|
ASTCtx, Options.UnoptimizedCFG,
|
|
|
|
Options.ShouldIncludeImplicitDtorsInCFG,
|
2019-07-16 12:46:31 +08:00
|
|
|
/*addInitializers=*/true,
|
[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
|
|
|
Options.ShouldIncludeTemporaryDtorsInCFG,
|
|
|
|
Options.ShouldIncludeLifetimeInCFG,
|
2018-08-07 07:09:07 +08:00
|
|
|
// Adding LoopExit elements to the CFG is a requirement for loop
|
|
|
|
// unrolling.
|
[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
|
|
|
Options.ShouldIncludeLoopExitInCFG ||
|
|
|
|
Options.ShouldUnrollLoops,
|
|
|
|
Options.ShouldIncludeScopesInCFG,
|
|
|
|
Options.ShouldSynthesizeBodies,
|
|
|
|
Options.ShouldConditionalizeStaticInitializers,
|
|
|
|
/*addCXXNewAllocator=*/true,
|
|
|
|
Options.ShouldIncludeRichConstructorsInCFG,
|
2019-05-25 07:37:08 +08:00
|
|
|
Options.ShouldElideConstructors,
|
|
|
|
/*addVirtualBaseBranches=*/true,
|
|
|
|
injector),
|
2020-01-31 00:00:49 +08:00
|
|
|
Ctx(ASTCtx), PP(PP), LangOpts(ASTCtx.getLangOpts()),
|
2018-08-07 07:09:07 +08:00
|
|
|
PathConsumers(PDC), CreateStoreMgr(storemgr),
|
|
|
|
CreateConstraintMgr(constraintmgr), CheckerMgr(checkerMgr),
|
|
|
|
options(Options) {
|
2011-07-29 07:07:59 +08:00
|
|
|
AnaCtxMgr.getCFGBuildOptions().setAllAlwaysAdd();
|
2019-12-12 03:34:44 +08:00
|
|
|
AnaCtxMgr.getCFGBuildOptions().OmitImplicitValueInitializers = true;
|
2019-12-18 09:53:26 +08:00
|
|
|
AnaCtxMgr.getCFGBuildOptions().AddCXXDefaultInitExprInAggregates =
|
|
|
|
Options.ShouldIncludeDefaultInitForAggregates;
|
2011-07-21 13:22:52 +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
|
|
|
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 10:03:00 +08:00
|
|
|
}
|