Commit Graph

44 Commits

Author SHA1 Message Date
Charusso 38ab3b876b [analyzer] CheckerContext: Make the Preprocessor available
Summary:
This patch hooks the `Preprocessor` trough `BugReporter` to the
`CheckerContext` so the checkers could look for macro definitions.

Reviewed By: NoQ

Differential Revision: https://reviews.llvm.org/D69731
2020-01-30 17:05:52 +01:00
Gabor Horvath ea93d7d642 [CFG] Add an option to expand CXXDefaultInitExpr into aggregate initialization
This is useful for clients that are relying on linearized CFGs for evaluating
subexpressions and want the default initializer to be evaluated properly.

The upcoming lifetime analysis is using this but it might also be useful
for the static analyzer at some point.

Differential Revision: https://reviews.llvm.org/D71642
2019-12-17 17:56:06 -08:00
Gabor Horvath 9fdcae7c81 [analyzer] Do not cache out on some shared implicit AST nodes
Some AST nodes which stands for implicit initialization is shared. The analyzer
will do the same evaluation on the same nodes resulting in the same state. The
analyzer will "cache out", i.e. it thinks that it visited an already existing
node in the exploded graph. This is not true in this case and we lose coverage.
Since these nodes do not really require any processing from the analyzer
we just omit them from the CFG.

Differential Revision: https://reviews.llvm.org/D71371
2019-12-11 17:15:12 -08:00
Dmitri Gribenko 6b9d7c9da5 Removed some dead code in BugReporter and related files
Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66473

llvm-svn: 369504
2019-08-21 08:48:24 +00:00
Rui Ueyama 49a3ad21d6 Fix parameter name comments using clang-tidy. NFC.
This patch applies clang-tidy's bugprone-argument-comment tool
to LLVM, clang and lld source trees. Here is how I created this
patch:

$ git clone https://github.com/llvm/llvm-project.git
$ cd llvm-project
$ mkdir build
$ cd build
$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \
    -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \
    -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \
    -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm
$ ninja
$ parallel clang-tidy -checks='-*,bugprone-argument-comment' \
    -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \
    ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h}

llvm-svn: 366177
2019-07-16 04:46:31 +00:00
Artem Dergachev 192a7474d6 [CFG] Add branch to skip vbase inits when they're handled by superclass.
This patch adds the run-time CFG branch that would skip initialization of
virtual base classes depending on whether the constructor is called from a
superclass constructor or not. Previously the Static Analyzer was already
skipping virtual base-class initializers in such constructors, but it wasn't
skipping their arguments and their potential side effects, which was causing
pr41300 (and was generally incorrect). The previous skipping behavior is
now replaced with a hard assertion that we're not even getting there due
to how our CFG works.

The new CFG element is under a CFG build option so that not to break other
consumers of the CFG by this change. Static Analyzer support for this change
is implemented.

Differential Revision: https://reviews.llvm.org/D61816

