clang/win: Attempt to fix component build after #321658.

clang/win: Attempt to fix component build after #321658.

BUG=82385
NOTRY=true
R=hans@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/e28e5618dfc74f02bb7d26b1fbe02c22f26e3ef2

[Nico, 2015-03-21 18:04:12]

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

[Nico, 2015-03-21 18:06:05]

The error is:

FAILED: C:\b\depot_tools\python276_bin\python.exe gyp-win-tool
link-with-manifests environment.x64 True base_unittests.exe
"C:\b\depot_tools\python276_bin\python.exe gyp-win-tool link-wrapper
environment.x64 False link.exe /nologo /OUT:base_unittests.exe
@base_unittests.exe.rsp" 1 mt.exe rc.exe
"obj\base\base_unittests.base_unittests.exe.intermediate.manifest"
obj\base\base_unittests.base_unittests.exe.generated.manifest
..\..\build\win\compatibility.manifest
base_unittests.stack_sampling_profiler_unittest.obj :error LNK2019: unresolved
external symbol "public: __cdecl
base::StackSamplingProfiler::Module::~Module(void)"
(??1Module@StackSamplingProfiler@base@@QEAA@XZ) referenced in function "public:
class std::vector<struct base::StackSamplingProfiler::Module,class
std::allocator<struct base::StackSamplingProfiler::Module> > & __cdecl
std::vector<struct base::StackSamplingProfiler::Module,class
std::allocator<struct base::StackSamplingProfiler::Module> >::operator=(class
std::vector<struct base::StackSamplingProfiler::Module,class
std::allocator<struct base::StackSamplingProfiler::Module> > const &)"
(??4?$vector@UModule@StackSamplingProfiler@base@@V?$allocator@UModule@StackSamplingProfiler@base@@@std@@@std@@QEAAAEAV01@AEBV01@@Z)

base_unittests.stack_sampling_profiler_unittest.obj :error LNK2019: unresolved
external symbol "public: __cdecl
base::StackSamplingProfiler::Frame::~Frame(void)"
(??1Frame@StackSamplingProfiler@base@@QEAA@XZ) referenced in function "public:
class std::vector<class std::vector<struct
base::StackSamplingProfiler::Frame,class std::allocator<struct
base::StackSamplingProfiler::Frame> >,class std::allocator<class
std::vector<struct base::StackSamplingProfiler::Frame,class
std::allocator<struct base::StackSamplingProfiler::Frame> > > > & __cdecl
std::vector<class std::vector<struct base::StackSamplingProfiler::Frame,class
std::allocator<struct base::StackSamplingProfiler::Frame> >,class
std::allocator<class std::vector<struct base::StackSamplingProfiler::Frame,class
std::allocator<struct base::StackSamplingProfiler::Frame> > > >::operator=(class
std::vector<class std::vector<struct base::StackSamplingProfiler::Frame,class
std::allocator<struct base::StackSamplingProfiler::Frame> >,class
std::allocator<class std::vector<struct base::StackSamplingProfiler::Frame,class
std::allocator<struct base::StackSamplingProfiler::Frame> > > > const &)"
(??4?$vector@V?$vector@UFrame@StackSamplingProfiler@base@@V?$allocator@UFrame@StackSamplingProfiler@base@@@std@@@std@@V?$allocator@V?$vector@UFrame@StackSamplingProfiler@base@@V?$allocator@UFrame@StackSamplingProfiler@base@@@std@@@std@@@2@@std@@QEAAAEAV01@AEBV01@@Z)

base_unittests.exe : fatalerror LNK1120: 2 unresolved externals


hans: Since these dtors are out-of-line here, I'm not sure I buy the usual
explanation of "well, cl.exe inlines them". (Maybe I'm misremembering the usual
explanation, though.)

[hans, 2015-03-21 18:47:29]

On 2015/03/21 18:06:05, Nico wrote:
> hans: Since these dtors are out-of-line here, I'm not sure I buy the usual
> explanation of "well, cl.exe inlines them". (Maybe I'm misremembering the
usual
> explanation, though.)

