History log of /external/clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
ef8225444452a1486bd721f3285301fe84643b00 21-Jul-2014 Stephen Hines <srhines@google.com> Update Clang for rebase to r212749.

This also fixes a small issue with arm_neon.h not being generated always.

Includes a cherry-pick of:
r213450 - fixes mac-specific header issue
r213126 - removes a default -Bsymbolic on Android

Change-Id: I2a790a0f5d3b2aab11de596fc3a74e7cbc99081d
6bcf27bb9a4b5c3f79cb44c0e4654a6d7619ad89 29-May-2014 Stephen Hines <srhines@google.com> Update Clang for 3.5 rebase (r209713).

Change-Id: I8c9133b0f8f776dc915f270b60f94962e771bc83
651f13cea278ec967336033dd032faef0e9fc2ec 24-Apr-2014 Stephen Hines <srhines@google.com> Updated to Clang 3.5a.

Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
50fa64d4411a42e0b4f373a84d8d4f5cbf339ea3 17-May-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Don't inline ~shared_ptr.

The analyzer can't see the reference count for shared_ptr, so it doesn't
know whether a given destruction is going to delete the referenced object.
This leads to spurious leak and use-after-free warnings.

For now, just ban destructors named '~shared_ptr', which catches
std::shared_ptr, std::tr1::shared_ptr, and boost::shared_ptr.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182071 91177308-0d34-0410-b5e6-96231b3b80d8
d95b70175646829c26344d5f0bda1ec3009f2a5b 17-May-2013 Anna Zaks <ganna@apple.com> [analyzer] Add an option to use the last location in the main source file as the report location.

Previously, we’ve used the last location of the analyzer issue path as the location of the
report. This might not provide the best user experience, when one analyzer a source
file and the issue appears in the header. Introduce an option to use the last location
of the path that is in the main source file as the report location.

New option can be enabled with -analyzer-config report-in-main-source-file=true.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182058 91177308-0d34-0410-b5e6-96231b3b80d8
b11a9086ebaf8e081daa8a6cd94ea99c97c027d2 05-Apr-2013 Jordan Rose <jordan_rose@apple.com> [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'


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178805 91177308-0d34-0410-b5e6-96231b3b80d8
c63a460d78a7625ff38d2b3580f78030c44f07db 02-Apr-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] For now, don't inline [cd]tors of C++ containers.

This is a heuristic to make up for the fact that the analyzer doesn't
model C++ containers very well. One example is modeling that
'std::distance(I, E) == 0' implies 'I == E'. In the future, it would be
nice to model this explicitly, but for now it just results in a lot of
false positives.

The actual heuristic checks if the base type has a member named 'begin' or
'iterator'. If so, we treat the constructors and destructors of that type
as opaque, rather than inlining them.

This is intended to drastically reduce the number of false positives
reported with experimental destructor support turned on. We can tweak the
heuristic in the future, but we'd rather err on the side of false negatives
for now.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178516 91177308-0d34-0410-b5e6-96231b3b80d8
a12643622ad3b85972dfdd80fe9006a3e8d8fb80 02-Apr-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Allow suppressing diagnostics reported within the 'std' namespace

This is controlled by the 'suppress-c++-stdlib' analyzer-config flag.
It is currently off by default.

This is more suppression than we'd like to do, since obviously there can
be user-caused issues within 'std', but it gives us the option to wield
a large hammer to suppress false positives the user likely can't work

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178513 91177308-0d34-0410-b5e6-96231b3b80d8
0f5c5c60e9806d13f0907cd99d7204ffab0e08f7 29-Mar-2013 Ted Kremenek <kremenek@apple.com> Add static analyzer support for conditionally executing static initializers.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178318 91177308-0d34-0410-b5e6-96231b3b80d8
02a88c3edf1aeb9580e0b6e444b30c52846a673c 29-Mar-2013 Ted Kremenek <kremenek@apple.com> 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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178317 91177308-0d34-0410-b5e6-96231b3b80d8
713e07591995d761f65c7132289dce003a29870f 06-Mar-2013 Anna Zaks <ganna@apple.com> [analyzer] IDC: Add config option; perform the idc check on first “null node” rather than last “non-null”.

