[Top][All Lists]

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

Re: PATCH: Merge objc-improvements-branch to mainline

From: Ziemowit Laski
Subject: Re: PATCH: Merge objc-improvements-branch to mainline
Date: Wed, 24 Sep 2003 13:26:40 -0700

On Wednesday, Sep 24, 2003, at 12:56 US/Pacific, David Ayers wrote:

Ziemowit Laski wrote:

(1) Bug fixes (as evidenced by the numerous new test cases vs. mainline) (2) Support for new Mac OS X (NeXT) runtime features, accessible via -fobjc-exceptions, -fno-nil-receivers, -fzero-link and -freplace-objc-classes, all of which have been documented in gcc/doc/invoke.texi. Test cases are included (and made
      Darwin-specific when appropriate).
(3) Retrofit of DejaGNU ObjC test suite so that most tests are usable with
      both NeXT and GNU runtimes.
(4) Very humble beginnings of Objective-C++ support (e.g., stub-objc.c, more
      #ifdef OBJCPLUS fragments in objc-act.c).

I deduce from this, that ObjC++ should also live in c-parse.in and objc-act.c. :-/

No, ObjC++ will not live in c-parse.in -- it will live in cp/parser.c.

I'll have a closer look once it's on the branch, but I must say I'm not too thrilled about effectively supporting three front ends in this conglomerate of files. If this is currently necessary to avoid code duplication, I'm not going to attempt block it. But we should try to find a way to separate the front ends and somehow share common code soon.

The common code is in objc-act.c, which is why you see the #ifdef OBJCPLUS fragments there...

I shall wait 24 hours for feedback,

The branch is still missing Alex's patch. Therefore we are seeing some inappropriate (but I believe harmless on all architectures) warnings about: I care little about whether this gets fixed on the branch or on mainline and gets merged back later, but it should get fixed soon.

Sure -- let's do it on the mainline, right after the current big patch goes in.

Plus there are more formal issues about introducing changes that seem to belong in ObjC++ support and not in this initial 'ObjC' only merge.

Yes, although the ObjC++-specific bits are surrounded with '#ifdef OBJCPLUS' and are not presently used/compiled at all. Keeping them there allows for a better FSF<->Apple source tree synergy.

There seem to be a few new non-portable implementation (which is currently NeXT runtime only). These should be addressed individually, so that we can find portable solutions for the GNU Runtime where applicable.

As Stan and I already mentioned, the non-portability issues can certainly be addressed in the future, but at the present time you (i.e., GNU runtime users) will not be affected by them at all.

(Plus formating issues here and there, especially the test cases.)

Please point them out to me and I will fix them. As for test cases, my understanding was that they do not have formatting conventions...?

Would it be possible to split this merge into coherent patches, individually RFC'ed and applied to mainline?

No, it would not; I'm very sorry. :-( I'm utilizing a sliver of time that I've been given at Apple to do this work, and there are many other issues on my plate (implementing 3.4 ObjC++, for one!) that I must get to ASAP. Plus, the resulting patches would not be very "coherent", since there a lot of interdependencies there.

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

reply via email to

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