[PATCH] D22034: [MSVC][DLL] use local vftable mangling only exported classes with virtual destructor

[David Majnemer via cfe-commits]

majnemer added a comment.

In http://reviews.llvm.org/D22034#475002, @DmitryPolukhin wrote:

> In http://reviews.llvm.org/D22034#474985, @majnemer wrote:
>
> > In http://reviews.llvm.org/D22034#474937, @DmitryPolukhin wrote:
> >
> > > David, do you know real programs that relay on constexpr and dllexport semantic that doesn't work on MSVC?
> >
> >
> > Yes, Chrome relied on these semantics.
>
>
> Hm, does it mean that Chrome has some workaround to bypass that MSVC doesn't support it?


Not an explicit workaround, other MSVC bugs prevent them from miscompiling the exact sequence used in Chrome.

> 

> 

> > > Anyway current implementation is not compatible with MSVC in much more common case without constexp.

> 

> > 

> 

> > 

> 

> > I don't see how it is not compatible.  The address of the vftable is not observable as far as I know...

> 

> 

> You can easily observe the difference if vftable is exported from DLL but some virtual functions are not (for example, private). MSVC will uses imported vftable and Clang will try to rebuild fvtable that will fail on link time.


Wait, can you give an example of MSVC exporting a vftable but not all the virtual methods (other than the deleting destructor)?  I don't believe I've ever come across an example of this.


http://reviews.llvm.org/D22034