This fixes <rdar://problem/6782722> XCDataTipsManager.m registers, observes notifications in class methods.

The radar above is the result of clang typing 'self' in a class method as 'Class', which results in some spurious warnings (GCC types 'self' in a class method as 'id').

I considered changing the type of 'self' to 'id' (to conform to GCC), however this resulted in *many* test cases breaking. In addition, I really prefer a more strongly typed 'self'.

All in all, this is the least obtrusive fix I could find for removing the spurious warnings (though we do loose some valid warnings).

llvm-svn: 69041

 - Pull out SetCommonAttributes, which handles the things common to
   aliases, methods, functions, and variables.

 - Pull out SetLLVMFunctionAttributesForDefinition, which handles the
   LLVM attributes which we only want to apply to a definition (like
   noinline and alwaysinline).

 - Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes
   and specialized).

 - Kill SetFunctionAttributesForDefinition (inlined into sole caller).

 - Inline SetGVDefinitionAttributes into SetMethodAttributes and
   specialize.

 - Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes.

This is supposed to be a no functionality change commit, but I may
have made a mistake.

llvm-svn: 69036

 - No functionality change.

llvm-svn: 69035

disambiguate it.
 - No functionality change.

llvm-svn: 69034

llvm-svn: 69033

not in c89 mode).

llvm-svn: 69032

inlined for some reason, then we don't want a strong or even weak
definition.

llvm-svn: 69031

llvm-svn: 69030

llvm-svn: 69029

llvm-svn: 69028

llvm-svn: 69027

llvm-svn: 69026

llvm-svn: 69025

t.c:3:8: warning: extra tokens at end of #endif directive
#endif foo
       ^
       //

Don't do this in strict-C89 mode because bcpl comments aren't 
valid there, and it is too much trouble to analyze whether
C block comments are safe.

llvm-svn: 69024

Warning to properly report that it is an import/include_next instead of
claiming it is a #include.

llvm-svn: 69023

llvm-svn: 69021

 - Exposed quite a few Sema issues and a CodeGen crash.

 - See FIXMEs in test case, and in SemaDecl.cpp (PR3983).

I'm skeptical that __private_extern__ should actually be a storage
class value. I think that __private_extern__ basically amounts to
  extern A __attribute__((visibility("hidden")))
and would be better off handled (a) as that, or (b) with an extra bit
in the VarDecl.

llvm-svn: 69020

 - No functionality change.

llvm-svn: 69019

llvm-svn: 69010

llvm-svn: 69009

llvm-svn: 69007

non-inline external definitions (and tentative definitions) that are
found at the top level. The corresponding declarations are stored in a
record in the PCH file, so that they can be provided to the
ASTConsumer (via HandleTopLevelDecl) when the PCH file is read.

llvm-svn: 69005

This was exposed as a result of something else that was recently fixed.

llvm-svn: 69004

expression or statement serialization before we can test them.

llvm-svn: 69002

llvm-svn: 68997

implies an all-zero bit pattern.

llvm-svn: 68994

llvm-svn: 68992

Northover.

llvm-svn: 68991

llvm-svn: 68990

handle the definition of __builtin_va_list on x86-64, eliminate the
forced -triple in PCH tests to get better coverage.

llvm-svn: 68988

 - No functionality change.

llvm-svn: 68987

llvm-svn: 68985

Objective-C types and record types for the moment.

llvm-svn: 68984

codegenerator bug.

llvm-svn: 68983

llvm-svn: 68982

llvm-svn: 68980

setter/getter synthesis.

llvm-svn: 68976

Fixed crasher in <rdar://problem/6780904> [irgen] Assertion failed: (Result == conversionOK && "UTF-8 to UTF-16 conversion failed"), function GetAddrOfConstantCFString, file CodeGenModule.cpp, line 1063.

Still a diagnostic related FIXME (will discuss with Daniel/Fariborz offline).

llvm-svn: 68975

llvm-svn: 68974

llvm-svn: 68972