Some of the magic functions take arguments of arbitrary type. However,
for semantic correctness, the compiler still requires a declaration
of these functions with the correct type. Since C does not have
argument-type-overloaded function, this made those functions hard to
use in C code. Improve this situation by allowing arbitrary suffixes
in the affected magic functions' names, thus allowing the user to
create different declarations for different types.

A patch by Keno Fischer!

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297325 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291831 91177308-0d34-0410-b5e6-96231b3b80d8

- 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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288257 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279942 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275848 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264941 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258862 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257893 91177308-0d34-0410-b5e6-96231b3b80d8

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.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257608 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257605 91177308-0d34-0410-b5e6-96231b3b80d8

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255236 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246105 91177308-0d34-0410-b5e6-96231b3b80d8

FIXME: Dragonegg may be updated at non-trivial changes.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198274 91177308-0d34-0410-b5e6-96231b3b80d8

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!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191909 91177308-0d34-0410-b5e6-96231b3b80d8

Patch by Jared Grubb!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190651 91177308-0d34-0410-b5e6-96231b3b80d8

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!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184768 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181351 91177308-0d34-0410-b5e6-96231b3b80d8

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>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178805 91177308-0d34-0410-b5e6-96231b3b80d8

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>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176200 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174398 91177308-0d34-0410-b5e6-96231b3b80d8

Thanks Jordan!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173955 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171788 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171786 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171425 91177308-0d34-0410-b5e6-96231b3b80d8

As per Ted's advice. It can be brought back from version control if
needed.

This also fixes a Sphinx warning.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170401 91177308-0d34-0410-b5e6-96231b3b80d8

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!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170260 91177308-0d34-0410-b5e6-96231b3b80d8

Also, document both new inlining options in IPA.txt.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163551 91177308-0d34-0410-b5e6-96231b3b80d8

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'.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163004 91177308-0d34-0410-b5e6-96231b3b80d8

There are two tests regressions that come from the fact that the Retain
Count checker does not cancel out inlining of ObjC methods.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162950 91177308-0d34-0410-b5e6-96231b3b80d8

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>.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162689 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162688 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162365 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162364 91177308-0d34-0410-b5e6-96231b3b80d8

bifurcation)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162343 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162338 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162336 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162318 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162073 91177308-0d34-0410-b5e6-96231b3b80d8