Benjamin Smedberg wrote:
Jason, I'm sorry to email you directly, as I don't know which email list
I should be discussing on. I've built gcc trunk after your visibility
patch landed, and there are some serious issues with compiling Mozilla now:
Take the following code:
class __attribute__ ((visibility ("hidden"))) HiddenBaseClass
{
public:
virtual SomeMethod();
};
__attribute__ ((visibility ("default"))) HiddenBaseClass*
CreateAClass();
This declaration warns "CreateAClass() declared with greater visibility
than its type. And when CreateAClass is instantiated, it is hidden
visibility.
This seriously breaks XPCOM, which uses this model throughout our code
(default-visibility accessors for interface types, which are declared
with hidden visibility). Why should this model be prevented?
>
A similar issue is present for hidden-visibility classes with
default-visibility member functions:
class __attribute__ ((visibility ("hidden"))) HiddenClass
{
__attribute__ ((visibility ("default"))) void SomeMethod();
};
I see that you explicitly wrote your patch to disallow this kind of
declaration, but I can't figure out why: it works, and we were using it.
This is a less serious issue in that we only use this pattern in a few
places and we can replace the exported method with a non-class method
fairly easily, but I can't take that change on the mozilla 1.8 or 1.8.0
branch. So, unless these patterns can be made to work, it seems that
FF1.5 and 2 are going to both be thoroughly broken when compiled against
gcc trunk->4.2
It seems that you have a different mental model of type visibility. The
way I was thinking about it, if a type has hidden visibility, we can't
refer to it from outside its object. Thus, it doesn't make sense for
members or objects with that type to have greater visibility because
even if people can call the accessor they can't do anything with the
return value.
However, I'm not attached to this in defiance of practical concerns.
What is your model of type visibility?
Jason
