This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Pending issues wrt integrating objc-improvements-branch with mainline
On 3 Aug, 2004, at 11.30, Mark Mitchell wrote:
Ziemowit Laski wrote:
(1) How should I discharge my obligation regarding ObjC++
documentation? Given that there is next to no _ObjC_ documentation
in GCC at present :-), I am tempted to simply point GCC users at
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/
index.html
which discusses both ObjC and ObjC++. Would this be OK, and if
so, where should I insert it?
I think that's an OK reference. As for where to insert it, I would
think that the place in the manual where you describe the switch that
activates Objective-C++ would be good.
OK; I guess the manual would apply to both '-x objective-c' and '-x
objective-c++'.
There are a lot of things not documented in the brief section in
Objective-C++ in the manual. For example, can you do overload
resolution on functions which take an Objective-C class and how does
that work? Can you instantiate a template with an Objective-C class?
Etc.
The answers are "no" and "yes", respectively, but generally you do
raise an excellent point. :-) To the extent that the documentation on
the Apple developer website is incomplete (as it clearly is), I would
be inclined to get in touch with our developer documentation folks and
get it updated, so that all the documentation is in one place.
In the future, we could try and start migrating the information from
the Apple site into gcc/doc/. I honestly don't know (and shall happily
defer to others) whether this is a good idea or not, since
documentation drift/rot may result. But I guess we can deal with this
later on.
I think the situation you are in is that without any specification of
that behavior, you are getting what you get. That includes the fact
that changes to the C++ front end in these areas may affect
Objective-C++. If that happens, I don't think people will look
favorably at trying to add back the old behavior to preserve
Objective-C++ semantics. So, your expectation should be that
Objective-C++ code might break over time, if the C++ side of things
moves around.
Indeed; unspecified behavior is subject to change. :-) At the same
time, over time we may flesh out some of the undefined areas. Of
course, such fleshing out will involve updating the documentation, as
well as adding new test cases.
(2) How would you like me to stage the actual integration once it is
ready to happen? To minimize the burden placed on other maintainers,
I propose to break this down as follows:
(a1) Merge in (minor) changes to the C front-end;
(a2) Merge in changes specific to the objc/ and
testsuite/objc* directories;
(b) Merge in the c-objc-common and cp/cp-objcp-common
lang-hooks rewrite (this basically just moves stuff around);
(c1) Merge in changes to the C++ front-end; aside from a big
new chunk going into cp/parser.c, these are also minor;
(c2) Merge in the objcp/ and testsuite/obj-c++.dg/ directories.
This assumes that (a1) and (a2) occur quasi-simultaneously,
followed by (b) and then by (c1)-(c2) (also quasi-simultaneously).
I can carry out (a2) and (c2) under my ObjC/ObjC++ mullah powers,
but will need global maintainer approval for the other three.
This seems like a good plan. I can review (c1); you'll need someone
else (Joseph Myers?) for (a1) and (b).
Good luck,
Thanks,
--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