RFC: Make dllimport/dllexport imply default visibility

[Chris Lattner]

On Jun 19, 2007, at 7:49 AM, Richard Earnshaw wrote:

> On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
>>> I suspect that the realview compiler accepts
>>> this as an oversight or a bug, not as an intentional feature.
>>
>> Let's ask.
>>
>> Richard E., is the fact that RealView 3.0SP1 accepts:
>>
>>   class __declspec(notshared) S {
>>     __declspec(dllimport) void f();
>>   };
>>
>> a bug or a feature?  If this is considered a bug, is it something  
>> that
>> RealView is likely to change in a future release, or will it be
>> preserved for the forseeable future for backwards compatibility?
>
> This is well beyond my sphere of expertise, so I've asked one of the
> original developers of the spec.  He asserts that the above is  
> supported
> and intentional.  Hopefully I've correctly represented his position
> below.
>
> His key point is that 'notshared' on a class is not the same as making
> the whole class hidden: only the class impedimenta (vtables, rtti) is
> hidden, but the rest of the class can be exported as normal.  And that
> since it can be exported, there's no reason why definitions of member
> functions can't be imported.

This description also makes sense, but is different than what was  
described before.  To me, this description/implementation is  
extremely problematic, because the extension cannot be described  
without describing the implementation (specifically presence of  
vtables etc), which is unlike any standard C++ feature.

Some more specific questions:

1. If a class is hidden, does that default all the members (not just  
the metadata) to be notshared?
2. If a class with vtable is hidden, what visibility constraints  
exist on virtual methods?
3. What does 'notshared' on a class without a vtable mean, what  
effect does it have?
4. If classes with vtables have different behavior than those  
without, is this something we want?
5. How does this impact the ODR?

-Chris