llvm-svn: 162880

could not be attached to a CFTypeRef.

Fixes <rdar://problem/12197822>

llvm-svn: 162872

when assignment expression in conditional invloves
property reference. // rdar://11066598

llvm-svn: 162846

and when used in property type declaration, is handled as type
attribute. Do not issue the warning when declaraing the property. 
// rdar://12173491

llvm-svn: 162801

declaration is not provided. It is only necessary on
the method implementation. // rdar://11593375

llvm-svn: 162628

in class extension, assume default is rewdwrite and don't
issue any diagnostics, privided other ownership models
are ok.

llvm-svn: 162583

llvm-svn: 162324

class extensions a little. clang now allows readonly property 
with no ownership rule (assign, unsafe_unretained, weak, retain, 
strong, or copy) with a readwrite property with an ownership rule.
// rdar://12103400 

llvm-svn: 162319

// rdar://12107381

llvm-svn: 162045

expressions except to void, void * and their
qualified versions. // rdar://12107381

llvm-svn: 162036

inside objc class implementation. // rdar://10387088

llvm-svn: 161705

Handle deprecation diagnostics correctly for C struct fields and Objective-C properties/ivars. <rdar://problem/6642337>.

llvm-svn: 161534

Unify the codepaths for emitting deprecation warnings.  The test changes are just to account for us emitting notes more consistently.

llvm-svn: 161528

We handled the builtin version of this function in r157968, but the builtin
isn't used when compiling as -fno-constant-cfstrings.

This should complete <rdar://problem/6157200>.

llvm-svn: 161525

-Wdirect-ivar-access.

llvm-svn: 161500

memory models, except when arc is accessing a weak
ivar (which is an error). // rdar://6505197

llvm-svn: 161458

Allow direct ivar access in init and dealloc methods
in mrr. // rdar://650197

llvm-svn: 161426

// rdar://6505197

llvm-svn: 161362

resulting in issuance of unused static variable
warning now. // rdar://10777111

llvm-svn: 161291

// rdar://11913153

llvm-svn: 161194

objects used as dictionary subscript objects.
// rdar://11913153

llvm-svn: 161187

type of generated call to super dealloc is 'void'
and asserts if user's dealloc is not of 'void type.
This rule must be enforced in clang front-end (with a 
fixit) if this is not the case, instead of asserting in CodeGen.
// rdar://11987838

llvm-svn: 160993

// rdar://11923822

llvm-svn: 160902

are cast to retainable types, only suggest CFBridgingRelease/
CFBridgingRetain and not the __bridge casts.
// rdar://11923822

llvm-svn: 160900

llvm-svn: 160895

Also, fix a subtle bug, which occurred due to lookupPrivateMethod
defined in DeclObjC.h not looking up the method inside parent's
categories.

Note, the code assumes that Class's parent object has the same methods
as what's in the Root class of a the hierarchy, which is a heuristic
that might not hold for hierarchies which do not descend from NSObject.
Would be great to fix this in the future.

llvm-svn: 160885

retainable types in arc, only suggest CFBridgingRelease/
CFBridgingRetain and not the confusing __bridge casts.
// rdar://11923822

llvm-svn: 160839

llvm-svn: 160707

llvm-svn: 160622

While we still want to consider this a hard error (non-POD variadic args are
normally a DefaultError warning), delaying the diagnostic allows us to give
better error messages, which also match the usual non-POD errors more closely.

In addition, this change improves the diagnostic messages for format string
argument type mismatches by passing down the type of the callee, so we can
say "variadic method" or "variadic function" appropriately.

<rdar://problem/11825593>

llvm-svn: 160517

No functionality change.

llvm-svn: 160516

Previously, we would ask for the SourceLocation of an argument even if
it were NULL (i.e. if Sema resulted in an ExprError trying to build it).

<rdar://problem/11890818>

llvm-svn: 160515

Checks against nil often appear as guards in macros, and comparing
Objective-C literals to nil has well-defined behavior (if tautological).

On OS X, 'nil' has not been typed as 'id' since 10.6 (possibly earlier),
so the warning was already not firing, but other runtimes continue to use
((id)0) or some variant. This change accepts comparisons to any null pointer;
to keep it simple, it looks through all casts (not just casts to 'id').

PR13276

llvm-svn: 160379

Suggested by Ted, since string literal comparison is at least slightly more
sensible than comparison of runtime literals. (Ambiguous language on
developer.apple.com implies that strings are guaranteed to be uniqued within
a translation unit and possibly across a linked binary.)

llvm-svn: 160378

Recovering as if the user had actually called -isEqual: is a bit too far from
the semantics of the program as written, /even though/ it's probably what they
intended.

llvm-svn: 160377

from diagnostics. // rdar://9657485

llvm-svn: 159943

Chris pointed out that while the comparison is certainly problematic
and does not have well-defined behavior, it isn't any worse than some
of the other abuses that we merely warn about and doesn't need to make
the compilation fail.

Revert the release notes change (r159766) now that this is just a new warning.

llvm-svn: 159939

a 'weak' property just as we do the same for
'weak' variables. // rdar://11814185

llvm-svn: 159859

under -Wsuper-class-method-mismatch for method
mismatches in current and suprt class.
// rdar://11793793

llvm-svn: 159784

c-function parsing when a declaration with
C++0x braced-init-list is inside an @implementation.

llvm-svn: 159693