[analyzer] Enable destructor inlining by default (c++-inlining=destructors).

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

1 files changed, 35 insertions, 6 deletions

diff --git a/docs/analyzer/IPA.txt b/docs/analyzer/IPA.txt
index 4cffcb7454..01e73cec7f 100644
--- a/docs/analyzer/IPA.txt
+++ b/docs/analyzer/IPA.txt
@@ -46,11 +46,14 @@ Each of these modes 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 c++-inlining mode is 'constructors', meaning that member functions,
-overloaded operators, and some constructors will be inlined. If a type has a
-non-trivial destructor, however, its constructor will not be inlined. Note that
-no C++ member functions will be inlined under -analyzer-config ipa=none or
--analyzer-config ipa=basic-inlining.
+The default c++-inlining mode is 'destructors', meaning that all member
+functions with visible definitions will be considered for inlining. In some
+cases the analyzer may still choose not to inline the function.
+
+Note that under 'constructors', constructors for types with non-trivial
+destructors will not be inlined. Additionally, no C++ member functions will be 
+inlined under -analyzer-config ipa=none or -analyzer-config ipa=basic-inlining,
+regardless of the setting of the c++-inlining mode.
 
 ### c++-template-inlining ###
 
@@ -73,7 +76,8 @@ considered for inlining.
 
     -analyzer-config c++-template-inlining=[true | false]
 
-Currently, C++ standard library functions are NOT considered for inlining by default.
+Currently, C++ standard library functions are considered for inlining by 
+default.
 
 The standard library functions and the STL in particular are used ubiquitously
 enough that our tolerance for false positives is even lower here. A false
@@ -81,6 +85,31 @@ positive due to poor modeling of the STL leads to a poor user experience, since
 most users would not be comfortable adding assertions to system headers in order
 to silence analyzer warnings.
 
+### c++-container-inlining ###
+
+This option controls whether constructors and destructors of "container" types
+should be considered for inlining.
+
+    -analyzer-config c++-container-inlining=[true | false]
+
+Currently, these constructors and destructors are NOT considered for inlining
+by default.
+
+The current implementation of this setting checks whether a type has a member
+named 'iterator' or a member named 'begin'; these names are idiomatic in C++,
+with the latter specified in the C++11 standard. The analyzer currently does a
+fairly poor job of modeling certain data structure invariants of container-like
+objects. For example, these three expressions should be equivalent:
+
+    std::distance(c.begin(), c.end()) == 0
+    c.begin() == c.end()
+    c.empty())
+
+Many of these issues are avoided if containers always have unknown, symbolic
+state, which is what happens when their constructors are treated as opaque.
+In the future, we may decide specific containers are "safe" to model through
+inlining, or choose to model them directly using checkers instead.
+
 
 Basics of Implementation
 -----------------------