llvm-svn: 83328

extension class's protocol list so its AST is complete.
2) Because of this no need to issue warning on unimplemeted
methods coming from the extended class protocols
because warning is issued when class definition is seen.

llvm-svn: 83326

assume that PCH files from different Clang revisions are not
compatible. Addresses <rdar://problem/7266572>.

llvm-svn: 83323

<rdar://problem/7269631> Protocols on class extensions don't work

llvm-svn: 83322

branch/revision information. Use that information in the driver,
rather than one-off branch/revision computation. 

llvm-svn: 83321

llvm-svn: 83319

llvm-svn: 83303

llvm-svn: 83272

llvm-svn: 83271

llvm-svn: 83268

llvm-svn: 83267

llvm-svn: 83266

llvm-svn: 83265

llvm-svn: 83264

llvm-svn: 83263

llvm-svn: 83235

llvm-svn: 83232

llvm-svn: 83231

When building constant structs, check if the resulting LLVM struct will be bigger than the record layout size and use a packed struct if that's the case. Fixes PR5108.

llvm-svn: 83230

explicit instantiation. Also, tighten up reference-count checking to
help catch these issues earlier. Fixes PR5069.

llvm-svn: 83225

- Add ObjCInterfaceDecl::lookupPrivateInstanceMethod().
- Convert clients.

No functionality change - One less method in Sema:-)

llvm-svn: 83224

of the flow-control checks for falling off the end of a function,
since the return type may instantiate to void. Similarly, if a
return statement has an expression and the return type of the function
is void, don't complain if the expression is type-dependent, since
that type could instantiate to void.

Fixes PR5071.

llvm-svn: 83222

llvm-svn: 83221

deciding const of null pointer conversion. Fixes PR5086.

llvm-svn: 83217

functions when they are explicitly declared, e.g., via a function
template specialization or explicit template instantiation
declaration. Don't try to synthesize bodies for the special member
functions in this case; rather, check whether we have an implicit
declaration and, if so, synthesize the appropriate function
body. Fixes PR5084.

llvm-svn: 83212

user-defined type conversion. Fixes PR5040.

llvm-svn: 83211

Patch by Rafael Espindola.

llvm-svn: 83209

llvm-svn: 83204

-fno-exceptions in C++ code. We used to always define __EXCEPTIONS in
C++.

llvm-svn: 83199

llvm-svn: 83195

BlockDeclRefDecls.

llvm-svn: 83185

apparently because using directives aren't quite working correctly.

llvm-svn: 83184

type is a template-id (e.g., basic_ostream<CharT, Traits>) and the
argument type is a class that has a derived class matching the
parameter type. Previously, we were giving up on template argument
deduction too early.

llvm-svn: 83177

overload candidates (but not the built-in ones). We still rely on the
underlying built-in semantic analysis to produce the initial
diagnostic, then print the candidates following that diagnostic. 

One side advantage of this approach is that we can perform more validation
of C++'s operator overloading with built-in candidates vs. the
semantic analysis for those built-in operators: when there are no
viable candidates, we know to expect an error from the built-in
operator handling code. Otherwise, we are not modeling the built-in
semantics properly within operator overloading. This is checked as:

      assert(Result.isInvalid() && 
             "C++ binary operator overloading is missing
             candidates!");
      if (Result.isInvalid())
        PrintOverloadCandidates(CandidateSet, /*OnlyViable=*/false);

The assert() catches cases where we're wrong in a +Asserts build. The
"if" makes sure that, if this happens in a production clang
(-Asserts), we still build the proper built-in operator and continue
on our merry way. This is effectively what happened before this
change, but we've added the assert() to catch more flies.

llvm-svn: 83175

a bad initializer. Fixes pr4274.

llvm-svn: 83169

Add an error for function parameters that have a qualified address space since this is not allowed by the embedded c extension spec.

llvm-svn: 83165

llvm-svn: 83153

<rdar://problem/7263113> Make clang produce gcc's objc_assign_StrongCast as a result of type-cast of an ivar in assignment.

llvm-svn: 83150

scheme, we can switch the previous scheme over to using this code
path.  There's a bit of simplifications yet to do as well.

llvm-svn: 83138

unbounded chains of operator-> delegations.

llvm-svn: 83134