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

[Dmitry Polukhin via cfe-commits]

DmitryPolukhin added a comment.

In http://reviews.llvm.org/D22034#475603, @majnemer wrote:

> Thinking about this some more, it is possible for clang to emit code that will make everybody happy:
>
> If a class is being constructed in a constexpr context and all the vftable entries it references are marked import, emit local vftables and reference them in the object.  If a vftable entry it references is not marked import, report an error.
>
> If a class is constructed via operator new and all the vftable entries it references are marked import, emit local vftables and store it in the object after the constructors run.  If a vftable entry it references is not marked import, report an error.
>
> If a class is constructed via a local or global variable and all the vftable entries it references are marked import, create a `dllimport available_externally` vftable.  Otherwise create a normal `dllimport external` vftable.
>
> I believe this behavior captures the best behavior across the spectrum of functionality we all care about: it supports devirtualization, constexpr and importing classes which don't have all their vftable methods exported.


I'll try to implement this approach except for special handling for constriction via new that seems to be out of scope for this issue and can be implemented independent later. Small addition, I think there is no sense to check if vftable references to entry that is not marked as dllimport. Linker will do this work for us and in some cases function may come from libraries (static or dynamic) but in the source may not be properly marked as dllimport (it is the behavior that MSVC does check it in compiler and relays on linker).


http://reviews.llvm.org/D22034