This is the mail archive of the
mailing list for the GCC project.
Re: [objc-improvements-branch] FYI: Added C++ template instantiationsupport
- From: David Ayers <d dot ayers at inode dot at>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: discuss-gnustep at gnu dot org, "gcc-patches at gcc dot gnu dot org Patches" <gcc-patches at gcc dot gnu dot org>, objc-language at lists dot apple dot com
- Date: Tue, 08 Jun 2004 00:38:38 +0200
- Subject: Re: [objc-improvements-branch] FYI: Added C++ template instantiationsupport
- References: <A1A2F5B3-B8B8-11D8-A699email@example.com>
Ziemowit Laski wrote:
I've also brought over David Ayers' fixes to the objc/execute/string?.m
I'll tackle protocol qualifiers next. :-)
Do you mean the Class <protocol> issue?
If you do, could you please consider:
Dropping "id" as a key word (instead of adding "Class" as one). This
would allow you to simply replace OBJECTNAME with TYPENAME for
typespec_nonreserved_nonattr: and you could do the assertions of the
correct type in get_object_reference (which could be renamed to
Well I still have the old patch I could cleanup in a day or two if you
like. I'd have to bring it up to date and revert some of Alexander
Malmbergs changes I prematurely integrated into my version because it
made the warning machinery so much more consistent. (Those were posted
back when both of you were working on the new warnings, but Alex's new
infrastructure never got reviewed in detail.)
Alex, any chance you could cleanup that stuff and repost it?
If you're looking for some more stuff to fix, you could have a look at
comptypes. Note that warnings wrt assignments differ if they are pure
assignments or initialization. This is because the C front end handles
comptypes arguments as being symmetrical (i.e. it doesn't differentiate
between lhs and rhs). Yet as that same code is used for ObjC where we
/do/ make that distinction, we have in issue.
While investigating this I even noticed a few ICEs with conceptually
rather incompatible assignments. I admit that digging into the type
handling (esp. wrt to protocol qualified types) was a bit out of my ball
park. Maybe your experience is better invested in this while I cleanup
the Class <protocol> patch. But don't let me hold you back if you're
already up and running.