llvm-svn: 61358

DeclContext. Instead, just keep the list of currently-active
declarations and only build the OverloadedFunctionDecl when we
absolutely need it.

This is a half-step toward eliminating the need to explicitly build
OverloadedFunctionDecls that store sets of overloaded
functions. This was suggested by Argiris a while back, and it's a good
thing for several reasons: first, it eliminates the messy logic that
currently tries to keep the OverloadedFunctionDecl in sync with the 
declarations that are being added. Second, it will (eventually)
eliminate the need to allocate memory for overload sets, which could
help performance. Finally, it helps set us up for when name lookup can
return multiple (possibly ambiguous) results, as can happen with
lookup of class members in C++.

Next steps: make the IdentifierResolver store overloads as separate
entries in its list rather than replacing them with an
OverloadedFunctionDecl now, then see how far we can go toward
eliminating OverloadedFunctionDecl entirely.

llvm-svn: 61357

llvm-svn: 61356

outer-most const of pointer types.

llvm-svn: 61355

llvm-svn: 61354

llvm-svn: 61353

llvm-svn: 61352

llvm-svn: 61351

llvm-svn: 61350

llvm-svn: 61349

llvm-svn: 61348

truely deleted. These will be expanded with further checks of all of the data
structures.

llvm-svn: 61347

llvm-svn: 61346

functions.

llvm-svn: 61345

up on a profile.

llvm-svn: 61344

reallocations. We don't do cloning on MachineInstr schedule DAGs,
but this is a worthwhile sanity check regardless.

llvm-svn: 61343

llvm-svn: 61342

comment for the ScheduleDAGSDNodes class.

llvm-svn: 61341

Support conversion from a null pointer constant o any Objective-C object pointer type. Fixes rdar://problem/6463298

llvm-svn: 61340

instance methods by building print-class-info.m,
whose output is now identical to what gcc puts out.

llvm-svn: 61339

llvm-svn: 61338

llvm-svn: 61337

property in a category and to issue diagnostics
for mismatch method in some other cases.

llvm-svn: 61336

llvm-svn: 61335

llvm-svn: 61334

llvm-svn: 61333

llvm-svn: 61332

llvm-svn: 61331

llvm-svn: 61330

  - Overloading has to cope with having both static and non-static
    member functions in the overload set.
  - The call may or may not have an implicit object argument,
    depending on the syntax (x.f() vs. f()) and the context (static
    vs. non-static member function).
  - We now generate MemberExprs for implicit member access expression.
  - We now cope with mutable whenever we're building MemberExprs.

llvm-svn: 61329

llvm-svn: 61328

llvm-svn: 61327

llvm-svn: 61326

llvm-svn: 61325

llvm-svn: 61324

llvm-svn: 61323

llvm-svn: 61322

llvm-svn: 61321

llvm-svn: 61320

us to measure the effect of this optimization.

llvm-svn: 61319