llvm-svn: 99394

llvm-svn: 99392

llvm-svn: 99391

  template <> friend void foo(int);
we need to change it to
  friend void foo<>(int);
or else the user won't get the template specialization they obviously want.

llvm-svn: 99390

llvm-svn: 99389

that was present in a prior declaration, emit a warning rather than a
hard error (which we did before, and still do with mismatched
exception specifications). Moreover, provide a fix-it hint with the
throw() clause that should be added, e.g.,

t.C:10:7: warning: 'operator new' is missing exception specification
      'throw(std::bad_alloc)'
void *operator new(unsigned long sz)
      ^
                                     throw(std::bad_alloc)

As part of this, disable the warning when we're missing an exception
specification on operator new, operator new[], operator delete, or
operator delete[] when exceptions are turned off (-fno-exceptions).

Fixes PR5957.

llvm-svn: 99388

llvm-svn: 99385

llvm-svn: 99384

templates.  So delay access-control diagnostics when (for example) the target
of a friend declaration is a specific specialization of a template.

I was surprised to find that this was required for an access-controlled selfhost.

llvm-svn: 99383

operators, make sure that the implicitly-declared global new and
delete operators are always available. Fixes PR5904.

llvm-svn: 99382

llvm-svn: 99381

llvm-svn: 99380

llvm-svn: 99378

scope. Fixes PR6619.

llvm-svn: 99377

llvm-svn: 99376

and defining the add pattern with Pat<>, eliminating a use of
parallel.

llvm-svn: 99375

llvm-svn: 99374

respectively, and add some more comment.

llvm-svn: 99373

llvm-svn: 99372

data it contains (similar to GetStringMapEntryFromValue).  
Patch by Greg Clayton!

llvm-svn: 99371

llvm-svn: 99370

ISD node.  The only change in the generated isel code are comments
like:

<                 // Src: (X86dec_flag:i16 GR16:i16:$src)
---
>                 // Src: (X86dec_flag:i16:i32 GR16:i16:$src)

because now it knows that X86dec_flag returns both an i16 (for the result)
and an i32 (for EFLAGS) in this case.  Wewt.

llvm-svn: 99369

each namespace, even when the outer namespace has multiple
definitions. As part of this, collapsed two pointers worth of storage
(original namespace and inner anonymous namespace) into a single
pointer with a distinguishing bit, since the two are mutually
exclusive, saving a pointer per NamespaceDecl. Fixes PR6620.

llvm-svn: 99368

llvm-svn: 99367

in some more places.

llvm-svn: 99366

llvm-svn: 99365

llvm-svn: 99364

llvm-svn: 99363

llvm-svn: 99362

based on a suggestion by Jochen Wilhelmy.

llvm-svn: 99361

llvm-svn: 99360

llvm-svn: 99359

llvm-svn: 99358

instead of reimplementing it wrong and poorly.

llvm-svn: 99357

test run permformance numbers say as to whether it helps.

llvm-svn: 99355

llvm-svn: 99354

llvm-svn: 99353

This reverts commit 99345. It was breaking buildbots.

llvm-svn: 99352

function within a class hierarchy (C++ [class.virtual]p2).

We use the final-overrider computation to determine when a particular
class is ill-formed because it has multiple final overriders for a
given virtual function (e.g., because two virtual functions override
the same virtual function in the same virtual base class). Fixes
PR5973.

We also use the final-overrider computation to determine which virtual
member functions are pure when determining whether a class is
abstract or diagnosing the improper use of an abstract class. The
prior approach to determining whether there were any pure virtual
functions in a class didn't cope with virtual base class subobjects
properly, and could not easily be fixed to deal with the oddities of
subobject hiding. Fixes PR6631.

llvm-svn: 99351

llvm-svn: 99350