llvm-svn: 68659

Fixes <rdar://problem/6762239> [sema] gcc incompatibility; error on incompatible operand types in ?:.

llvm-svn: 68617

Fixes <rdar://problem/6759522>

llvm-svn: 68611

we must not issue gc-specific errors in non-gc mode.

llvm-svn: 68551

functions.  Fixes PR3941.

llvm-svn: 68541

the base implementations (and not in
current implementation).

llvm-svn: 68527

Tweak Sema::ActOnInstanceMessage() to look for a class method when dealing with qualified id's. This change is motivated by our desire to not support the "Class<foo>" idiom. Note that the change makes perfect sense (since all ObjC classes are also id/instances).

This allow us to document a simple migration path...change "Class <foo>" to "id <foo>".

This effects: 
- <rdar://problem/6761939> TASK: File source change radars for "qualified Class" errors
- <rdar://problem/6761864> Protocol qualified Class is unsupported

llvm-svn: 68517

This fixes <rdar://problem/6757102> clang type for @"xxx" is "NSConstantString *" (GCC type is "NSString *").

llvm-svn: 68514

Be kind to so many projects which are doing this (and be
like gcc).

llvm-svn: 68474

This will simplify clang adoption, and is probably better "etiquette" (since gcc has always accepted this idiom without warning). Once we are over the adoption hurdle, we can turn this into an error.

llvm-svn: 68468

llvm-svn: 68454

ivars.

llvm-svn: 68453

a really really bad idea.  Now that we emit an error about the unpromoted
type, users should be able to understand what is going on.

llvm-svn: 68447

makes the property writable in the current class.
 

llvm-svn: 68446

diagnostic use the va_list typedef more often, see the difference in the 
changed testcase.

llvm-svn: 68441

llvm-svn: 68435

va_lists for some reason.  This fixes rdar://6726818

llvm-svn: 68434

llvm-svn: 68424

llvm-svn: 68414

llvm-svn: 68413

used in a class which declares a property of the same
name. This should not result in an unimplemented
method warning.

llvm-svn: 68409

llvm-svn: 68407

objc's continuation class.

llvm-svn: 68339

definition, warn if there are too many/too few function call
arguments.

llvm-svn: 68318

llvm-svn: 68278

llvm-svn: 68268

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