[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.
--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
Re: PATCH: Merge objc-improvements-branch to mainline, Pete French, 2003/09/24
Re: PATCH: Merge objc-improvements-branch to mainline, David Ayers, 2003/09/24
- Re: PATCH: Merge objc-improvements-branch to mainline,
Ziemowit Laski <=
Re: PATCH: Merge objc-improvements-branch to mainline, Pete French, 2003/09/25