MS ABI: Use musttail for thunk IR generation

This allows us to perfectly forward non-trivial arguments that use
inalloca.

We still can't forward non-trivial arguments through thunks when we have
a covariant return type with a non-trivial adjustment.  This would
require emitting an extra copy, which is non-conforming anyway.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208927 91177308-0d34-0410-b5e6-96231b3b80d8
test/CodeGenCXX/dllexport.cpp: we already correctly emit b() even when
it's not used, because CodeGenModule::EmitGlobal consults
ASTContext::DeclMustBeEmitted via CodeGenModule::MayDeferGeneration.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208936 91177308-0d34-0410-b5e6-96231b3b80d8
InstrProf: Set profile data to visibility hidden

Shared objects are fairly broken for InstrProf right now -- a follow-up
commit in compiler-rt will fix the rest of this.

The main problem here is that at link time, profile data symbols in the
shared object might get used instead of symbols from the main
executable, creating invalid profile data sections.

<rdar://problem/16918688>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208939 91177308-0d34-0410-b5e6-96231b3b80d8
Switch another write_escaped to yaml::escape

I missed one in r206443.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208941 91177308-0d34-0410-b5e6-96231b3b80d8
Replace a fake enum class with the real thing.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208943 91177308-0d34-0410-b5e6-96231b3b80d8
Push implicitly-declared allocation functions into the IdResolver. Otherwise,
declaration merging in modules is unable to find them and we get bogus errors
and even crashes.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208944 91177308-0d34-0410-b5e6-96231b3b80d8
InstrProf: Look for the PIC-version of the profile runtime

If `-shared` is specified, pull in a PIC-version of the profile runtime,
which was added to compiler-rt in r208947.  I'm hoping this will get the
bots on my side.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208948 91177308-0d34-0410-b5e6-96231b3b80d8
Improve a scan-build message



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208951 91177308-0d34-0410-b5e6-96231b3b80d8
Update for llvm API change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208984 91177308-0d34-0410-b5e6-96231b3b80d8
Tooling: use stderr, not stdout for missing command line messages

Matches other tooling output that use stderr.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208988 91177308-0d34-0410-b5e6-96231b3b80d8
Rename SourceManager::createFileIDForMemBuffer()

It makes more sense to just overload createFileID().

Gardening only.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209002 91177308-0d34-0410-b5e6-96231b3b80d8
Merge a couple of copy-and-pasted functions

No change in functionality.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209005 91177308-0d34-0410-b5e6-96231b3b80d8
[ASTMatchers] Move the 'isImplicit' matcher from CXXConstructorDecl to Decl.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209006 91177308-0d34-0410-b5e6-96231b3b80d8
Update for llvm api change.

Now that llvm cannot represent alias cycles, we have to diagnose erros just
before trying to close the cycle. This degrades the errors a bit. The real
solution is what it was before: if we want to provide good errors for these
cases, we have to be able to find a clang level decl given a mangled name
and produce the error from Sema.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209008 91177308-0d34-0410-b5e6-96231b3b80d8
Missed a ! in the if statement when these were being set and the options
are inverted in clang and llvm.

I'll attempt to get a testcase for this that doesn't involve compiling to .s,
but it's unlikely.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209017 91177308-0d34-0410-b5e6-96231b3b80d8
Use getAliasee instead of getAliasedGlobal.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209038 91177308-0d34-0410-b5e6-96231b3b80d8
If a declaration is loaded, and then a module import adds a redeclaration, then
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.

This works as follows:
 * The 'most recent' pointer on a canonical declaration grows a pointer to the
   external AST source and a generation number (space- and time-optimized for
   the case where there is no external source).
 * Each time the 'most recent' pointer is queried, if it has an external source,
   we check whether it's up to date, and update it if not.
 * The ancillary data stored on the canonical declaration is allocated lazily
   to avoid filling it in for declarations that end up being non-canonical.
   We'll still perform a redundant (ASTContext) allocation if someone asks for
   the most recent declaration from a decl before setPreviousDecl is called,
   but such cases are probably all bugs, and are now easy to find.

Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.

Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.

Early performance benchmarks show that this makes no measurable difference to 
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209046 91177308-0d34-0410-b5e6-96231b3b80d8
Add missed file from r209046.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209047 91177308-0d34-0410-b5e6-96231b3b80d8
Tweak diagnostic wording for init list narrowing

The conventional form is '<action> to silence this warning'.

Also call the diagnostic an 'issue' rather than a 'message' because the latter
term is more widely used with reference to message expressions.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209052 91177308-0d34-0410-b5e6-96231b3b80d8
Correct incoherent function versus function template partial ordering for conversion operators (the comparison could claim that two conversion operators are both better than each other). Actually implement DR495, rather than passing its test by chance because the declarations happened to be in the "lucky" order.


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