Commit Graph

3 Commits

Author SHA1 Message Date
Reid Kleckner a283e48f69 Revert "Fix for PR32990"
This reverts commit r321239. It broke the Chromium DLL build:

[8834/50217] LINK(DLL) icui18n.dll icui18n.dll.lib icui18n.dll.pdb
FAILED: icui18n.dll icui18n.dll.lib icui18n.dll.pdb
zrule.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) public: void __cdecl icu_60::UnicodeString::`vbase destructor'(void)"
(__imp_??_DUnicodeString@icu_60@@QEAAXXZ)

llvm-svn: 321298
2017-12-21 19:44:23 +00:00
Erich Keane abf9d6648c Fix for PR32990
This fixes the bug in https://bugs.llvm.org/show_bug.cgi?id=32990.

Patch By: zahiraam
Differential Revision: https://reviews.llvm.org/D39063

llvm-svn: 321239
2017-12-21 02:07:46 +00:00
Reid Kleckner 3da37e05f7 [MS] Don't bail on replacing dllimport vbase dtors with base dtors
Fix PR32990 by effectively reverting r283063 and solving it a different
way.

We want to limit the hack to not replace equivalent available_externally
dtors specifically to libc++, which uses always_inline. It seems certain
versions of libc++ do not provide all the symbols that an explicit
template instantiation is expected to provide.

If we get to the code that forms a real alias, only *then* check if this
is available_externally, and do that by asking a better question, which
is "is this a declaration for the linker?", because *that's* what means
we can't form an alias to it.

As a follow-on simplification, remove the InEveryTU parameter. Its last
use guarded this code for forming aliases, but we should never form
aliases to declarations, regardless of what we know about every TU.

llvm-svn: 315656
2017-10-13 00:53:02 +00:00