Bug Fix: Template explicit instantiations should not have definitions (FixIts yet to be tested.)

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@184503 91177308-0d34-0410-b5e6-96231b3b80d8
When building a module, keep *all* declared methods in the global method pool.

As an optimization, we only kept declared methods with distinct
signatures in the global method pool, to keep the method lists
small. Under modules, however, one could have two different methods
with the same signature that occur in different (sub)modules. If only
the later submodule is important, message sends to 'id' with that
selector would fail because the first method (the only one that got
into the method pool) was hidden. When building a module, keep *all*
of the declared methods.

I did a quick check of both module build time and uses of modules, and
found no performance regression despite this causing us to keep more
methods in the global method pool. Fixes <rdar://problem/14148896>.


git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@184504 91177308-0d34-0410-b5e6-96231b3b80d8
Add test header missing from r184504.


git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@184505 91177308-0d34-0410-b5e6-96231b3b80d8
Alternative fix for r184473.

This just seems a bit tidier/more principled. Based on a patch provided
by Adrian - with the only minor tweak that it needed to use
"getTypeOrNull" rather than "getCompletedTypeOrNull" since we don't
store declarations in the CompletedTypes cache.

No intended functionality change.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@184509 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Fix stale comment in CallEvent.

No functionality change.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@184510 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Handle zeroing CXXConstructExprs.

Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.

As a bonus, trivial default constructors are now no longer inlined; they
are instead processed explicitly by ExprEngine. This has a (positive)
effect on the generated path edges: they no longer stop at a default
constructor call unless there's a user-provided implementation.

<rdar://problem/14212563>

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