RFC: Make dllimport/dllexport imply default visibility

[Chris Lattner]

On Jun 15, 2007, at 3:45 PM, Mark Mitchell wrote:

> Bill Wendling wrote:
>> On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote:
>>
>>> Consider:
>>>
>>>  struct __attribute__((vsibility ("hidden"))) S {
>>>    void __declspec(dllimport) f();
>>>  };
>>>
>>> At present, we give "f" hidden visibility.  That seems odd since the
>>> user has explicitly told us that the symbol is coming from another
>>> shared library.
>>>
>>> I'm planning to make any dllimport or dllexport attribute imply  
>>> default
>>> visibility.  Is that a bad idea?
>>>


> Yes.  And, therefore, emitting a undefined reference to S::f with  
> hidden
> linkage in the current translation unit causes S::f to have hidden
> visibility in the shared object containing this translation unit.  For
> example, if the translation unit goes on to say:
>
>   void g() {
>     S s;
>     s.f();
>   }
>
> we will now have an undefined reference to S::f with hidden  
> visibility.
>  As a result, S::f will have hidden visibility in the shared object
> containing this translation unit.  Thus, despite dllimport, the user
> cannot actually import a function of a hidden class from another DLL.

This construct seems like it should be rejected by the C++ front- 
end.  The source is making two contradictory claims: the struct is  
not visible outside this library, but part of it is implemented  
outside of it.  This should be rejected by the front-end, not the  
linker IMO.

-Chris