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

PR10120: Make CodeGenModule::getVTableLinkage use NamedDecl::getLinkage to determine whether the vtable should be externally visible, instead of a rough approximation of it which messes up with templates.

While I'm here, zap the other user of isInAnonymousNamespace outside of Decl.cpp.

llvm-svn: 132861

llvm-svn: 132855

to study it.

llvm-svn: 132843

llvm-svn: 132842

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

[analyzer] PR8962 again. Ban ParenExprs (and friends) from block-level expressions (by calling IgnoreParens before adding expressions to blocks). Undo 132769 (LiveVariables' local IgnoreParens), since it's no longer necessary.

Also, have Environment stop looking through NoOp casts; it didn't match the behavior of LiveVariables. And once that's gone, the whole cast block of that switch is unnecessary.

llvm-svn: 132840

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

llvm-svn: 132812

// rdar://9566314

llvm-svn: 132791

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

range checking for immediate operands.  Radar 9558930.

llvm-svn: 132783

[analyzer] Ignore parentheses around block-level expressions when computing liveness. Fixes the other half of PR8962.

llvm-svn: 132769

llvm-svn: 132762

llvm-svn: 132757

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

llvm-svn: 132753

comments.  rdar://problem/9037836

llvm-svn: 132752

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

Very sorry for the accidental commit of WIP code.

llvm-svn: 132745

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

llvm-svn: 132743

rdar://problem/9037836

llvm-svn: 132737

may pick it up. This would create bad text relocations.

llvm-svn: 132736

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

llvm-svn: 132731

-undef flag is passed in. Also __ASSEMBLER__ with -x assembler-with-cpp. (Don't
ask.)

llvm-svn: 132708

specializations within an explicit instantiation to default to off
(enabled by -pedantic). Nobody else seem to implement C++
[temp.explicit]p3. Fixes PR10093.

llvm-svn: 132704

llvm-svn: 132700

llvm-svn: 132694

llvm-svn: 132691

llvm-svn: 132687

llvm-svn: 132679

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

llvm-svn: 132677

llvm-svn: 132675

"unsafe mix of type 'int' and type 'bool' in operation"

llvm-svn: 132674

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