[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 <d.ayers@inode.at>
and Alexander Malmberg <alexander@malmberg.org> */
/* { 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.) */
}
- Re: New warnings (hopefully) in gcc 3.4,
David Ayers <=
Re: New warnings (hopefully) in gcc 3.4, Fred Kiefer, 2003/09/01
Re: New warnings (hopefully) in gcc 3.4, David Ayers, 2003/09/01