The second modification does not lead to any visible result, but, theoretically, is what we should
have been looking at to begin with since we are checking if the node was assumed to be null in
an inlined function.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176576 91177308-0d34-0410-b5e6-96231b3b80d8
a11f22f60673c6c9556976b49e64bf7fa751f4eb 27-Feb-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Turn on C++ constructor inlining by default.

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.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176200 91177308-0d34-0410-b5e6-96231b3b80d8
dc84cd5efdd3430efb22546b4ac656aa0540b210 20-Feb-2013 David Blaikie <dblaikie@gmail.com> Include llvm::Optional in clang/Basic/LLVM.h

Post-commit CR feedback from Jordan Rose regarding r175594.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175679 91177308-0d34-0410-b5e6-96231b3b80d8
ac3a3e7a402cd349dd2b7d70cd92c5fe702ae831 30-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Make shallow mode more shallow.

Redefine the shallow mode to inline all functions for which we have a
definite definition (ipa=inlining). However, only inline functions that
are up to 4 basic blocks large and cut the max exploded nodes generated
per top level function in half.

This makes shallow faster and allows us to keep inlining small
functions. For example, we would keep inlining wrapper functions and

With the new shallow, it takes 104s to analyze sqlite3, whereas
the deep mode is 658s and previous shallow is 209s.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173958 91177308-0d34-0410-b5e6-96231b3b80d8
6bbe1442a5f3f5f761582a9005e9edf1d49c4da2 30-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Use analyzer config for max-inlinable-size option.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173957 91177308-0d34-0410-b5e6-96231b3b80d8
ce32890df08387b50a960f785da79ac5582b7f74 30-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Remove further references to analyzer-ipa.

Thanks Jordan!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173955 91177308-0d34-0410-b5e6-96231b3b80d8
aeca2cc3a6f486abff3fdfb4e82903cd3ca4267e 26-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Add 'prune-paths' config option to disable path pruning.

This should be used for testing only. Path pruning is still on by default.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173545 91177308-0d34-0410-b5e6-96231b3b80d8
7ee8906295d56ceb84b8b3da502cdc8770509868 26-Jan-2013 Jordan Rose <jordan_rose@apple.com> [analyzer] Rename PruneNullReturnPaths to SuppressNullReturnPaths.

"Prune" is the term for eliminating pieces of a path that are not
relevant to the user. "Suppress" means don't show that path at all.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173544 91177308-0d34-0410-b5e6-96231b3b80d8
d130140cb7bce73b4350c5d50495443abe38418a 25-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Add "-analyzer-config mode=[deep|shallow] ".

The idea is to introduce a higher level "user mode" option for
different use scenarios. For example, if one wants to run the analyzer
for a small project each time the code is built, they would use
the "shallow" mode.

The user mode option will influence the default settings for the
lower-level analyzer options. For now, this just influences the ipa
modes, but we plan to find more optimal settings for them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173386 91177308-0d34-0410-b5e6-96231b3b80d8
bfa9ab8183e2fdc74f8633d758cb0c6201314320 25-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Replace "-analyzer-ipa" with "-analyzer-config ipa".

The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173385 91177308-0d34-0410-b5e6-96231b3b80d8
73f0563009a6715a5d3d41f664f5bfab5096d51f 25-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] refactor: access IPAMode through the accessor.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173384 91177308-0d34-0410-b5e6-96231b3b80d8
cfa88f893915ceb8ae4ce2f17c46c24a4d67502f 12-Jan-2013 Dmitri Gribenko <gribozavr@gmail.com> Remove useless 'llvm::' qualifier from names like StringRef and others that are
brought into 'clang' namespace by clang/Basic/LLVM.h

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172323 91177308-0d34-0410-b5e6-96231b3b80d8
7959671d456c916706a5f61af609d8f1fc95decf 17-Dec-2012 Anna Zaks <ganna@apple.com> [analyzer] Implement "do not inline large functions many times"
performance heuristic

