- Fix the bug with transition handling in ExprInspectionChecker's
checkDeadSymbols implementation.
- Test this bug by adding a new function clang_analyzer_numTimesReached() to
catch number of passes through the code, which should be handy for testing
against unintended state splits.
- Add two more functions should help debugging issues quickly without running
the debugger or dumping exploded graphs - clang_analyzer_dump() which dump()s
an SVal argument to a warning message, and clang_analyzer_printState(), which
dump()s the current program state to stderr.
Differential Revision: https://reviews.llvm.org/D26835
llvm-svn: 288257
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
Provide separate visitor templates for the three hierarchies, and also
the `FullSValVisitor' class, which is a union of all three visitors.
Additionally, add a particular example visitor, `SValExplainer', in order to
test the visitor templates. This visitor is capable of explaining the SVal,
SymExpr, or MemRegion in a natural language.
Compared to the reverted r257605, this fixes the test that used to fail
on some triples, and fixes build failure under -fmodules.
Differential Revision: http://reviews.llvm.org/D15448
llvm-svn: 257893
This reverts commit r257605.
The test fails on architectures that use unsigned int as size_t.
SymbolManager.h fails with compile errors on some platforms.
llvm-svn: 257608
Provide separate visitor templates for the three hierarchies, and also
the `FullSValVisitor' class, which is a union of all three visitors.
Additionally, add a particular example visitor, `SValExplainer', in order to
test the visitor templates. This visitor is capable of explaining the SVal,
SymExpr, or MemRegion in a natural language.
Differential Revision: http://reviews.llvm.org/D15448
llvm-svn: 257605
SymbolReaper was destroying the symbol too early when it was referenced only
from an index SVal of a live ElementRegion.
In order to test certain aspects of this patch, extend the debug.ExprInspection
checker to allow testing SymbolReaper in a direct manner.
Differential Revision: http://reviews.llvm.org/D12726
llvm-svn: 255236
This will emit a warning if a call to clang_analyzer_warnIfReached is
executed, printing REACHABLE. This is a more explicit way to declare
expected reachability than using clang_analyzer_eval or triggering
a bug (divide-by-zero or null dereference), and unlike the former will
work the same in inlined functions and top-level functions. Like the
other debug helpers, it is part of the debug.ExprInspection checker.
Patch by Jared Grubb!
llvm-svn: 191909
Add a debug checker that is useful to understand how the ExplodedGraph is
built; it can be triggered using the following command:
clang -cc1 -analyze -analyzer-checker=debug.ViewExplodedGraph my_program.c
A patch by Béatrice Creusillet!
llvm-svn: 184768
This turns on not only destructor inlining, but inlining of constructors
for types with non-trivial destructors. Per r178516, we will still not
inline the constructor or destructor of anything that looks like a
container unless the analyzer-config option 'c++-container-inlining' is
set to 'true'.
In addition to the more precise path-sensitive model, this allows us to
catch simple smart pointer issues:
#include <memory>
void test() {
std::auto_ptr<int> releaser(new int[4]);
} // memory allocated with 'new[]' should not be deleted with 'delete'
<rdar://problem/12295363>
llvm-svn: 178805
This enables constructor inlining for types with non-trivial destructors.
The plan is to enable destructor inlining within the next month, but that
needs further verification.
<rdar://problem/12295329>
llvm-svn: 176200
This is a text file with Markdown-ish formatting because we haven't decided
where analyzer internal documents should go, but it's probably better to
have this in source control than sitting on my local drive forever.
llvm-svn: 174398
This is just the output of sphinx-quickstart. Now all that is needed
to begin converting the analyzer docs to reST is the server-side setup.
The analyzer folks have asked me to keep this segregated from the other
clang docs since the analyzer is a logically separate project (and has
its own separate web page) even though it resides in the clang tree.
llvm-svn: 171425
The file still exists in docs/analyzer/, but it won't be linked to from
clang.llvm.org or processed as part of the default Sphinx doc-build.
RegionStore has changed a lot from what Ted and Zhongxing describe here!
llvm-svn: 170260
More generally, this adds a new configuration option 'c++-inlining', which
controls which C++ member functions can be considered for inlining. This
uses the new -analyzer-config table, so the cc1 arguments will look like this:
... -analyzer-config c++-inlining=[none|methods|constructors|destructors]
Note that each mode implies that all the previous member function kinds
will be inlined as well; it doesn't make sense to inline destructors
without inlining constructors, for example.
The default mode is 'methods'.
llvm-svn: 163004
Because the CXXNewExpr appears after the CXXConstructExpr in the CFG, we don't
actually have the correct region to construct into at the time we decide
whether or not to inline. The long-term fix (discussed in PR12014) might be to
introduce a new CFG node (CFGAllocator) that appears before the constructor.
Tracking the short-term fix in <rdar://problem/12180598>.
llvm-svn: 162689
Since DynamicTypeInfo is not inherently related to inlining or to dynamic
calls, it makes more sense (to me) to discuss it first.
Also fix some typos, massage some grammar, and (hopefully) improve precision
and clarity.
llvm-svn: 162365
Also, remove the FIXME about merging -analyzer-stats and the debug.Stats
checker. This would be a bad idea because simply running debug.Stats can
affect the output of -analyzer-stats.
llvm-svn: 162364
Formatting includes:
- removing line wraps (Emacs Cmd-Q), to make text easier to read
- provide useful indentation
- call out caveats and notes more explictly
Stylistically, I prefer the document talk in 3rd person instead of "we". The
term "we" is unambiguous, and sometimes refers to different things. I've passed
over the existing paragraphs and made them speak more about specific entities
that compose the analyzer and what they do (e.g., ExprEngine) instead of "we"
referring to the analyzer.
Further, I have substituted some vague concepts such as "state" or "program
state" and replaced them with their precise implementation counterparts (e.g.,
ProgramState). This makes the document more technically precise throughout the
entire narrative, which would sometimes use vague terms and other times precise
terms.
I've placed several comments within the document, which can be seen with
***TMK/COMMENT***, which indicate places that need to be enhanced or clarified,
or called out as questions about intended bheavior.
llvm-svn: 162338
Under -analyzer-ipa=basic-inlining, only C functions, blocks, and C++ static
member functions are inlined -- essentially, the calls that behave like simple
C function calls. This is essentially the behavior in Xcode 4.4.
C++ support still has some rough edges, and we don't want users to be worried
about them if they download and run their own checker. (In particular, the
massive number of false positives for analyzing LLVM comes from inlining
defensively-written code in contexts where more aggressive assumptions are
implicitly made. This problem is not unique to C++, but it is exacerbated by
the higher proportion of code that lives in header files in C++.)
The eventual goal is to be comfortable enough with C++ support (and simple
Objective-C support) to advance to -analyzer-ipa=inlining as the default
behavior. See the IPA design notes for more details.
llvm-svn: 162318
This attempts to be a higher-level description of our inlining heuristics
and decision trees than the source, where the work is spread out between
ExprEngine (mostly in ExprEngineCallAndReturn.cpp) and CallEvent, with a
few other classes participating as well.
llvm-svn: 162073
Artem Dergachev