Windows component build become 1.3~1.4x faster

[Takuto Ikuta]

Hi chromium developers (especially on windows).

I just landed a CL enabling a new clang flag "/Zc:dllexportInlines-" (draft document) collaborating with chrome c++ toolchain team (hans, thakis and rnk).

This flag makes windows component build 1.3~1.4x faster with goma and 1.1~1.3x faster without goma.

I hope this give windows developer better experience of faster edit and test cycles on windows.

But you may see linker error like

[97/1686] LINK net_unittests.exe
FAILED: net_unittests.exe
ninja -t msvc -e environment.x86 -- ../../third_party/llvm-build/Release+Asserts/bin/lld-link.exe /nologo /OUT:./net_unittests.exe /PDB:./net_unittests.exe.pdb @./net_unittests.exe.rsp
lld-link: error: undefined symbol: "bool __thiscall net::internal::ClientSocketPoolBaseHelper::Group::RequestWithHandleHasJobForTesting(class net::ClientSocketHandle const *) const" (?RequestWithHandleHasJobForTesting@Group@ClientSocketPoolBaseHelper@internal@net@@QBE_NPBVClientSocketHandle@4@@Z)
>>> referenced by obj/net/net_unittests/client_socket_pool_base_unittest.obj:("bool __thiscall net::internal::ClientSocketPoolBaseHelper::RequestInGroupWithHandleHasJobForTesting(class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>> const &, class net::ClientSocketHandle const *) const" (?RequestInGroupWithHandleHasJobForTesting@ClientSocketPoolBaseHelper@internal@net@@QBE_NABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PBVClientSocketHandle@3@@Z))

If you see this kind of error, please add export attribute to the class (this is recommended, but not always work) or function where the undefined symbol is defined.

Also if you see other strange behavior, please let me know.

Thanks, Takuto

[Hans Wennborg]

The Clang User's Manual
https://clang.llvm.org/docs/UsersManual.html#the-zc-dllexportinlines-option
has some info on how this flag works and why it can create new link
errors.

[bruce...@chromium.org]

Another (related) benefit of this change is that .obj files get much smaller in component builds. In one test of this change the total size of my .obj files dropped from 30.7 GB to 18.5 GB. This has obvious implications for disk cache effectiveness, the ability to have multiple output directories on a small disk, and on link times (especially on slow disks or after the files have aged out of the disk cache).

Excellent work.

[Nico Weber]

There's a longer write-up of what this change does at http://blog.llvm.org/2018/11/30-faster-windows-builds-with-clang-cl_14.html for people who are curious.