Actually, it's just the undefined symbol that's breaking the build.

Last good:
https://build.chromium.org/p/chromium.fyi/builders/CrWinClangLLD/builds/5908

First bad:
https://build.chromium.org/p/chromium.fyi/builders/CrWinClangLLD/builds/5909

I'm guessing the missing symbol is due to https://chromium-review.googlesource.com/606702
"Use import binding instead of manual thunking for chrome_elf."

I'm pretty sure we pass -Werror to the linker, so there are two more bugs:
1. -Werror doesn't consistently turn warnings into errors (e.g. the manifest tool warning)
2. We emit that manifest tool warning even though everything's perfectly fine

Rui, can you take a look?

Eric Beckmann put up https://reviews.llvm.org/D37240 to make the manifest tool warning go away.

Comment 3 on missing symbol confirmed locally with revert of 86ac09aa98e574ca69c9cd090f105683294a64b0 and subsequent successful local WinClangLLD build. Previous comments on issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=759266

 Issue 759266  has been merged into this issue.

I accidentally looked at this a bit. I think the problem is that https://chromium-review.googlesource.com/c/chromium/src/+/621367/12/components/crash/content/app/crashpad.cc removed the `extern "C"` around RequestSingleCrashUploadImpl(), so _RequestSingleCrashUploadImpl truly doesn't exist. However, https://cs.chromium.org/chromium/src/chrome_elf/chrome_elf.def?type=cs&sq=package:chromium still references it.

link.exe apparently doesn't care about references to non-existent symbols from .def files, while lld does care.

I think the Right Fix is to remove the references from the .def file -- siggi, does that sound right to you?

No, removing the symbols will break the link in the dependents of chrome_elf.dll, not to mention crash reporting if the link were to succeed. The function is still declared extern "C" here: https://chromium-review.googlesource.com/c/chromium/src/+/621367/12/components/crash/content/app/crash_export_thunks.h#22, and this should be what the definition sees?

I also believe link.exe does a search for "likely" candidates to export, I believe I've seen it snag various decorations of the base name exported in a .def file.

Huh, weirdness:
> dumpbin /exports out\Release64\chrome_elf.dll
...

1    E 00034A88 RequestSingleCrashUploadImpl = ?RequestSingleCrashUploadImpl@crash_reporter@@YAXAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z (void __cdecl crash_reporter::RequestSingleCrashUploadImpl(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &))

Apparently the definition of that function is not seeing the right declaration, or the intended definition is altogether missing.
Investigating.

Oh, my, <deity>. This <https://chromium-review.googlesource.com/c/chromium/src/+/621367/12/components/crash/content/app/crash_export_thunks.cc#14> was mis-typed. It should have been named "RequestSingleCrashUploadImpl", but link.exe apparently searches aggressively for something, anything to stop the gap, and finds decorated(crash_reporter::RequestSingleCrashUploadImpl).
Please don't implement bug compatibility with this <atrocity>. Will fix.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2d9f09dcf57061551782f4549e149996a5245164

commit 2d9f09dcf57061551782f4549e149996a5245164
Author: Sigurdur Asgeirsson <siggi@chromium.org>
Date: Thu Aug 31 20:27:21 2017

Fix typo in a function exported from chrome_elf.

Only by a link.exe misfeature is the link succeeding as-is, by
producing broken binaries.

Bug:  760385 
Change-Id: I3a4b809fb7f738deb4b9ca41c0a562c1735a63be
Reviewed-on: https://chromium-review.googlesource.com/646594
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498978}
[modify] https://crrev.com/2d9f09dcf57061551782f4549e149996a5245164/components/crash/content/app/crash_export_thunks.cc

Fix looks good. Pulled ToT including 2d9f09dcf57061551782f4549e149996a5245164 and successfully built CrWinClangLLD64 locally. Thanks!

Thanks for verifying! Out of interest, what are you using lld for? Just for fun?

Pretty much for fun and "being different." I migrated to clang last year, and I like that lld now allows me to easily enable thinlto by basically reverting 3ba9c67e210df1f039f93548c1ad5bb2dfe3a945 and setting flto to thin.

The missing symbol is resolved, but the builders are still failing. I did not catch this one locally because I had treat_warnings_as_errors = false.

FAILED: obj/chrome/browser/browser_0/installed_programs_win.obj 
../../third_party/llvm-build/Release+Asserts/bin/clang-cl.exe /nologo /showIncludes  @obj/chrome/browser/browser_0/installed_programs_win.obj.rsp /c ../../chrome/browser/conflicts/installed_programs_win.cc /Foobj/chrome/browser/browser_0/installed_programs_win.obj /Fd"obj/chrome/browser/browser_0_cc.pdb"
In file included from ../../chrome/browser/conflicts/installed_programs_win.cc:5:
In file included from ../..\chrome/browser/conflicts/installed_programs_win.h:8:
c:\b\c\win_toolchain\vs_files\f53e4598951162bad6330f7a167486c7ae5db1e5\win_sdk\bin\..\..\vc\include\memory(1195,3):  error: delete called on non-final 'MsiUtil' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
                delete _Ptr;
                ^
c:\b\c\win_toolchain\vs_files\f53e4598951162bad6330f7a167486c7ae5db1e5\win_sdk\bin\..\..\vc\include\memory(1397,4):  note: in instantiation of member function 'std::default_delete<MsiUtil>::operator()' requested here
                        this->get_deleter()(get());
                        ^
../../chrome/browser/conflicts/installed_programs_win.cc(174,30):  note: in instantiation of member function 'std::unique_ptr<MsiUtil, std::default_delete<MsiUtil> >::~unique_ptr' requested here
    std::unique_ptr<MsiUtil> msi_util) {
                             ^
1 error generated.

From my local CrWinClangLLD64 build....

In file included from ../../chrome/browser/conflicts/installed_programs_win.cc:5:
In file included from ../..\chrome/browser/conflicts/installed_programs_win.h:8:
c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.11.25503\include\memory(1999,3):  warning: delete called on non-final 'MsiUtil' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
                delete _Ptr;
                ^
c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.11.25503\include\memory(2203,4):  note: in instantiation of member function 'std::default_delete<MsiUtil>::operator()' requested here
                        this->get_deleter()(get());
                        ^
../../chrome/browser/conflicts/installed_programs_win.cc(174,30):  note: in instantiation of member function 'std::unique_ptr<MsiUtil, std::default_delete<MsiUtil> >::~unique_ptr' requested here
    std::unique_ptr<MsiUtil> msi_util) {
                             ^
1 warning generated.

That one is  bug 673171 . It should be fixed on Windows now, at least some of the Windows bots are cycling green. iOS and Android are still unhappy.