argument but doesn't (because previous template parameters had default
arguments), clear out all of the default arguments so that we maintain
the invariant that a template parameter has a default argument only if
subsequence template parameters also have default arguments.
Fixes a crash-on-invalid <rdar://problem/8913649>.

llvm-svn: 124345

diagnostic about ref-qualifiers where they do not belong.

llvm-svn: 124344

derived-to-base cast that also casts away constness (one of the cases
for static_cast followed by const_cast) would be treated as a bit-cast
rather than a derived-to-base class, causing miscompiles and
heartburn.

Fixes <rdar://problem/8913298>.

llvm-svn: 124340

overload a function without a ref-qualifier (C++0x
[over.load]p2). This, apparently, completes the implementation of
rvalue references for *this.

llvm-svn: 124321

llvm-svn: 124319

reference binding is for the implicit object parameter of a member
function with a ref-qualifier. My previous comment, that we didn't
need to track this explicitly, was wrong: we do in fact get
rvalue-references-prefer-rvalues overloading with ref-qualifiers.

llvm-svn: 124313

for the implicit object argument to a non-static member function with
a ref-qualifier (C++0x [over.match.funcs]p4).

llvm-svn: 124311

the presence and form of a ref-qualifier. Note that we do *not* yet
implement the restriction in C++0x [over.load]p2 that requires either
all non-static functions with a given parameter-type-list to have a
ref-qualifier or none of them to have a ref-qualifier.

llvm-svn: 124297

llvm-svn: 124295

the restrictions on .* and ->* for ref-qualified pointer-to-member
functions.

llvm-svn: 124294

rules), now that we've actually have a clean build for me to sully.

llvm-svn: 124290

  - Add ref-qualifiers to the type system; they are part of the
  canonical type. Print & profile ref-qualifiers
  - Translate the ref-qualifier from the Declarator chunk for
    functions to the function type. 
  - Diagnose mis-uses of ref-qualifiers w.r.t. static member
  functions, free functions, constructors, destructors, etc.
  - Add serialization and deserialization of ref-qualifiers.

llvm-svn: 124281

after a 'return' in a CFGBlock.  This accidentally
was working before, but the false assumption that
'return' always appeared at the end of the block
was uncovered by a recent change.

llvm-svn: 124280

llvm-svn: 124276

Clairvoyance by John!

llvm-svn: 124264

in default ivar synthesis.  Fixes // rdar://8913053.

llvm-svn: 124258

llvm-svn: 124247

llvm-svn: 124244

llvm-svn: 124243

Change error "function cannot return array type" -> "blocks cannot return array type" when blocks are involved.
Addresses rdar://8876238.

llvm-svn: 124242

handling all CFGElement kinds.  While writing
the test case, it turned out that return-noreturn.cpp
wasn't actually testing anything since it has the wrong -W
flag.  That uncovered another regression with
the handling of destructors marked noreturn.  WIP.

llvm-svn: 124238

for reference binding (C++ [over.rank.ics]p3b1sb4), so that we prefer
the binding of an lvalue reference to a function lvalue over the
binding of an rvalue reference. This change resolves the ambiguity
with std::forward and lvalue references to function types in a way
that seems consistent with the original rvalue references proposal.

My proposed wording for this change is shown in
isBetterReferenceBindingKind(); we'll try to get this change adopted
in the C++0x working paper as well.

llvm-svn: 124236

authors to write 

  class __attribute__((forbid_temporaries)) Name { ... };

when they want to force users to name all variables of the type. This protects
people from doing things like creating a scoped_lock that only lives for a
single statement instead of an entire scope.

The warning produced by this attribute can be disabled by
-Wno-forbid-temporaries.

llvm-svn: 124217

(C++0x [over.ics.rank]p3) when one binding is an lvalue reference and
the other is an rvalue reference that binds to an rvalue. In
particular, we were using the predict "is an rvalue reference" rather
than "is an rvalue reference that binds to an rvalue", which was
incorrect in the one case where an rvalue reference can bind to an
lvalue: function references.

This particular issue cropped up with std::forward, where Clang was
picking an std::forward overload while forwarding an (lvalue)
reference to a function. However (and unfortunately!), the right
answer for this code is that the call to std::forward is
ambiguous. Clang now gets that right, but we need to revisit the
std::forward implementation in libc++.

llvm-svn: 124216

about uninitialized variables captured by blocks.

llvm-svn: 124213

generate meaningful [*] template argument location information.

[*] Well, as meaningful as possible, given that this entire code path
is a hack for when we've lost type-source information.

llvm-svn: 124211

llvm-svn: 124201

during template instantiation. This code needs to eventually die, but
this little tweak fixes PR8629, where bad location information slipped
through to the location of a class template instantiation.

llvm-svn: 124199

T) when taking the address of an overloaded function or matching a
specialization to a template (C++0x [temp.deduct.type]p10). Fixes
PR9044.

llvm-svn: 124197

derived-to-base conversion, set the cast kind and base path
appropriately.

llvm-svn: 124189

attributes for the benefit of the static analyzer.

llvm-svn: 124174

llvm-svn: 124153

llvm-svn: 124146

as useful in a templated context as it is without templates. Fixes PR8755!

llvm-svn: 124136

Wennborg! Fixes PR8295.

llvm-svn: 124135

llvm-svn: 124122

implementation used by overload resolution to support rvalue
references. The original commits caused PR9026 and some
hard-to-reproduce self-host breakage.

The only (crucial!) difference between this commit and the previous
commits is that we now properly check the SuppressUserConversions flag
before attempting to perform a second user-defined conversion in
reference binding, breaking the infinite recursion chain of
user-defined conversions.

Rvalue references should be working a bit better now.

llvm-svn: 124121

llvm-svn: 124087

llvm-svn: 124083

  error: no super class declared in @interface for 'XXX'

to be:

  error: 'X' cannot use 'super' because it is a root class

The latter explains what the user actually did wrong.

Fixes: <rdar://problem/8904409>
llvm-svn: 124074