llvm-svn: 68261

class which was exposed by implementation of 
objc2's nonfragile abi code gen.

llvm-svn: 68259

failures that involve malformed types, e.g., "typename X::foo" where
"foo" isn't a type, or "std::vector<void>" that doens't instantiate
properly.

Similarly, be a bit smarter in our handling of ambiguities that occur
in Sema::getTypeName, to eliminate duplicate error messages about
ambiguous name lookup.

This eliminates two XFAILs in test/SemaCXX, one of which was crying
out to us, trying to tell us that we were producing repeated error
messages.

llvm-svn: 68251

- Finish up support for converting UTF8->UTF16 to support ObjC @"string" constants.

Remove warning from CheckObjCString.

As the FIXME in the test case indicates, I still have a bug to work out (apparently with \u handling).

llvm-svn: 68245

heuristics to determine when it's useful to desugar a type for display
to the user. Introduce two C++-specific heuristics:

  - For a qualified type (like "foo::bar"), only produce a new
    desugred type if desugaring the qualified type ("bar", in this
    case) produces something interesting. For example, if "foo::bar"
    refers to a class named "bar", don't desugar. However, if
    "foo::bar" refers to a typedef of something else, desugar to that
    something else. This gives some useful desugaring such as
    "foo::bar (aka 'int')".
  - Don't desugar class template specialization types like
    "basic_string<char>" down to their underlying "class
    basic_string<char, char_traits<char>, allocator<char>>, etc.";
    it's better just to leave such types alone. 

Update diagnostics.html with some discussion and examples of type
preservation in C++, showing qualified names and class template
specialization types.

llvm-svn: 68207

specifiers that terminate in a simple-template-id, e.g.,

  typename MetaFun::template apply<T1, T2>

Also, implement template instantiation for dependent
nested-name-specifiers that involve unresolved identifiers, e.g.,

  typename T::type::type

llvm-svn: 68166

llvm-svn: 68140

template template parameters and dependent template names. For
example, the oft-mentioned

  typename MetaFun::template apply<T1, T2>::type

can now be instantiated, with the appropriate name lookup for "apply".

llvm-svn: 68128

llvm-svn: 68110

llvm-svn: 68091

disable this feature for now, to err on the side of rejecting instead
of sometimes crashing.  rdar://6326239

llvm-svn: 68088

within nested-name-specifiers, e.g., for the "apply" in

  typename MetaFun::template apply<T1, T2>::type

At present, we can't instantiate these nested-name-specifiers, so our
testing is sketchy.

llvm-svn: 68081

llvm-svn: 68077

representation handles the various ways in which one can name a
template, including unqualified references ("vector"), qualified
references ("std::vector"), and dependent template names
("MetaFun::template apply").

One immediate effect of this change is that the representation of
nested-name-specifiers in type names for class template
specializations (e.g., std::vector<int>) is more accurate. Rather than
representing std::vector<int> as

  std::(vector<int>)

we represent it as

  (std::vector)<int>

which more closely follows the C++ grammar. 

Additionally, templates are no longer represented as declarations
(DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new
OpaquePtr type (TemplateTy) that holds the representation of a
TemplateName. This will simplify the handling of dependent
template-names, once we get there.

llvm-svn: 68074

llvm-svn: 68021

productions (except the already broken ObjC cases like @class X,Y;) in 
the parser that can produce more than one Decl return a DeclGroup instead
of a Decl, etc.

This allows elimination of the Decl::NextDeclarator field, and exposes
various clients that should look at all decls in a group, but which were
only looking at one (such as the dumper, printer, etc).  These have been
fixed.

Still TODO:

1) there are some FIXME's in the code about potentially using
DeclGroup for better location info.
2) ParseObjCAtDirectives should return a DeclGroup due to @class etc.
3) I'm not sure what is going on with StmtIterator.cpp, or if it can
   be radically simplified now.
4) I put a truly horrible hack in ParseTemplate.cpp.

I plan to bring up #3/4 on the mailing list, but don't plan to tackle
#1/2 in the short term.

llvm-svn: 68002

Reintroduce r67870 (rval ref overloading), since I can't reproduce any test failures on i386 or x86_64. If this fails for someone, please contact me.

llvm-svn: 67999

llvm-svn: 67981

llvm-svn: 67978

to work around this.

llvm-svn: 67968

More improvements to namespace aliases. We now support everything except aliases in using directives.

llvm-svn: 67966

llvm-svn: 67964

llvm-svn: 67962

llvm-svn: 67961

pointer.  Its purpose in life is to be a glorified void*, but which does not
implicitly convert to void* or other OpaquePtr's with a different UID.

Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>.  Change the 
entire parser/sema interface to use DeclPtrTy instead of DeclTy*.  This
makes the C++ compiler enforce that these aren't convertible to other opaque
types.

We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc,
but I don't plan to do that in the short term.

The one outstanding known problem with this patch is that we lose the 
bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to
bitmangle the success bit into the low bit of DeclPtrTy.  I will rectify
this with a subsequent patch.

llvm-svn: 67952

llvm-svn: 67932

llvm-svn: 67925

llvm-svn: 67923

llvm-svn: 67921

llvm-svn: 67915

 TranslationUnit

llvm-svn: 67913

SemaCXX//overload-member-call.cpp
SemaCXX//overloaded-operator.cpp
SemaTemplate//instantiate-method.cpp

llvm-svn: 67912

llvm-svn: 67911

llvm-svn: 67910

happy with just ASTContext, they don't need a TU.

llvm-svn: 67894

clang.cpp

llvm-svn: 67890

LHS type and the computation result type; this encodes information into 
the AST which is otherwise non-obvious.  Fix Sema to always come up with the 
right answer for both of these types.  Fix IRGen and the analyzer to 
account for these changes.  This fixes PR2601.  The approach is inspired 
by PR2601 comment 2.

Note that this changes real *= complex in CodeGen from a silent 
miscompilation to an explicit error.

I'm not really sure that the analyzer changes are correct, or how to 
test them... someone more familiar with the analyzer should check those 
changes.

llvm-svn: 67889

llvm-svn: 67887

syntax into extension warnings, and provide code-modification hints
showing how to fix the problem.

llvm-svn: 67885

instantiation for C++ typename-specifiers such as

  typename T::type

The parsing of typename-specifiers is relatively easy thanks to
annotation tokens. When we see the "typename", we parse the
typename-specifier and produce a typename annotation token. There are
only a few places where we need to handle this. We currently parse the
typename-specifier form that terminates in an identifier, but not the
simple-template-id form, e.g.,

  typename T::template apply<U, V>

Parsing of nested-name-specifiers has a similar problem, since at this
point we don't have any representation of a class template
specialization whose template-name is unknown.

Semantic analysis is only partially complete, with some support for
template instantiation that works for simple examples. 

llvm-svn: 67875