llvm-svn: 361681
2019-05-24 23:37:08 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Kristof Umann 549f9cd46f [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-11-30 20:44:00 +00:00
George Karpenkov 4ece68a0a8 [analyzer] Add ASTContext to CheckerManager
Some checkers require ASTContext. Having it in the constructor saves a
lot of boilerplate of having to pass it around.

Differential Revision: https://reviews.llvm.org/D50111

llvm-svn: 339079
2018-08-06 23:09:07 +00:00
Artem Dergachev ff267df0de [CFG] [analyzer] Add construction contexts that explain pre-C++17 copy elision.
Before C++17 copy elision was optional, even if the elidable copy/move
constructor had arbitrary side effects. The elidable constructor is present
in the AST, but marked as elidable.

In these cases CFG now contains additional information that allows its clients
to figure out if a temporary object is only being constructed so that to pass
it to an elidable constructor. If so, it includes a reference to the elidable
constructor's construction context, so that the client could elide the
elidable constructor and construct the object directly at its final destination.

Differential Revision: https://reviews.llvm.org/D47616

llvm-svn: 335795
2018-06-28 00:04:54 +00:00
Maxim Ostapenko debca45e45 [analyzer] Add scope information to CFG
This patch adds two new CFG elements CFGScopeBegin and CFGScopeEnd that indicate
when a local scope begins and ends respectively. We use first VarDecl declared
in a scope to uniquely identify it and add CFGScopeBegin and CFGScopeEnd elements
into corresponding basic blocks.

Differential Revision: https://reviews.llvm.org/D16403

llvm-svn: 327258
2018-03-12 12:26:15 +00:00
Artem Dergachev 41ffb30716 [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
George Karpenkov 3d64d6ee54 [Analyzer] Do not use static storage to for implementations created in BodyFarm.cpp
Differential Revision: https://reviews.llvm.org/D39208

llvm-svn: 316400
2017-10-23 23:59:52 +00:00
Peter Szecsi d91554bc91 [StaticAnalyzer] LoopUnrolling fixes
1. The LoopUnrolling feature needs the LoopExit included in the CFG so added this
dependency via the config options
2. The LoopExit element can be encountered even if we haven't encountered the 
block of the corresponding LoopStmt. So the asserts were not right.
3. If we are caching out the Node then we get a nullptr from generateNode which
case was not handled.


Differential Revision: https://reviews.llvm.org/D37103

llvm-svn: 311880
2017-08-28 10:21:24 +00:00
Peter Szecsi 999a25ff72 [CFG] Add LoopExit information to CFG
This patch introduces a new CFG element CFGLoopExit that indicate when a loop
ends. It does not deal with returnStmts yet (left it as a TODO).
It hidden behind a new analyzer-config flag called cfg-loopexit (false by
default).
Test cases added.

The main purpose of this patch right know is to make loop unrolling and loop
widening easier and more efficient. However, this information can be useful for
future improvements in the StaticAnalyzer core too.

Differential Revision: https://reviews.llvm.org/D35668

llvm-svn: 311235
2017-08-19 11:19:16 +00:00
Matthias Gehre 351c218d15 CFG: Add CFGElement for automatic variables that leave the scope
Summary:
This mimics the implementation for the implicit destructors. The
generation of this scope leaving elements is hidden behind
a flag to the CFGBuilder, thus it should not affect existing code.

Currently, I'm missing a test (it's implicitly tested by the clang-tidy
lifetime checker that I'm proposing).
I though about a test using debug.DumpCFG, but then I would
have to add an option to StaticAnalyzer/Core/AnalyzerOptions
to enable the scope leaving CFGElement,
which would only be useful to that particular test.

Any other ideas how I could make a test for this feature?

Reviewers: krememek, jordan_rose

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D15031

llvm-svn: 307759
2017-07-12 07:04:19 +00:00
Ted Kremenek 3a0678e33c [analyzer] Apply whitespace cleanups by Honggyu Kim.
llvm-svn: 246978
2015-09-08 03:50:52 +00:00
Ted Kremenek eeccb30b94 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 15:14:15 +00:00
Ted Kremenek 233c1b0c77 Add configuration plumbing to enable static initializer branching in the CFG for the analyzer.
This setting still isn't enabled yet in the analyzer.  This is
just prep work.

llvm-svn: 178317
2013-03-29 00:09:22 +00:00
Ted Kremenek 4a5b35eeec Have AnalyzerOptions::getBooleanOption() stick the matching config
string in the config table so that it can be dumped as part of the 
config dumper.  Add a test to show that these options are sticking
and can be cross-checked using FileCheck.

llvm-svn: 164954
2012-10-01 18:28:19 +00:00
Ted Kremenek 14f779c4d6 Implement faux-body-synthesis of well-known functions in the static analyzer when
their implementations are unavailable.  Start by simulating dispatch_sync().

This change is largely a bunch of plumbing around something very simple.  We
use AnalysisDeclContext to conjure up a fake function body (using the
current ASTContext) when one does not exist.  This is controlled
under the analyzer-config option "faux-bodies", which is off by default.

The plumbing in this patch is largely to pass the necessary machinery
around.  CallEvent needs the AnalysisDeclContextManager to get
the function definition, as one may get conjured up lazily.

BugReporter and PathDiagnosticLocation needed to be relaxed to handle
invalid locations, as the conjured body has no real source locations.
We do some primitive recovery in diagnostic generation to generate
some reasonable locations (for arrows and events), but it can be
improved.

llvm-svn: 164339
2012-09-21 00:09:11 +00:00
Jordan Rose 6d671cc34a [analyzer] Always include destructors in the analysis CFG.
While destructors will continue to not be inlined (unless the analyzer
config option 'c++-inlining' is set to 'destructors'), leaving them out
of the CFG is an incomplete model of the behavior of an object, and
can cause false positive warnings (like PR13751, now working).

Destructors for temporaries are still not on by default, since
(a) we haven't actually checked this code to be sure it's fully correct
    (in particular, we probably need to be very careful with regard to
    lifetime-extension when a temporary is bound to a reference,
    C++11 [class.temporary]p5), and
(b) ExprEngine doesn't actually do anything when it sees a temporary
    destructor in the CFG -- not even invalidate the object region.

To enable temporary destructors, set the 'cfg-temporary-dtors' analyzer
config option to '1'. The old -cfg-add-implicit-dtors cc1 option, which
controlled all implicit destructors, has been removed.

llvm-svn: 163264
2012-09-05 22:55:23 +00:00
Ted Kremenek 8756c4a1a9 Store const& to AnalyzerOptions in AnalysisManager instead of copying
individual flags.

llvm-svn: 162929
2012-08-30 19:26:43 +00:00
Ted Kremenek fb5351eed3 Add new -cc1 driver option -analyzer-config, which allows one to specify
a comma separated collection of key:value pairs (which are strings).  This
allows a general way to provide analyzer configuration data from the command line.

No clients yet.

llvm-svn: 162827
2012-08-29 05:55:00 +00:00
Ted Kremenek 9bf9af92a4 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
Jordan Rose a765bac7a1 [analyzer] Turn -cfg-add-initializers on by default, and remove the flag.
llvm-svn: 161060
2012-07-31 18:04:59 +00:00
Benjamin Kramer d1d76b2da7 Remove unused private member variables found by clang's new -Wunused-private-field.
llvm-svn: 158086
2012-06-06 17:32:50 +00:00
Douglas Gregor 0481c8f206 Remove the unused, unmaintained, incomplete 'Index' library.
llvm-svn: 154672
2012-04-13 16:31:46 +00:00
Anna Zaks 72eee39df7 [analyzer] Enable retry exhausted without inlining by default.
llvm-svn: 153591
2012-03-28 19:59:16 +00:00
Anna Zaks 5b3939fae6 [analyzer] Add an option to re-analyze a dead-end path without inlining.
The analyzer gives up path exploration under certain conditions. For
example, when the same basic block has been visited more than 4 times.
With inlining turned on, this could lead to decrease in code coverage.
Specifically, if we give up inside the inlined function, the rest of
parent's basic blocks will not get analyzed.

This commit introduces an option to enable re-run along the failed path,
in which we do not inline the last inlined call site. This is done by
enqueueing the node before the processing of the inlined call site
with a special policy encoded in the state. The policy tells us not to
inline the call site along the path.

This lead to ~10% increase in the number of paths analyzed. Even though
we expected a much greater coverage improvement. 

The option is turned off by default for now.

llvm-svn: 153534
2012-03-27 20:02:53 +00:00
David Blaikie bbafb8a745 Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".

Reviewed by Chris Lattner

llvm-svn: 152536
2012-03-11 07:00:24 +00:00
Anna Zaks 0af3e06ff6 [analyzer] Rework inlining related command line options.
- Remove -analyzer-inline-call.
 - Add -analyzer-ipa=[none|inlining]
 - Add -analyzer-inlining-mode to allow experimentation for
different performance tuning methods.

llvm-svn: 152351
2012-03-08 23:16:35 +00:00
Anna Zaks 265087721a [analyzer] Bound the size of the functions being inlined + provide
command line options for inlining tuning.

This adds the option for stack depth bound as well as function size
bound. 

+ minor doxygenification

llvm-svn: 151930
2012-03-02 19:05:03 +00:00
Benjamin Kramer 7ec12c928a Revert my patches which removed Diagnostic.h includes by moving some operator overloads out of line.
This seems to negatively affect compile time onsome ObjC tests
(which use a lot of partial diagnostics I assume). I have to come
up with a way to keep them inline without including Diagnostic.h
everywhere. Now adding a new diagnostic requires a full rebuild
of e.g. the static analyzer which doesn't even use those diagnostics.

This reverts commit 6496bd10dc3a6d5e3266348f08b6e35f8184bc99.
This reverts commit 7af19b817ba964ac560b50c1ed6183235f699789.
This reverts commit fdd15602a42bbe26185978ef1e17019f6d969aa7.
This reverts commit 00bd44d5677783527d7517c1ffe45e4d75a0f56f.
This reverts commit ef9b60ffed980864a8db26ad30344be429e58ff5.

llvm-svn: 150006
2012-02-07 22:29:24 +00:00
Benjamin Kramer 3307c508c9 Move various diagnostic operator<< overloads out of line and remove includes of Diagnostic.h.
Fix all the files that depended on transitive includes of Diagnostic.h.
With this patch in place changing a diagnostic no longer requires a full rebuild of the StaticAnalyzer.

llvm-svn: 149781
2012-02-04 12:31:12 +00:00
David Blaikie 68e081d606 Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146959
2011-12-20 02:48:34 +00:00
Ted Kremenek 81ce1c8a99 Rename AnalysisContext to AnalysisDeclContext. Not only is this name more accurate, but it frees up the name AnalysisContext for other uses.
llvm-svn: 142782
2011-10-24 01:32:45 +00:00
Anna Zaks 8d4c8e1498 [analyzer] Add -analyzer-purge option which can take on multiple values, remove -analyzer-purge=none. (Small refactor as well: move the work of constructing AnalysisManager from the callers to the class itself.)
llvm-svn: 140838
2011-09-30 02:03:00 +00:00
David Blaikie 53c125d063 Rename PathDiagnosticClient to PathDiagnosticConsumer as per issue 5397
llvm-svn: 140492
2011-09-26 00:51:36 +00:00
David Blaikie 9c902b5502 Rename Diagnostic to DiagnosticsEngine as per issue 5397
llvm-svn: 140478
2011-09-25 23:23:43 +00:00
Ted Kremenek e9fda1e48a [analyzer] Overhaul how the static analyzer expects CFGs by forcing CFGs to be linearized only when used by the static analyzer. This required a rewrite of LiveVariables, and exposed a ton of subtle bugs.
The motivation of this large change is to drastically simplify the logic in ExprEngine going forward.

Some fallout is that the output of some BugReporterVisitors is not as accurate as before; those will
need to be fixed over time.  There is also some possible performance regression as RemoveDeadBindings
will be called frequently; this can also be improved over time.

llvm-svn: 136419
2011-07-28 23:07:59 +00:00
Ted Kremenek 86070b9c0f Move AnalysisManager constructor out of line. No functionality change (yet).
llvm-svn: 135667
2011-07-21 05:22:52 +00:00
Ted Kremenek f8cbac4b91 Split 'include/clang/StaticAnalyzer' into 'include/clang/StaticAnalyzer/Core' and 'include/clang/StaticAnalyzer/Checkers'.
This layout matches lib/StaticAnalyzer, which corresponds to two StaticAnalyzer libraries.

llvm-svn: 125251
2011-02-10 01:03:03 +00:00
Argyrios Kyrtzidis fa0734ec4f [analyzer] Move the files in lib/StaticAnalyzer to lib/StaticAnalyzer/Core.
Eventually there will also be a lib/StaticAnalyzer/Frontend that will handle initialization and checker registration.
Yet another library to avoid cyclic dependencies between Core and Checkers.

llvm-svn: 125124
2011-02-08 22:30:36 +00:00