llvm-svn: 75705

llvm-svn: 75684

llvm-svn: 75589

llvm-svn: 75446

llvm-svn: 75028

llvm-svn: 74986

Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.

llvm-svn: 74506

Timings showed no significant difference before and after the commit.

llvm-svn: 74504

The implementations of these methods can Use Decl::getASTContext() to get the ASTContext.

This commit touches a lot of files since call sites for these methods are everywhere.
I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it.

llvm-svn: 74501

  - Track implicit instantiations vs. the not-yet-supported explicit
  specializations
  - Give implicit instantiations of function templates (and member
  functions of class templates) linkonce_odr linkage.
  - Improve name mangling for function template specializations,
  including the template arguments of the instantiation and the return
  type of the function.

Note that our name-mangling is improved, but not correct: we still
don't mangle substitutions, although the manglings we produce can be
demangled.

llvm-svn: 74466

redundant, implicit instantiations of function templates and provide a
place where we can hang function template specializations.

llvm-svn: 74454

FunctionTemplateSpecializationInfo, in DeclTemplate.h. No functionality change.

llvm-svn: 74431

variables in ObjC's Next runtime mode. Next runtime also implicitly applies
'used' attribute on some of its meta-data. This results in two 
'llvm.used' arrays to be generated, and one of them is renamed to
'llvm.used1'.

llvm-svn: 74008

llvm-svn: 73812

llvm-svn: 73702

llvm-svn: 73651

preprocessor and initialize it early in clang-cc.  This
ensures that __has_builtin works in all modes, not just
when ASTContext is around.

llvm-svn: 73319

llvm-svn: 73316

llvm-svn: 73208

 - <rdar://problem/6948703> clang treats weak_import like weak

llvm-svn: 72967

function of interest, not an operand of it.

llvm-svn: 72869

llvm-svn: 72591

Found by code inspection; I haven't seen this in real-world code.

llvm-svn: 72408

llvm-svn: 71957

llvm-svn: 71937

A C++ member function always has either weak linkage (if it's inline or defined inline) or strong linkage (other cases).

llvm-svn: 71873

to allow us to support generation of deferred ctors/dtors.
It looks like codegen isn't emitting a call to the dtor in 
member-functions.cpp:test2, but when it does, its body should
get emitted.

llvm-svn: 71594

functions and methods declared inline, but not ctors/dtors or methods not declared
inline (apparently my previous patch wasn't good enough).

llvm-svn: 71591

llvm-svn: 71590

llvm-svn: 71585

llvm-svn: 71583

to go back and clean up existing uses of the bitcasted function.  This
is not just an optimization: it is required for correctness to get
always inline functions to work, see testcases in function-attributes.c.

llvm-svn: 70971

Refactor global decls to hold either a regular Decl or a CXXConstructorDecl + ctor type or a CXXDestructorDecl + dtor type.

llvm-svn: 70962

llvm-svn: 70789

llvm-svn: 70786

mode and in the presence of __gnu_inline__ attributes. This should fix
both PR3989 and PR4069.

As part of this, we now keep track of all of the attributes attached
to each declaration even after we've performed declaration
merging. This fixes PR3264.

llvm-svn: 70292

multiple declarations of the function. Should fix PR3989 and
<rdar://problem/6818429>.

llvm-svn: 69905

methods, class methods, and property implementations) and instead
place all of these entities into the DeclContext.

This eliminates more linear walks when looking for class or instance
methods and should make PCH (de-)serialization of ObjCDecls trivial
(and lazy).

llvm-svn: 69849

 - This has pros and cons, but for now the pros seem to significantly
   outway the con.

The con is that we will always need to cast in the runtime
implementation to a struct type, if we wish to access an interface
directly.

The pros are:
 - Avoid the cost of generating types which are used. Most
   manipulation of Objective-C objects is done through messages, and
   only the implementation of a class will directly access
   memory. Previously, we would convert the type even if it only
   appear as a function parameter, for example.

 - We don't need to worry about incomplete types, and
   UpdateCompletedType for interfaces is gone.

 - It becomes easier to narrow the interface to the shadow struct for
   Objective-C interfaces (so it can be eliminated).

Currently the runtimes still use the CodeGenTypes machinery to
generate the LLVM structure they need via ConvertTagDecl, but this can
eventually be replaced.

llvm-svn: 69797

extern.  Previously we would warn about it and ignore the attribute.
This is incorrect, it should be handled as a c89 "extern inline" 
function.  Many thanks to Matthieu Castet for pointing this out and
beating me over the head until I got it.

PR3988: extern inline function are not externally visible
llvm-svn: 69756