This is the mail archive of the
mailing list for the GCC project.
Re: [C++ patch] [PR 9283] Implement per-class visibility attribute [resend]
- From: Brian Ryner <bryner at brianryner dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 24 Mar 2004 20:31:36 -0800
- Subject: Re: [C++ patch] [PR 9283] Implement per-class visibility attribute [resend]
- References: <40362CA0.firstname.lastname@example.org> <email@example.com>
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.
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.
Anyway, I'm a newbie here, so if you have any suggestions for a better way to do
this I'd be happy to try it. Thanks.
Jason Merrill wrote:
Sorry I've taken so long to review this.
Why did you decide to store so much information in current_class_stack? It
would seem simpler to me just to look up the relevant attributes when
needed. I suppose that caching the class visibility in current_class_stack
might speed things up slightly, but the visibility_overrides scheme seems
slower than just looking for a visibility attribute on the decl.