clang/win: Attempt to fix component build after r194273.

clang/win: Attempt to fix component build after r194273.

We're seeing this error on the clang/win bots:

blink_platform_unittests.HarfBuzzShaperTest.obj :
error LNK2019: unresolved external symbol
"public: __thiscall blink::HarfBuzzShaper::HarfBuzzRun::~HarfBuzzRun(void)"
(??1HarfBuzzRun@HarfBuzzShaper@blink@@QAE@XZ) referenced in function
"private: virtual void __thiscall `anonymous namespace'::HarfBuzzShaperTest_ResolveCandidateRunsLatin_Test::TestBody(void)"
(?TestBody@HarfBuzzShaperTest_ResolveCandidateRunsLatin_Test@?A@@EAEXXZ)

We used to think that cl.exe (MSVC's compiler) doesn't apply __dllexport on
an outer class to inner classes (and continue to do so), but it's not clear
to me why this builds with cl.exe but doesn't with clang-cl.exe.  We'll have
to investigate, but for now this will get our component build bots back to
green.  (Similar to https://codereview.chromium.org/1027693006/, also see
discussion there.)

BUG=82385
R=hans@chromium.org
TBR=eae

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=194314

[Nico, 2015-04-23 17:40:55]

thakis@chromium.org changed reviewers:
+ eae@chromium.org, hans@chromium.org

[Nico, 2015-04-23 17:40:59]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2015-04-23 17:41:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1058613007/1

[hans, 2015-04-23 18:08:38]

> We used to think that cl.exe (MSVC's compiler) doesn't apply __dllexport on
> an outer class to inner classes (and continue to do so), but it's not clear
> to me why this builds with cl.exe but doesn't with clang-cl.exe.

Arm-chair theory: HarfBuzzShaper doesn't have an explicit destructor, so we
synthesize one, it gets inlined into this test, and tries to call ~HarfBuzzRun
because it has a 'Vector<OwnPtr<HarfBuzzRun>, 16> m_harfBuzzRuns;' member.

Maybe HarfBuzzShaper should have an out-of-line dtor since it's non-trivial.

lgtm for this fix in the meantime, though.

[Nico, 2015-04-23 18:11:50]

On 2015/04/23 18:08:38, hans wrote:
> > We used to think that cl.exe (MSVC's compiler) doesn't apply __dllexport on
> > an outer class to inner classes (and continue to do so), but it's not clear
> > to me why this builds with cl.exe but doesn't with clang-cl.exe.
> 
> Arm-chair theory: HarfBuzzShaper doesn't have an explicit destructor, so we
> synthesize one, it gets inlined into this test, and tries to call ~HarfBuzzRun
> because it has a 'Vector<OwnPtr<HarfBuzzRun>, 16> m_harfBuzzRuns;' member.

Ah, that makes sense.

I guess cl.exe doesn't inline dtors of dllexported classes, and I vaguely
remember us discussing this too and then deciding not to do that since it
usually works and can be faster (?)

All good then, this CL is good as-is.

[hans, 2015-04-23 18:16:57]

On 2015/04/23 18:11:50, Nico (OOO sick) wrote:
> I guess cl.exe doesn't inline dtors of dllexported classes,

They never inline any dllexported methods I think, but we do - for speed :)

[Nico, 2015-04-23 18:32:41]

Committed patchset #1 (id:1) manually as 194314 (presubmit successful).