After inlining a function with more than 13 basic blocks 32 times, we
are not going to inline it anymore. The idea is that inlining large
functions leads to drastic performance implications. Since the function
has already been inlined, we know that we've analyzed it in many

The following metrics are used:
- Large function is a function with more than 13 basic blocks (we
should switch to another metric, like cyclomatic complexity)
- We consider that we've inlined a function many times if it's been
inlined 32 times. This number is configurable with -analyzer-config

This heuristic addresses a performance regression introduced with
inlining on one benchmark. The analyzer on this benchmark became 60
times slower with inlining turned on. The heuristic allows us to analyze
it in 24% of the time. The performance improvements on the other
benchmarks I've tested with are much lower - under 10%, which is

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170361 91177308-0d34-0410-b5e6-96231b3b80d8
55fc873017f10f6f566b182b70f6fc22aefa3464 04-Dec-2012 Chandler Carruth <chandlerc@gmail.com> Sort all of Clang's files under 'lib', and fix up the broken headers

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
6a329ee7567cf3267ffab2bc755ea8c773d967e7 29-Oct-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] New option to not suppress null return paths if an argument is null.

Our one basic suppression heuristic is to assume that functions do not
usually return NULL. However, when one of the arguments is NULL it is
suddenly much more likely that NULL is a valid return value. In this case,
we don't suppress the report here, but we do attach /another/ visitor to
go find out if this NULL argument also comes from an inlined function's
error path.

This new behavior, controlled by the 'avoid-suppressing-null-argument-paths'
analyzer-config option, is turned off by default. Turning it on produced
two false positives and no new true positives when running over LLVM/Clang.

This is one of the possible refinements to our suppression heuristics.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166941 91177308-0d34-0410-b5e6-96231b3b80d8
4d9e497a2b1eab3b1214848216050c64fc3acfd6 24-Oct-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Replace -analyzer-no-eagerly-trim-egraph with graph-trim-interval.

After every 1000 CFGElements processed, the ExplodedGraph trims out nodes
that satisfy a number of criteria for being "boring" (single predecessor,
single successor, and more). Rather than controlling this with a cc1 option,
which can only disable this behavior, we now have an analyzer-config option,
'graph-trim-interval', which can change this interval from 1000 to something
else. Setting the value to 0 disables reclamation.

The next commit relies on this behavior to actually test anything.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166528 91177308-0d34-0410-b5e6-96231b3b80d8
86e7b7e4421eacdd5ae610a0fb2d8ea5dec5e644 02-Oct-2012 Ted Kremenek <kremenek@apple.com> Silence -Wunused-value warning.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165059 91177308-0d34-0410-b5e6-96231b3b80d8
48d05e6d776f4b68f3db4016eb5680ac041c2b7d 02-Oct-2012 Ted Kremenek <kremenek@apple.com> Refactor clients of AnalyzerOptions::getBooleanOption() to have
an intermediate helper method to query and populate the Optional value.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165043 91177308-0d34-0410-b5e6-96231b3b80d8
94bb74cef72a33d77c5d6739abfc0840c781eb8e 02-Oct-2012 Ted Kremenek <kremenek@apple.com> Tweak AnalyzerOptions::getOptionAsInteger() to populate the string
table, making it printable with the ConfigDump checker. Along the
way, fix a really serious bug where the value was getting parsed
from the string in code that was in an assert() call. This means
in a Release-Asserts build this code wouldn't work as expected.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165041 91177308-0d34-0410-b5e6-96231b3b80d8
9e28fe60bbfa5de196ce4aa396210bf10fc5c266 02-Oct-2012 Ted Kremenek <kremenek@apple.com> Change AnalyzerOptions::mayInlineCXXMemberFunction to default populate
the config string table. Also setup a test for dumping the analyzer
configuration for C++.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165040 91177308-0d34-0410-b5e6-96231b3b80d8
622b6fb0a1d280c16e135c7e427b79cafffbde1f 01-Oct-2012 Ted Kremenek <kremenek@apple.com> 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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164954 91177308-0d34-0410-b5e6-96231b3b80d8
b9d4e5e3bb235f1149e99d3c833ff7cb3474c9f1 22-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Suppress bugs whose paths go through the return of a null pointer.

