setter/getter synthesis.

llvm-svn: 68976

Change diagnostic as a result of researching <rdar://problem/6779809> missing interface name in "error: cannot declare variable inside a class, protocol or category ''.

Since ObjC 2.0 class "extensions" have a null name, the diagnostic above is actually "correct". Nevertheless, it is confusing. Decided to remove the name entirely (from my perspective, it didn't add any value). Also simplified the text of the diagnostic a bit.

llvm-svn: 68967

list of another protocol definition.  This warning is very noisy and GCC doesn't
produce it so existing code doesn't expect it.

llvm-svn: 68894

@property int x;

associate the location of X with the property decl, not the location
of the @.  Also, pass this info along to the synthesized ParmVarDecls
so that redefinition and other diagnostics can use it.  This eliminates
a fixme.

llvm-svn: 68880

that it is plumbed through Sema.  On a file from growl, we used to emit:

t.mi:107059:1: warning: conflicting types for 'removePluginHandler:forPluginTypes:'
- (void) removePluginHandler:(id <GrowlPluginHandler>)handler forPluginTypes:(NSSet *)extensions {
^
t.mi:105280:1: note: previous definition is here
- (void) removePluginHandler:(id <NSObject>)handler forPluginTypes:(NSSet *)types;
^

now we produce:

t.mi:107059:55: warning: conflicting parameter types in implementation of 'removePluginHandler:forPluginTypes:': 'id<NSObject>' vs 'id<GrowlPluginHandler>'
- (void) removePluginHandler:(id <GrowlPluginHandler>)handler forPluginTypes:(NSSet *)extensions {
                                                      ^
t.mi:105280:45: note: previous definition is here
- (void) removePluginHandler:(id <NSObject>)handler forPluginTypes:(NSSet *)types;
                                            ^

We still don't have proper loc info for properties, hence the FIXME.

rdar://6782494

llvm-svn: 68879

llvm-svn: 68877

to their arguments.

llvm-svn: 68876

1) improve localizability by not passing english strings in.
2) improve location for arguments.
3) print the objc type being passed.

Before:
method-bad-param.m:15:1: error: Objective-C type cannot be passed by value
-(void) my_method:(foo) my_param
^

after:
method-bad-param.m:15:25: error: Objective-C interface type 'foo' cannot be passed by value
-(void) my_method:(foo) my_param
                        ^

llvm-svn: 68872

information in a little struct instead of individually.  While we're
at it, add per-argument loc info and attribute info.

llvm-svn: 68871

indent code properly

llvm-svn: 68866

llvm-svn: 68834

llvm-svn: 68804

No functionality change (really).

llvm-svn: 68726

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

llvm-svn: 68551

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

llvm-svn: 68474

ivars.

llvm-svn: 68453

makes the property writable in the current class.
 

llvm-svn: 68446

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

llvm-svn: 68409

objc's continuation class.

llvm-svn: 68339

class which was exposed by implementation of 
objc2's nonfragile abi code gen.

llvm-svn: 68259

llvm-svn: 68077

productions (except the already broken ObjC cases like @class X,Y;) in 
the parser that can produce more than one Decl return a DeclGroup instead
of a Decl, etc.

This allows elimination of the Decl::NextDeclarator field, and exposes
various clients that should look at all decls in a group, but which were
only looking at one (such as the dumper, printer, etc).  These have been
fixed.

Still TODO:

1) there are some FIXME's in the code about potentially using
DeclGroup for better location info.
2) ParseObjCAtDirectives should return a DeclGroup due to @class etc.
3) I'm not sure what is going on with StmtIterator.cpp, or if it can
   be radically simplified now.
4) I put a truly horrible hack in ParseTemplate.cpp.

I plan to bring up #3/4 on the mailing list, but don't plan to tackle
#1/2 in the short term.

llvm-svn: 68002

llvm-svn: 67978

pointer.  Its purpose in life is to be a glorified void*, but which does not
implicitly convert to void* or other OpaquePtr's with a different UID.

Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>.  Change the 
entire parser/sema interface to use DeclPtrTy instead of DeclTy*.  This
makes the C++ compiler enforce that these aren't convertible to other opaque
types.

We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc,
but I don't plan to do that in the short term.

The one outstanding known problem with this patch is that we lose the 
bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to
bitmangle the success bit into the low bit of DeclPtrTy.  I will rectify
this with a subsequent patch.

llvm-svn: 67952

category or protocol.

llvm-svn: 67450

whose sema decl is at the translation unit.

llvm-svn: 67249

week in:

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013580.html

That patch caused the output of the diagnostics to change. Since
'DeclarationName' can already reason about Selectors and the Diagnostics logic
reasons about DeclarationName, there is no additional code needed to get the
diagnostics working by making Selector::getIdentifierInfo() private.

llvm-svn: 66992

Remove ActiveScope (revert http://llvm.org/viewvc/llvm-project?view=rev&revision=65694 and http://llvm.org/viewvc/llvm-project?view=rev&revision=66741).

Will replace with something better today...

llvm-svn: 66893

llvm-svn: 66317

llvm-svn: 66314

- Make Selector::getAsIdentifierInfo() private.  Using IdentifierInfo* in
  Selector is an implementation detail that clients shouldn't think about.
- Modify diagnostic emission in Sema::ProcessPropertyDecl to not use
  Selector::getAsIdentifierInfo() (which could crash when IdentifierInfo* is
  null) and instead use Selector::getAsString().
- Tidy up Selector::getAsString() implementation.

llvm-svn: 66313

Tweak diag for <rdar://problem/5982579> [clang on xcode] (using arch=x86_64): synthesized property 'sdkPath' must either be named the same as a compatible ivar or must explicitly name an ivar.

llvm-svn: 66162

llvm-svn: 66161

llvm-svn: 66016

Fix <rdar://problem/5982579> [clang on xcode] (using arch=x86_64): synthesized property 'sdkPath' must either be named the same as a compatible ivar or must explicitly name an ivar.

llvm-svn: 65973

Change Sema::DiagnosePropertyMismatch() to check for type compatibility (rather than type equivalence, which is too strict).

llvm-svn: 65949

llvm-svn: 65948

llvm-svn: 65855

in its extension.

llvm-svn: 65854

"This patch uses the new ObjCImplDecl class to merge  Sema::ImplMethodsVsClassMethods and Sema::ImplCategoryMethodsVsIntfMethods methods.
And now, when clang check a class implementation to find unimplemented methods, it also checks all methods from the class extensions (unnamed categories).

There is also a test case to check this warning.

This patch contains also a minor update for ObjCImplDecl . getNameAsCString and getNameAsString now returns an empty string instead of crashing for unnamed categories."

Patch by Jean-Daniel Dupas!

llvm-svn: 65744