Hmm, strange. I'm positive that MSVC does not export inner classes.

The references seem to come from the 'modules' and 'samples' vectors in
StackSamplingProfiler::Profile. It's the operator=, so maybe it's from Profile's
operator=, which _is_ exported, but also available inline. It's possible that
the out-of-library user of Profile chooses to inline the operator=.

lgtm for the fix anyway

[Nico, 2015-03-21 19:01:38]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2015-03-21 19:02:01]

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

[hans, 2015-03-21 19:11:53]

On 2015/03/21 18:47:29, hans wrote:
> On 2015/03/21 18:06:05, Nico wrote:
> > hans: Since these dtors are out-of-line here, I'm not sure I buy the usual
> > explanation of "well, cl.exe inlines them". (Maybe I'm misremembering the
> usual
> > explanation, though.)
> 
> Hmm, strange. I'm positive that MSVC does not export inner classes.
> 
> The references seem to come from the 'modules' and 'samples' vectors in
> StackSamplingProfiler::Profile. It's the operator=, so maybe it's from
Profile's
> operator=, which _is_ exported, but also available inline. It's possible that
> the out-of-library user of Profile chooses to inline the operator=.

This is an interesting problem actually. Us marking inline dllimported functions
available_externally allows for some nice optimization, but if the inline
function refers to other functions which are not exported, it could create
problems like this one:

  void g();
  void __declspec(dllimport) inline f() { g(); }
  void h() { f(); }

With optimizations enabled, Clang will generate an object file that references g
here, which won't work if g is in another dll.

[Nico, 2015-03-21 20:54:30]

On 2015/03/21 19:11:53, hans wrote:
> On 2015/03/21 18:47:29, hans wrote:
> > On 2015/03/21 18:06:05, Nico wrote:
> > > hans: Since these dtors are out-of-line here, I'm not sure I buy the usual
> > > explanation of "well, cl.exe inlines them". (Maybe I'm misremembering the
> > usual
> > > explanation, though.)
> > 
> > Hmm, strange. I'm positive that MSVC does not export inner classes.
> > 
> > The references seem to come from the 'modules' and 'samples' vectors in
> > StackSamplingProfiler::Profile. It's the operator=, so maybe it's from
> Profile's
> > operator=, which _is_ exported, but also available inline. It's possible
that
> > the out-of-library user of Profile chooses to inline the operator=.
> 
> This is an interesting problem actually. Us marking inline dllimported
functions
> available_externally allows for some nice optimization, but if the inline
> function refers to other functions which are not exported, it could create
> problems like this one:
> 
>   void g();
>   void __declspec(dllimport) inline f() { g(); }
>   void h() { f(); }
> 
> With optimizations enabled, Clang will generate an object file that references
g
> here, which won't work if g is in another dll.

It doesn't seem to be a frequent problem in practice, so enabling optimizations
is probably the right tradeoff. Thanks for the explanation!

[commit-bot: I haz the power, 2015-03-22 03:30:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-22 03:30:56]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Nico, 2015-03-22 04:45:24]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2015-03-22 04:45:59]

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

[commit-bot: I haz the power, 2015-03-22 04:54:57]

Patchset 1 (id:??) landed as
https://crrev.com/e28e5618dfc74f02bb7d26b1fbe02c22f26e3ef2
Cr-Commit-Position: refs/heads/master@{#321703}

[Nico, 2015-03-22 04:55:15]

Committed patchset #1 (id:1) manually as
e28e5618dfc74f02bb7d26b1fbe02c22f26e3ef2 (tree was closed).

[Mike Wittman, 2015-03-23 15:50:43]

wittman@chromium.org changed reviewers:
+ wittman@chromium.org

[Mike Wittman, 2015-03-23 15:50:45]

Thanks for the fix. I developed these changes under component build (on x64), so
not sure why I didn't see this issue.