explicitly-specified template arguments are enough to determine the
instantiation, and either template argument deduction fails or is not
performed in that context, we can resolve the template-id down to a
function template specialization (so sayeth C++0x
[temp.arg.explicit]p3). Fixes PR5811.

llvm-svn: 91852

not deduce an "overload" type. Such a deduction indicates a failure in
semantic analysis  (e.g., PR5811) that currently isn't caught until
code-generation time. This assertions makes it clearer that this
particular issue is a semantic-analysis problem, not a code-gen problem.

llvm-svn: 91844

recursing in CGDebugInfo::CreateTypeNode, teach
CanonicalizeTypeForDebugInfo---now called UnwrapTypeForDebugInfo---to
keep unwrapping the type until we hit something that can be
represented by debug information. Thanks to Anders for pointing this out!

llvm-svn: 91840

ElaboratedType, QualifiedNameType, and SubstTemplateTypeParmType type
nodes. Also, produce an "unsupported" diagnostic for C++0x type nodes
and "typeof" nodes, rather than asserting nondescriptly.

llvm-svn: 91837

object.

llvm-svn: 91830

as a g++ extension (fixes radar 7481987).

llvm-svn: 91827

support diagnostics and error recovery.

llvm-svn: 91825

llvm-svn: 91818

Sema::getTypeName.

"LookupNestedNameSpecifierName" isn't quite the right kind of lookup, though; 
it doesn't ignore namespaces.  Someone more familiar with the lookup code
should fix this properly.

llvm-svn: 91809

llvm-svn: 91808

llvm-svn: 91807

llvm-svn: 91806

llvm-svn: 91805

llvm-svn: 91804

llvm-svn: 91803

llvm-svn: 91802

pull ':' eating out of ParseAsmOperandsOpt.

llvm-svn: 91801

llvm-svn: 91800

Rework the way pointer types are handled by the RTTI builder. We now get the right linkage for indirect pointers to incomplete structs.

llvm-svn: 91799

assignment.

llvm-svn: 91798

llvm-svn: 91797

Switch default-initialization of variables of class type (or array thereof) over to InitializationSequence. I could swear that this fixes a PR somewhere, but I couldn't figure out which one

llvm-svn: 91796

llvm-svn: 91795

llvm-svn: 91794

Because of the rules of base-class lookup* and the restrictions on typedefs, it
was actually impossible for this to cause any problems more serious than the
spurious acceptance of
  template <class T> class A : B<A> { ... };
instead of
  template <class T> class A : B<A<T> > { ... };
but I'm sure we can all agree that that is a very important restriction which
is well worth making another Parser->Sema call for.

(*) n.b. clang++ does not implement these rules correctly;  we are not ignoring
    non-type names

llvm-svn: 91792

Clang reasonably adds all the base specifiers in one pass;  this is now required
for correctness to prevent lookup from going mad.  But this has the advantage of
establishing the correct context when looking up base specifiers, which will be
important for access control.

llvm-svn: 91791

quite right;  I'll come back to it later.  It does fix PR 5741.

llvm-svn: 91789

to go from a decl to the doc comments for it.

llvm-svn: 91785

llvm-svn: 91781

would have a higher respect for its own code. This is getting old, is this
warning really adding value?

llvm-svn: 91779

llvm-svn: 91772

the redeclaration problems in the [temp.explicit]p3 testcase worse, but I can
live with that;  they'll need to be fixed more holistically anyhow.

llvm-svn: 91771

instantiation, since we're not using a Scope object for that anyway.

llvm-svn: 91770

Magically fixes all the terrible lookup problems associated with not pushing
a new scope.  Resolves an ancient xfail and an LLVM misparse.

llvm-svn: 91769

small bug fixes in SemaInit, switch over SemaDecl to use it more often, and
change a bunch of diagnostics which are different with the new initialization
code.

llvm-svn: 91767

is an lvalue. Fixes PR5787.

llvm-svn: 91765

llvm-svn: 91761

llvm-svn: 91758

ARM: Use front-end specific target features "soft-float" and "soft-float-abi" to communicate FP mode to target; __SOFTFP__ is set correctly now.

llvm-svn: 91755

 - In particular, it can claim features for itself instead of always passing them on to LLVM.
 - This allows using the target features as a generic mechanism for passing target specific options to the TargetInfo instance, which may need them for initializing preprocessor defines, etc.

llvm-svn: 91753