for floats, and also check if 'nil' is declared
when suggesting it for initializing ObjC pointers.

llvm-svn: 124004

as an rvalue per C++0x [class.copy]p33. If that fails, try again with
the original subexpression.

llvm-svn: 124002

llvm-svn: 123996

to suggest initializations for pointer and
ObjC pointer types.

llvm-svn: 123995

to issue the warning at an uninitialized variable's
declaration, but to issue notes at possible
uninitialized uses (which could be multiple).

llvm-svn: 123994

when returning an NRVO candidate expression. For example, this
properly picks the move constructor when dealing with code such as

  MoveOnlyType f() { MoveOnlyType mot; return mot; }

The previously-XFAIL'd rvalue-references test case now works, and has
been moved into the appropriate paragraph-specific test case.

llvm-svn: 123992

llvm-svn: 123983

NRVO candidate for a return statement, to
Sema::getCopyElisionCandidate(), and teach it enough to also determine
the NRVO candidate for a throw expression. We still don't use the
latter information, however.

Along the way, implement core issue 1148, which eliminates copy
elision from catch parameters and clarifies that copy elision cannot
occur from function parameters (which we already implemented).

llvm-svn: 123982

f(T&) and f(T&&).

llvm-svn: 123981

reference to an rvalue rather than binding a const-qualified lvalue
reference to that rvalue.

llvm-svn: 123979

llvm-svn: 123978

resolution to match the latest C++0x working paper's semantics. The
implementation now matching up with the reference-binding
implementation used for initialization.

llvm-svn: 123977

call (C++0x [temp.deduct.call]p3).

As part of this, start improving the reference-binding implementation
used in the computation of implicit conversion sequences (for overload
resolution) to reflect C++0x semantics. It still needs more work and
testing, of course.

llvm-svn: 123966

This allows us to simplify the handling for the overloadable attribute,
removing a number of FIXMEs.

llvm-svn: 123961

llvm-svn: 123960

Inheritable attributes on declarations may be inherited by any later
redeclaration at merge time.  By contrast, a non-inheritable attribute
will not be inherited by later redeclarations.  Non-inheritable
attributes may be semantically analysed early, allowing them to
influence the redeclaration/overloading process.

Before this change, the "overloadable" attribute received special
handling to be treated as non-inheritable, while all other attributes
were treated as inheritable.  This patch generalises the concept,
while removing a FIXME.  Some CUDA location attributes are also marked
as non-inheritable in order to support special overloading semantics
(to be introduced in a later patch).

The patch introduces a new Attr subclass, InheritableAttr, from
which all inheritable attributes derive.  Non-inheritable attributes
simply derive from Attr.

N.B. I did not review every attribute to determine whether it should
be marked non-inheritable.  This can be done later on an incremental
basis, as this change does not affect default functionality.

llvm-svn: 123959

reference to an lvalue.

llvm-svn: 123953

specification. In particular, an rvalue reference can bind to an
initializer expression that is an lvalue if the referent type and the
initializer expression type are not reference-related. This is a newer
formulation to the previous "rvalue references can never bind to
lvalues" rule.

llvm-svn: 123952

type checking based on the actual reference type we're trying to bind
the result to, rather than stripping the reference.

llvm-svn: 123950

llvm-svn: 123948

llvm-svn: 123947

working paper's structure. The only functional change here is that we
now handling binding to array rvalues, which we would previously reject.

llvm-svn: 123918

llvm-svn: 123916

involving rvalue references, to start scoping out what is and what
isn't implemented. In the process, tweak some standards citations,
type desugaring, and teach the tentative parser about && in
ptr-operator.

llvm-svn: 123913

When instantiating member functions, propagate whether the member function is marked 'final' and 'override'.

Also, call CheckOverrideControl when instantiating member functions.

llvm-svn: 123900

llvm-svn: 123894

llvm-svn: 123893

llvm-svn: 123888

llvm-svn: 123882

llvm-svn: 123878

failed to find a case where an enum context would make a difference, but
found PR9007 on the way.

llvm-svn: 123871

declaration that name lookup actually found, so that we can use it for
access checking later on. Fixes <rdar://problem/8876150>.

llvm-svn: 123867

so allow it to propagate the failure outward. Fixes the crashing part
of <rdar://problem/8876150>.

llvm-svn: 123863

overload resolution, so that we only use that number of call arguments
for partial ordering. Fixes PR9006, a recent regression.

llvm-svn: 123861

ExtWarn. We want variadic templates to be usable in libc++/libstdc++
headers even when we're in C++98/03 mode, since it's the only clean
way to implement TR1 <functional>.

llvm-svn: 123852

together. In particular: 
  - Handle the use of captured parameter pack names within blocks
  (BlockDeclRefExpr understands parameter packs now)
  - Handle the declaration and expansion of parameter packs within a block's
  parameter list, e.g., ^(Args ...args) { ... })
  - Handle instantiation of blocks where the return type was not
  explicitly specified. (unrelated, but necessary for my tests).

Together, these fixes should make blocks and variadic templates work
reasonably well together. Note that BlockDeclRefExpr is still broken
w.r.t. its computation of type and value dependence, which will still
cause problems for blocks in templates.

llvm-svn: 123849

a pack expansion, e.g., the parameter pack Values in:

  template<typename ...Types>
  struct Outer {
    template<Types ...Values>
    struct Inner;
  };

This new implementation approach introduces the notion of an
"expanded" non-type template parameter pack, for which we have already
expanded the types of the parameter pack (to, say, "int*, float*",
for Outer<int*, float*>) but have not yet expanded the values. Aside
from creating these expanded non-type template parameter packs, this
patch updates template argument checking and non-type template
parameter pack instantiation to make use of the appropriate types in
the parameter pack.

llvm-svn: 123845

in pretending otherwise.

llvm-svn: 123839

a typo for !=). Fixes PR9001, from Hans Wennborg!

llvm-svn: 123836

there's a respectable point of instantiation.  Also, make sure we do
this operation even when instantiating a dependently-typed variable.

llvm-svn: 123818