Re: RFC: Make dllimport/dllexport imply default visibility

[Chris Lattner <clattner at apple dot com>]

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