There is a build error on win with following gn args:
target_cpu = "x86"
enable_nacl = false
is_component_build = true
is_debug = true
use_lld = false
win_console_app = true
use_goma = true

Here is output:
$ autoninja webkit_unit_tests
[86/12905] LINK(DLL) content_public_common_mojo_bindings_shared
LINK : fatal error LNK1104: cannot open file 'speech_recognition_error_code_shared.dll.lib'

Though I can build the file, there is still no
speech_recognition_error_code_shared.dll.lib:
$ autoninja speech_recognition_error_code_shared.dll.lib
$ ls speech_recognition_error_code_shared.*
speech_recognition_error_code_shared.dll     speech_recognition_error_code_shared.ilk
speech_recognition_error_code_shared.dll.pdb

I guess if we doesn't have any class/struct, some generator
doesn't create *dll.lib but someone requres it.
Here is generated mojom.h:
https://cs.chromium.org/chromium/src/out/Debug/gen/content/public/common/speech_recognition_error_code.mojom.h?q=speech_recognition_error_code+package:chromium&dr=CSs

Following is discussion log from 
https://chromium-review.googlesource.com/c/chromium/src/+/1078027

Nico Weber:
This is probably more an llvm-lib than an lld thing.
I guess llvm-lib allows this only when building thin archives (?) Else we could use llvm-lib even if use_lld is false.
It'd be good to have a bug to discuss options in. If we want to support this, the mojo compiler should probably write this dummy struct if there are no symbols, or it should use source_sets instead of static libs.

Reid Kleckner:
My first guess is that the Visual C++ linker doesn't make import libraries (.lib files) when the DLL has zero exports. This enum-only mojom file results in a binding DLL that doesn't export anything. LLD appears to always create an accompanying .lib file when it makes a DLL, even if there are no exports.
I think llvm-lib is only used to make static archives, so I don't think it's related to this issue.
Perhaps a proper fix would be for the mojo C++ binding generator to always export at least one dummy symbol that nobody uses when no structs are involved.

Ken Rockot:
The mojom GN template spits out component targets, so I guess we could just set static_component_type = "source_set" in those. I don't know the reasons why component() even defaults to static_library though, so maybe I'm overlooking something. If it works, I'd probably prefer that over generating a dummy symbol.

Peter Collingbourne:
Or we can change our link.exe wrapper to create an empty import library before running the linker.

Nico Weber:
component used to use source_set, but then all .obj files in there get linked in instead of just the needed ones, making binaries larger and links slower, so we changed that a while ago. If this generates components, then the dummy symbol is probably the way to go if we want to care about link.exe (which we probably do want to care about).