This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [objc-improvements] Yet another set of fixes committed



On Wednesday, Aug 27, 2003, at 18:39 US/Pacific, Alexander Malmberg wrote:


Ziemowit Laski wrote:

On Wednesday, Aug 27, 2003, at 17:44 US/Pacific, Alexander Malmberg wrote:

Ziemowit Laski wrote:
[snip]
Please test away!  I will now sync up with HEAD and, if there are no
regressions, will commit that as well.

GNUstep fails to build; the first error was caused by a minor problem
in
the new code. However, testing the message passing behavior shows that
the new code gets several cases wrong. The commit message implies that
there is/was something amiss with the commit. Is this the case? If not,
I'll get to work on a patch to clean things up and a set of test cases
that covers all the cases I can find.

Can you be more specific as to what is broken?

It won't find prototypes for a type if the prototype comes from a protocol implemented by the class, eg.:

@protocol Zot
-(void) zot;
@end

@interface Foo : Object <Zot>
@end

int main()
{
	Foo *f=nil;
	[f zot]; /* warns that f might not respond to -zot here */
	return 0;
}

I've attached a patch.

Also, it fails to detect multiple applicable prototypes in many cases,
and the behavior in case d. does not seem to have changed (so it's
compatible with the old behavior, but it matches neither my nor your
proposal for new behavior). Anyway, I want to investigate a bit more and
finish a complete set of tests before reporting on this, so that'll have
to wait until tomorrow.

Yes, the implementation does depart from both you and I were describing. Specifically, if your receiver is of type 'id<Foo, Bar, Baz>', then the front-end will examine the three protocols in turn, and return the first matching method, rather than search all 3 protocols unconditionally to reveal any conflicts. And yes, this is what the compiler did up until now, and I'm a bit nervous about changing it. :-( What's your take on this?


Certainly, you're more
than welcome to make a patch :-), but perhaps it's something really
trivial that I omitted/comitted...

Also/more importantly, could you provide me with a quickie tarball of
GNUStep sources that I could just run 'make' on?  The GNUStep
installation
liturgy I found on the Web is highly discouraging. :-(

Installation is easy _iff_ you have all the dependencies covered. Either
get the cvs version:


http://savannah.gnu.org/cvs/?group=gnustep

(the gnustep/core/ module), or grab a snapshot:

http://ftp.gnustep.org/pub/daily-snapshots/

Running compile-all in core/ should compile and install it. The script
also shows how to do it manually (in case of errors, or if you want to
use a special CC or something). Basically, you run "./configure ; make ;
make install" in make, base, gui, and back in that order.


If you don't have all the dependencies, the build guide is supposed to
be good:

http://documents.made-it.com/GNUstep/buildguide.html

Yeah, that's the write-up that frightened me so. :-( That's why I was hoping that if someone already went through this paint on a RH Linux 8 system, they could just tar up the fruits of their labor, so that I may jump right into the configure/make step you're describing. But perhaps I'm hoping for too much... :-)


- Alexander MalmbergIndex: objc-act.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/objc/objc-act.c,v retrieving revision 1.179.2.7 diff -u -r1.179.2.7 objc-act.c --- objc-act.c 27 Aug 2003 00:19:24 -0000 1.179.2.7 +++ objc-act.c 28 Aug 2003 01:23:48 -0000 @@ -6387,7 +6387,7 @@ if (CLASS_PROTOCOL_LIST (inter)) { if ((meth = (lookup_method_in_protocol_list - (CLASS_PROTOCOL_LIST (inter), ident, 1)))) + (CLASS_PROTOCOL_LIST (inter), ident, is_class)))) return meth; }

Indeed - a stupid omission on my part; many thanks, I'll commit your patch,
along with the test case at the top.
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]