Pending issues wrt integrating objc-improvements-branch with mainline

[Joseph S. Myers]

On Tue, 3 Aug 2004, 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?

This looks to be probably what we currently point to in standards.texi for
Objective-C - except that the present URL gets redirected to a more
general location
<http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/> -->
<http://developer.apple.com/documentation/index.html>.  (Proper 404
avoidance means redirecting old URLs to the most specific replacement
possible, not just to a general area of the site that contains something
equivalent.  Remember that URLs in the GCC manual end up in manuals
printed and distributed by GNU Press, so try to ensure that any new URL
you put in is durable.)

Are the few aspects of Objective-C++ documented there all also covered in
the Objective-C++ testsuite?  Not that I'll object if they aren't, given
that it's expressly Apple's responsibility rather than that of volunteers
contributing to FSF GCC to keep the Objective-C++ front end functioning
(or not).  But it seems a good idea for the documented points and the
answers to Mark's questions

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

to be covered in the testsuite.

> > (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).

I don't know for what supposed expertise I was on the original reviewer
list for Objective-C++ <http://gcc.gnu.org/ml/gcc/2004-06/msg00818.html>,
but surely not expertise in Objective-C or Objective-C++ (I'd guess for
review of documentation and coding standards).  If the C changes obviously
only change how the compiler behaves when compiling Objective-C then I'd
tend to presume that Objective-C maintainers know what they are doing (but
also normally tend to pass over reviewing such changes in favour of review
by Objective-C experts).

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)