discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New warnings (hopefully) in gcc 3.4


From: David Ayers
Subject: Re: New warnings (hopefully) in gcc 3.4
Date: Mon, 01 Sep 2003 13:54:00 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Alexander Malmberg wrote:

Making all in Source...
make[1]: Entering directory `/opt/gstep/core/base/Source'
Making all in subprojects of library libgnustep-base...
make[2]: Entering directory `/opt/gstep/core/base/Source/Additions'
Making all for subproject Additions...
Compiling file GSCategories.m ...
Compiling file GSObjCRuntime.m ...
GSObjCRuntime.m: In function `GSObjCSetValue':

GSObjCRuntime.m:1168: warning: no interface seen for `NSNull'
GSObjCRuntime.m:1168: warning: receiver of type `NSNull' may not respond to 
`+new'

[snip]

Compiling file NSAttributedString.m ...
NSAttributedString.m: In function `+[NSAttributedString initialize]':

NSAttributedString.m:101: warning: no interface seen for `GSAttributedString'
NSAttributedString.m:101: warning: receiver of type `GSAttributedString' may 
not respond to `+class'
Hi Alex,

Well about your requested comments, I'll wait for others to reply, as you pretty much know my enthusiasm about this approach :-).

But this issue ( @class MyClass; ... [MyClass class]; ) prompted me fixup an new test case. I've attached it with some comments. It leads to proposing the following Objective-C extension (actually I'm not sure if Apple's compiler allready handles it, but I doubt it.):

id <MyProtocol> someVar1;
This checks only the instance methods of the protocol. (This is already current behavior.) I'm a bit split about root classes implementing a protocol (like <NSObject>) and therefor having the protocol also be valid for class methods *if* any root class declares this protocol.

Class <MyProtocol> someVar2;
This checks the class methods of the protocol. (This syntax is currently illegal (parse error).)

Cheers,
David

PS: I've "numbered" this test 'a' as we still have to fill the holes for the other tests.


/* Check for finding the prototype
   when there multiple conflicting available. */
/* Contributed by David Ayers <address@hidden>
and Alexander Malmberg <address@hidden> */
/* { dg-do compile } */

#include <objc/objc-api.h>


@class MyClass;

@protocol Proto1
+(Class)getClass;
+(Class)getClass2;
@end

@protocol Proto2
+(id)getClass;
+(Class)getClass2;
@end

void foo1(void)
{
  Class varCls;
  id <Proto1> varProto1;

  varCls = [MyClass getClass];
  /* I think it's ok to enforce including the header,
     to be able to do [SomeClass class/new]; (e.g. +initialze methods).
     I remember a discussion about prefering
     [NSNull new] to [NSNull null] to avoid including NSNull.h,
     but I think that can be deemed invalid.  If you send a message
     to a class, include the header or be warned.  */

  [varCls getClass];
  /* The warnings about multiple declarations seems right.  */
  [varCls getClass2];
  /* If the prototypes are unambigous, you don't have the warning.  */

  [(Class)varCls getClass];
  /* This test seems redundant
     (and can be removed from the test if you like).  */

  [(id <Proto1>)varCls getClass];
  /* This warning makes sense, is I believe id implies instances.  */

  [(Class <Proto1>)varCls getClass];
  /* but this is illegal :-/ ... but I'm not sure it should be.  */

  [(Class)MyClass getClass];
  /* This is also illegal and is semantically an incorrect cast also,
     as IIRC a cast only indicates the type of a variable.  But this
     identifier isn't a variable. (IOW: there is no quick cast solution
     for the first variant.)  */

}




reply via email to

[Prev in Thread] Current Thread [Next in Thread]