This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ patch] [PR 9283] Implement per-class visibility attribute[resend]
- From: Jason Merrill <jason at redhat dot com>
- To: Brian Ryner <bryner at brianryner dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 25 Mar 2004 14:58:04 -0500
- Subject: Re: [C++ patch] [PR 9283] Implement per-class visibility attribute[resend]
- References: <40362CA0.9060801@brianryner.com><xypk719ob0j.fsf@miranda.boston.redhat.com><406260A8.5060307@brianryner.com>
On Wed, 24 Mar 2004 20:31:36 -0800, Brian Ryner <bryner@brianryner.com> wrote:
> I did the overrides that way because handle_visibility_attribute
> (c-common.c) sets no_add_attrs=true, so the attribute is not present on the
> decl after the visibility bits are set in the tree_decl. I wasn't sure
> what the implications would be of changing that.
Please try it and see.
> As for caching the class visibility on current_class_stack, I wasn't sure
> how to attach the attribute to the decl without passing it through to
> decl_attributes(), which would then wind up in
> handle_visibility_attribute(), which would have to somehow know that
> visibility is ok on a type decl, for C++ (but probably not C, since it
> doesn't have any meaning). This approach does have the advantage of not
> taking extra per-class-decl memory when visibility is specified, once the
> class is done being parsed.
Yep. You could even add a macro
#define CLASSTYPE_VISIBILITY(NODE) DECL_VISIBILITY (TYPE_NAME (NODE))
It seems like decl_attributes can't currently deal with an attribute which
is valid on both decls and types, so it'll need some adjustment.
handle_visibility_attribute would just need to pull out the decl from
TYPE_NAME.
Jason