This is a heuristic intended to greatly reduce the number of false
positives resulting from inlining, particularly inlining of generic,
defensive C++ methods that live in header files. The suppression is
triggered in the cases where we ask to track where a null pointer came
from, and it turns out that the source of the null pointer was an inlined
function call.

This change brings the number of bug reports in LLVM from ~1500 down to
around ~300, a much more manageable number. Yes, some true positives may
be hidden as well, but from what I looked at the vast majority of silenced
reports are false positives, and many of the true issues found by the
analyzer are still reported.

I'm hoping to improve this heuristic further by adding some exceptions
next week (cases in which a bug should still be reported).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164449 91177308-0d34-0410-b5e6-96231b3b80d8
938869941e5a01049fb301fbf82f3caa4c7efa09 21-Sep-2012 Ted Kremenek <kremenek@apple.com> Re-enable faux-bodies by default.

Try this again, now that r164392 is in place.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164393 91177308-0d34-0410-b5e6-96231b3b80d8
1cc9a80f8df979d5ff26739ebf3c134c4e6a4ed0 21-Sep-2012 NAKAMURA Takumi <geek4civic@gmail.com> Revert r164364, "Flip "faux-bodies" in the analyzer on by default to flush out bugs."

It crashed test/Analysis/Output/blocks.m on some hosts.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164368 91177308-0d34-0410-b5e6-96231b3b80d8
85cb7a5696f93f8b98604d3e72525921a32537f0 21-Sep-2012 Ted Kremenek <kremenek@apple.com> Flip "faux-bodies" in the analyzer on by default to flush out bugs.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164364 91177308-0d34-0410-b5e6-96231b3b80d8
a43df9539644bf1c258e12710cd69d79b0b078cd 21-Sep-2012 Ted Kremenek <kremenek@apple.com> 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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164339 91177308-0d34-0410-b5e6-96231b3b80d8
e9f1f234932e80bb83be9b094e163ca4c47a3086 11-Sep-2012 Jordan Rose <jordan_rose@apple.com> 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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163647 91177308-0d34-0410-b5e6-96231b3b80d8
c6baadceec1d5148c20ee6c902a102233c547f62 11-Sep-2012 Anna Zaks <ganna@apple.com> [analyzer] Disable STL inlining. Blocked by PR13724.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163633 91177308-0d34-0410-b5e6-96231b3b80d8
e08dcbe75eb9b3ffe6f1f60ac2b216b4c878606a 11-Sep-2012 Anna Zaks <ganna@apple.com> [analyzer] Turn stl inlining back on.

The one reported bug, which was exposed by stl inlining, is addressed in

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163574 91177308-0d34-0410-b5e6-96231b3b80d8
57330eed3fbe530cb05996e4a346cc5fc217c0d9 11-Sep-2012 Anna Zaks <ganna@apple.com> [analyzer] Add an option to enable/disable objc inlining.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163562 91177308-0d34-0410-b5e6-96231b3b80d8
7229d0011766c174beffe6a846d78f448f845b39 11-Sep-2012 Anna Zaks <ganna@apple.com> [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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163558 91177308-0d34-0410-b5e6-96231b3b80d8
978869aa6e31a4bc6afdf5446ffb717aad3f7d97 10-Sep-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Make the defaults explicit for each of the new config options.

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
81fb50e8b120fc95dc0245b4112972d4d7cca3b5 10-Sep-2012 Jordan Rose <jordan_rose@apple.com> [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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163548 91177308-0d34-0410-b5e6-96231b3b80d8
5a1ffe98b04120846a15f7105905b5f363b08635 06-Sep-2012 Jordan Rose <jordan_rose@apple.com> [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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163264 91177308-0d34-0410-b5e6-96231b3b80d8
de5277fc555551857602bd7a7e5e616274e2d4a6 31-Aug-2012 Jordan Rose <jordan_rose@apple.com> [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'.

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