This is the mail archive of the
mailing list for the GCC project.
Question: Need to store ObjC-specific info in type nodes.
- From: Ziemowit Laski <zlaski at apple dot com>
- To: gcc List <gcc at gcc dot gnu dot org>
- Date: Thu, 23 Sep 2004 15:41:38 -0700
- Subject: Question: Need to store ObjC-specific info in type nodes.
Currently, ObjC does some rather ghastly things with accessors such as
TYPE_CONTEXT, TREE_PUBLIC and TYPE_MAIN_VARIANT, which are used for its
own merry purposes in RECORD_TYPEs. This is a horrible state of
affairs, and so I'd like to clean up the way ObjC stores its own
information so that it plays nice(r) with what C and C++ expect. (This
work is part of the ongoing ObjC++ integration, BTW, so a prompt
response would be appreciated.)
There seem to be several ways of attacking this, but I'd like to ask
the powers that be for the preferred approach before actually
(1) The additional info required for ObjC RECORD_TYPEs is stored as
attributes, which peacefully co-exist with C/C++ attributes in the
(2) In addition to a 'struct lang_type *lang_specific' field, each
type node also gets a 'struct objc_lang_type *objc_lang_specific' field
(set to NULL in plain C and C++ modes).
(3) A variation of (2) in which 'struct lang_type' itself (both in C
and C++) gets 'struct objc_lang_type *objc_lang_specific' field.
Which of these would be preferable and/or have I left out other
possibilities? It seems that (1) would require least (if any!) changes
to existing GCC infrastructure, but the resulting ObjC/ObjC++
compile-time performance would be less than stellar. Personally, I