in ObjCMethods.

Extend FunctionTextRegion to represent ObjC methods as well as
functions. Note, it is not clear what type ObjCMethod region should
return. Since the type of the FunctionText region is not currently used,
defer solving this issue.

llvm-svn: 164046

llvm-svn: 163828

crazy case where dispatch_once gets redefined as a macro that calls
_dispatch_once (which calls the real dispatch_once).  Users want to
see the warning in their own code.

Fixes <rdar://problem/11617767>

llvm-svn: 163816

Thanks Jordan.

llvm-svn: 163762

in NSException to a helper object in libAnalysis that can also
be used by Sema.  Not sure if the predicate name 'isImplicitNoReturn'
is the best one, but we can massage that later.

No functionality change.

llvm-svn: 163759

Fixes a false positive found by analyzing LLVM code base.

llvm-svn: 163750

llvm-svn: 163749

llvm-svn: 163748

Again, GCC is more aggressive about reusing temporary space than we are,
leading to Release build crashes for this undefined behavior.

PR13710 (though it may not be the only problem there)

llvm-svn: 163747

Currently we don't update the dynamic type of a C++ object when it is
cast. This can cause the situation above, where the static type of the
region is now known to be a subclass of the dynamic type.

Once we start updating DynamicTypeInfo in response to the various kinds
of casts in C++, we can re-add this assert to make sure we don't miss
any cases. This work is tracked by <rdar://problem/12287087>.

In -Asserts builds, we will simply not return any runtime definition
when our DynamicTypeInfo is known to be incorrect like this.

llvm-svn: 163745

Using the static type may be inconsistent with later calls. We should just
report that there is no inlining definition available if the static type is
better than the dynamic type. See next commit.

This reverts r163644 / 19d5886d1704e24282c86217b09d5c6d35ba604d.

llvm-svn: 163744

were not emitted.

Fixes <rdar://problem/12280665>.

llvm-svn: 163683

parameter packs where the reference is not being expanded but the pack has
been. Previously, Clang would segfault in such cases.

llvm-svn: 163672

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

reinterpret_cast does not provide any of the usual type information that
static_cast or dynamic_cast provide -- only the new type. This can get us
in a situation where the dynamic type info for an object is actually a
superclass of the static type, which does not match what CodeGen does at all.
In these cases, just fall back to the static type as the best possible type
for devirtualization.

Should fix the crashes on our internal buildbot.

llvm-svn: 163644

llvm-svn: 163633

C++11 [expr.call]p1: ...If the selected function is non-virtual, or if the
  id-expression in the class member access expression is a qualified-id,
  that function is called. Otherwise, its final overrider in the dynamic type
  of the object expression is called.

<rdar://problem/12255556>

llvm-svn: 163577

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

llvm-svn: 163574

depth.

We only want to count how many substantial functions we inlined. This
is an improvement to r163558.

llvm-svn: 163571

llvm-svn: 163562

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

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

llvm-svn: 163551

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

llvm-svn: 163546

llvm-svn: 163533

llvm-svn: 163531

I need to see how this breaks on other platforms when I fix the issue
that Benjamin Kramer pointed out.

This includes r163489 and r163490, plus a two line change.

llvm-svn: 163512

llvm-svn: 163505

r163489, "Take another crack at stabilizing the emission order of analyzer"
r163490, "Use isBeforeInTranslationUnitThan() instead of operator<."

llvm-svn: 163497

llvm-svn: 163490

diagnostics without using FoldingSetNodeIDs.  This is done
by doing a complete recursive comparison of the PathDiagnostics.

Note that the previous method of comparing FoldingSetNodeIDs did
not end up relying on unstable things such as pointer addresses, so
I suspect this may still have some issues on various buildbots because
I'm not sure if the true source of non-determinism has been eliminated.
The tests pass for me, so the only way to know is to commit this change
and see what happens.

llvm-svn: 163489

llvm-svn: 163487

llvm-svn: 163479

PathDiagnosticEventPieces were *always* pruned.  Instead, they
are suppose to only be pruned if the entire call gets pruned.

llvm-svn: 163460

of the analyzer by using the FullProfile() of a PathDiagnostic
for ordering them.

llvm-svn: 163455

ObjCSelfInitChecker stashes information in the GDM to persist it across
function calls; it is stored in pre-call checks and retrieved post-call.
The post-call check is supposed to clear out the stored state, but was
failing to do so in cases where the call did not have a symbolic return
value.

This was actually causing the inappropriate cache-out from r163361.
Per discussion with Anna, we should never actually cache out when
assuming the receiver of an Objective-C message is non-nil, because
we guarded that node generation by checking that the state has changed.
Therefore, the only states that could reach this exact ExplodedNode are
ones that should have merged /before/ making this assumption.

r163361 has been reverted and the test case removed, since it won't
actually test anything interesting now.

llvm-svn: 163449

No functionality change.

llvm-svn: 163448

llvm-svn: 163446

llvm-svn: 163445

Previously, we'd just keep constraints around forever, which means we'd
never be able to merge paths that differed only in constraints on dead
symbols.

Because we now allow constraints on symbolic expressions, not just single
symbols, this requires changing SymExpr::symbol_iterator to include
intermediate symbol nodes in its traversal, not just the SymbolData leaf
nodes.

llvm-svn: 163444