classes which are incompatible with weak references.
// rdar://9693477

llvm-svn: 134522

structure to hold inferred information, then propagate each invididual
bit down to -cc1.  Separate the bits of "supports weak" and "has a native
ARC runtime";  make the latter a CodeGenOption.

The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.

llvm-svn: 134453

passed to it, and unknown selectors causing potential leak.
// rdar://9659270

llvm-svn: 134449

llvm-svn: 134278

cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type
to the cast type:

id x;
(NSString**)&x; // Casting as (__strong NSString**).

llvm-svn: 134275

specifiers.  Fixes <rdar://problem/9607158>." because it causes false positives
on some code that uses CF toll free bridging.
 - I'll let Doug or Ted figure out the right fix here, possibly just to accept
   any pointer type.

llvm-svn: 134041

  vector<int>

to

  std::vector<int>

Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.

Thanks Kaelyn!

llvm-svn: 134007

only to pointers to locals.  But it should work inside blocks, too.

llvm-svn: 133969

arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.

The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.

Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.

llvm-svn: 133906

to turn off warning on those properties which follow Cocoa naming
convention for retaining objects and yet they were not meant for
such purposes. Also, perform consistancy checking for declared
getters of such methods. // rdar://9636091

llvm-svn: 133849

is not implemented. // rdar://9651605

llvm-svn: 133819

objects.  // rdar://9495837

llvm-svn: 133806

Rename objc_lifetime -> objc_ownership, and modify diagnostics to talk about 'ownership', not 'lifetime'.

rdar://9477613.

llvm-svn: 133779

diagnose it properly and don't throw clang into an
infinit loop. // rdar://9653341

llvm-svn: 133773

llvm-svn: 133625

integral as it is not transferring ownership.. 
// rdar://9619861

llvm-svn: 133622

message sent to an objc method (or property access)
// rdar://9474349

llvm-svn: 133469

llvm-svn: 133300

__bridge_retain as a synonym for __bridge_retained.

llvm-svn: 133295

they should still be officially __strong for the purposes of errors, 
block capture, etc.  Make a new bit on variables, isARCPseudoStrong(),
and set this for 'self' and these enumeration-loop variables.  Change
the code that was looking for the old patterns to look for this bit,
and change IR generation to find this bit and treat the resulting         
variable as __unsafe_unretained for the purposes of init/destroy in
the two places it can come up.

llvm-svn: 133243

null at any time. // rdar://9612030

llvm-svn: 133168

complaining about mismatches in the global method pool.

llvm-svn: 133123

on all platforms in non-ARC mode.

llvm-svn: 133114

Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.

Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.

llvm-svn: 133103

[format strings] correctly suggest correct type for '%@' specifiers.  Fixes <rdar://problem/9607158>.

llvm-svn: 133024

reason to allow the user to control these semantics through a flag.

llvm-svn: 132919

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

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

llvm-svn: 132753

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

llvm-svn: 132731

There are APIs, e.g. [NSValue valueWithBytes:objCType:], which use the encoding to find out
the size of an object pointed to by a pointer. Make things safer by making it illegal to @encode
incomplete types.

llvm-svn: 131364

bit by allowing __weak and __strong to be added/dropped as part of
implicit conversions (qualification conversions in C++). A little
history: GCC lets one add/remove/change GC qualifiers just about
anywhere, implicitly. Clang did roughly the same before, but we
recently normalized the semantics of qualifiers across the board to
get a semantics that we could reason about (yay). Unfortunately, this
tightened the screws a bit too much for GC qualifiers, where it's
common to add/remove these qualifiers at will.

Overall, we're still in better shape than we were before: we don't
permit directly changing the GC qualifier (e.g., __weak -> __strong),
so type safety is improved. More importantly, we're internally
consistent in our handling of qualifiers, and the logic that allows
adding/removing GC qualifiers (but not adding/removing address
spaces!) only touches two obvious places.

Fixes <rdar://problem/9402499>.

llvm-svn: 131065

Change -Wparentheses to not imply -Widiomatic-parentheses.  Users rarely want to see these warnings, and often explicitly pass -Wparentheses.

llvm-svn: 130535

Emit a -Wnull-dereference warning for "*null" not just "*null = something". Addresses rdar://9269271.

llvm-svn: 130207

invalid expression rather than the far-more-generic "error". Fixes a
mild regression in error recovery uncovered by the GCC testsuite.

llvm-svn: 130128

a 'deprecated' selector in the diagnostics for the
selector. // rdar://9309223

llvm-svn: 130062

-Wwrite-strings. First and foremost, once the positive form of the flag
was passed, it could never be disabled by passing -Wno-write-strings.
Also, the diagnostic engine couldn't in turn use -Wwrite-strings to
control diagnostics (as GCC does) because it was essentially hijacked to
drive the language semantics.

Fix this by giving CC1 a clean '-fconst-strings' flag to enable
const-qualified strings in C and ObjC compilations. Corresponding
'-fno-const-strings' is also added. Then the driver is taught to
introduce '-fconst-strings' in the CC1 command when '-Wwrite-strings'
dominates.

This entire flag is basically GCC-bug-compatibility driven, so we also
match GCC's bug where '-w' doesn't actually disable -Wwrite-strings. I'm
open to changing this though as it seems insane.

llvm-svn: 130051

ObjC NeXt runtime where method pointer registered in
metadata belongs to an unrelated method. Ast part of this fix,
I turned at @end missing warning (for class
implementations) into an error as we can never
be sure that meta-data being generated is correct.
// rdar://9072317

llvm-svn: 130019

of conditional expressions of objc pointer types
where one type is the immediate base type of the
other. // rdar://9296866

llvm-svn: 129718

// rdar://9287695

llvm-svn: 129615