Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:

t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
      expression of type 'NSArray *' [-Wincompatible-pointer-types]
  NSSet *array = [[NSArray alloc] init];
         ^       ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note: 
      instance method 'init' is assumed to return an instance of its
      receiver
      type ('NSArray *')
- (id)init;
^

It also means that we get decent type inference when writing code in
Objective-C++0x:

  auto array = [[NSMutableArray alloc] initWithObjects:@"one",  @"two",nil];
  //    ^ now infers NSMutableArray* rather than id

llvm-svn: 132868

properties.

llvm-svn: 132866

to study it.

llvm-svn: 132843

I believe, upon, careful review, that this code causes us to incorrectly
handle exception specifications of copy assignment operators in C++03
mode. However, we currently do not seem to properly implement the subtle
distinction between copying of members and bases made by implicit copy
constructors and assignment operators in C++03 - namely that they are
limited in their overload selection - in all cases. As such, I feel that
committing this code is correct pending a careful review of our
implementation of these semantics.

llvm-svn: 132841

llvm-svn: 132835

isn't yet used for the less controlled environments of initialization.

Also a few random text fixups.

llvm-svn: 132833

- Removed fix-it hints from template instaniations since changes to the
templates are rarely helpful.
- Changed the caret in template instaniations from the class/struct name to the
class/struct keyword, matching the other warnings.
- Do not offer fix-it hints when multiple declarations disagree.  Warnings are
still given.
- Once a definition is found, offer a fix-it hint to all previous declarations
with wrong tag.
- Declarations that disagree with a previous definition will get a fix-it hint
to change the declaration.

llvm-svn: 132831

This is a follow-up to r132565, and should address the rest of PR9969:

Warn about cases such as

int foo(A a, bool b) {
 return a + b ? 1 : 2; // user probably meant a + (b ? 1 : 2);
}

also when + is an overloaded operator call.

llvm-svn: 132784

It is not a sanctioned keyword and is assumed as default.
// rdar://8790791

llvm-svn: 132753

This fixes a memory error on FreeBSD (and is the right thing to do
in any case).

llvm-svn: 132750

were intended for was suppressed.

llvm-svn: 132746

namespace set algorithm (re-)introduced. We may not have seen the 'std'
namespace, but we should still suggested associated namespaces. Easy
fix, but a bit annoying to test.

llvm-svn: 132744

declared __weak objc-gc mode.  // rdar://9666091.

llvm-svn: 132731

llvm-svn: 132700

specializing a member of an unspecialized template, and recover from
such errors without crashing. Fixes PR10024 / <rdar://problem/9509761>.

llvm-svn: 132677

this. My suggestion assumed a viable erase method for iterators on
SmallPtrSet.

This patch restores his original pattern.

llvm-svn: 132673

Fix PR10053: Improve diagnostics and error recovery for code which some compilers incorrectly accept due to a lack of proper support for two-phase name lookup.

llvm-svn: 132672

Drop most of InitializationSequence::SequenceKind's values. They didn't really contain any information that the step array didn't contain too. This makes debugging dumps a bit less informative, but probably not significantly so. The advantage is that the redundancy is gone, so the code is easier to understand.
ReferenceBinding is still there, because it is used in some unclear code.

llvm-svn: 132667

llvm-svn: 132666

Remove all references to InitializationSequence::FailedSequence from outside SemaInit.cpp. Replace them with the boolean conversion or the new Failed() function. This is a first step towards removing InitializationSequence::SequenceKind. No functionality change.

llvm-svn: 132664

compared even when one is a reference binding and the other is not
(<rdar://problem/9173984>), but the definition of an identity sequence
does not involve lvalue-to-rvalue adjustments (PR9507). Fix both
inter-related issues.

llvm-svn: 132660

  return <expression> ;

in blocks with a 'void' result type, so long as <expression> has type
'void'. This follows the rules for C++ functions.

llvm-svn: 132658

with a type-dependent expression, infer the placeholder type
'Context.DependentTy' to indicate that this is just a
placeholder. Fixes PR9982 / <rdar://problem/9486685>.

llvm-svn: 132657

the self-host failures and Chandler's concerns.

llvm-svn: 132622

__builtin_astype(): Used to reinterpreted as another data type of the same size using for both scalar and vector data types.
Added test case.

llvm-svn: 132612

libclang. Fixes <rdar://problem/9537904>.

llvm-svn: 132603

suggested by Chandler.

llvm-svn: 132593

destructors are implemented but other special members are on the way,
which is where the real benefits of this will be visible.

llvm-svn: 132572

Warn in cases such as "x + someCondition ? 42 : 0;",
where the condition expression looks arithmetic, and has
a right-hand side that looks boolean.

This (partly) addresses http://llvm.org/bugs/show_bug.cgi?id=9969

llvm-svn: 132565

In code such as "char* volatile const j()", Clang warns that "volatile
const" will be ignored. Make it point to the first ignored qualifier,
and simplify the code a bit.

llvm-svn: 132563

Sema::RequireCompleteExprType() a bit more, setting the point of
instantiation if needed, and skipping explicit specializations entirely.

llvm-svn: 132547

llvm-svn: 132546

llvm-svn: 132544

I'll try to implement this functionality again soon.

llvm-svn: 132536

diagnostic group to cover the cases where we have definitively bad
behavior: dynamic classes.

It also rips out the existing support for POD-based checking. This
didn't work well, and triggered too many false positives. I'm looking
into a possibly more principled way to warn on the fundamental buggy
construct here. POD-ness isn't the critical aspect anyways, so a clean
slate is better. This also removes some silliness from the code until
the new checks arrive.

llvm-svn: 132534

of incomplete array type, attempt to complete the array type. This was
made much easier by Chandler's addition of RequireCompleteExprType(),
which I've tweaked (slightly) to improve the consistency of the
DeclRefExpr. Fixes PR7985.

llvm-svn: 132530

the template parameter, perform the checking as a "specified" template
argument rather than a "deduced" template argument; the latter implies
stricter type checking that is not permitted for default template
arguments.

Also, cleanup our handling of substitution of explicit template
arguments for a function template. We were actually performing some
substitution of default arguments at this point!

Fixes PR10069.

llvm-svn: 132529

llvm-svn: 132460

+keyPathsForValuesAffecting<Key> completion was mislabeled as an
instance method, and +automaticallyNotifiesObserversOf<Key> was
missing entirely. Fixes <rdar://problem/9516762>.

llvm-svn: 132452

llvm-svn: 132447