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

[Ziemowit Laski <zlaski at apple dot com>]

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.

--Zem
--------------------------------------------------------------
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