Commit Graph

9 Commits

Author SHA1 Message Date
Jordan Rose a522f1cf8b Revert "[analyzer] Disable STL inlining. Blocked by PR13724."
While PR13724 is still an issue, it's not actually an issue in the STL.
We can keep this option around in case there turn out to be widespread
false positives due to poor modeling of the C++ standard library functions,
but for now we'd like to get more data.

This reverts r163633 / c6baadceec1d5148c20ee6c902a102233c547f62.

llvm-svn: 163647
2012-09-11 20:26:49 +00:00
Anna Zaks 464493fbf4 [analyzer] Disable STL inlining. Blocked by PR13724.
llvm-svn: 163633
2012-09-11 17:15:39 +00:00
Anna Zaks 1ded453e36 [analyzer] Turn stl inlining back on.
The one reported bug, which was exposed by stl inlining, is addressed in
r163558.

llvm-svn: 163574
2012-09-10 23:59:02 +00:00
Anna Zaks 5446f4dfb1 [analyzer] Add an option to enable/disable objc inlining.
llvm-svn: 163562
2012-09-10 22:56:41 +00:00
Anna Zaks 14ce52492f [analyzer] Add ipa-always-inline-size option (with 3 as the default).
The option allows to always inline very small functions, whose size (in
number of basic blocks) is set using -analyzer-config
ipa-always-inline-size option.

llvm-svn: 163558
2012-09-10 22:37:19 +00:00
Jordan Rose c6fcbf06a6 [analyzer] Make the defaults explicit for each of the new config options.
Also, document both new inlining options in IPA.txt.

llvm-svn: 163551
2012-09-10 21:54:24 +00:00
Jordan Rose 1e0e4001c8 [analyzer] For now, don't inline C++ standard library functions.
This is a (heavy-handed) solution to PR13724 -- until we know we can do
a good job inlining the STL, it's best to be consistent and not generate
more false positives than we did before. We can selectively whitelist
certain parts of the 'std' namespace that are known to be safe.

This is controlled by analyzer config option 'c++-stdlib-inlining', which
can be set to "true" or "false".

This commit also adds control for whether or not to inline any templated
functions (member or non-member), under the config option
'c++-template-inlining'. This option is currently on by default.

llvm-svn: 163548
2012-09-10 21:27:35 +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
Jordan Rose 219c9d0dd3 [analyzer] Though C++ inlining is enabled, don't inline ctors and dtors.
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
2012-08-31 17:06:49 +00:00