r175587 - Add a new 'type_visibility' attribute to allow users to

[John McCall]

On Feb 20, 2013, at 12:30 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> Users who want to minimize the set of symbols they export from their
>> dynamic libraries usually compile with -fvisibility=hidden.  They then
>> find themselves going back and marking certain classes with default
>> visibility.  They then find themselves with extra symbols again because
>> the inline functions from those class are now default visibility.
>> It's all really a huge pain.
>> 
>> The point of type_visibility is that you can give your RTTI symbols
>> default visibility, and therefore make dynamic_cast and exceptions
>> work across dynamic library boundaries, without affecting any other
>> visibility calculations.
>> 
>> libc++ in particular can actually go and mark all of its exported classes
>> with type_visibility("default") and visibility("hidden"), and suddenly,
>> regardless of compilation mode, RTTI symbols will be properly
>> exported and nothing else will.
>> 
>> The only way of achieving that right now is to put DEFAULT on the
>> class and then individually mark every single method declaration
>> with HIDDEN.
> 
> I see. For this use case, can't you give just the typeinfo name
> default visibility? That is the only thing whose address (and not just
> the contents) is important when implementing dynamic_cast and
> exceptions, no?

I believe we already drop the visibility of linkonce_odr vtables and
typeinfo objects.  If they're *not* linkonce_odr, I think these ought
to use the type_visibility rules, both because it makes sense (type
visibility controls all metadata associated with the type) and because
I really don't want to have a *third* attribute specifically for controlling
v-table visibility.

John.