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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178513 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Use inline storage in the FunctionSummary DenseMap.

The summaries lasted for the lifetime of the map anyway; no reason to
include an extra allocation.

Also, use SmallBitVector instead of BitVector to track the visited basic
blocks -- most functions will have less than 64 basic blocks -- and
use bitfields for the other fields to reduce the size of the structure.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178514 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Cache whether a function is generally inlineable.

Certain properties of a function can determine ahead of time whether or not
the function is inlineable, such as its kind, its signature, or its
location. We can cache this value in the FunctionSummaries map to avoid
rechecking these static properties for every call.

Note that the analyzer may still decide not to inline a specific call to
a function because of the particular dynamic properties of the call along
the current path.

No intended functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178515 91177308-0d34-0410-b5e6-96231b3b80d8
[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.

<rdar://problem/13497258>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178516 91177308-0d34-0410-b5e6-96231b3b80d8
un-break remaining gdb buildbot testcases.
Make sure we do not generate line info for debugging-related frame setup.
Follow-up to r178361 / rdar://problem/12767564

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178517 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Teach invalidateRegions that regions within LazyCompoundVal need to be invalidated

Refactor invalidateRegions to take SVals instead of Regions as input and teach RegionStore
about processing LazyCompoundVal as a top-level “escaping” value.

This addresses several false positives that get triggered by the NewDelete checker, but the
underlying issue is reproducible with other checkers as well (for example, MallocChecker).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178518 91177308-0d34-0410-b5e6-96231b3b80d8
Add -Wstatic-local-in-inline, which warns about using a static local
variable in a C99 inline (but not static-inline or extern-inline)
function definition.

The standard doesn't actually say that this doesn't apply to
"extern inline" definitions, but that seems like a useful extension,
and it at least doesn't have the obvious flaw that a static
mutable variable in an externally-available definition does.

rdar://13535367

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