In mingw environments, resources are normally compiled to resource object files directly, instead of letting the linker convert them to COFF format.
Since some time, GCC supports the notion of a default manifest object. When invoking the linker, GCC looks for the default manifest object file, and if found in the expected path, it is added to linker commands.
The default manifest is one that indicates support for the latest known versions of windows, to implicitly unlock the modern behaviours of certain APIs. (No stance taken on whether doing that implicitly is a good thing.)
Not all mingw/gcc distributions include this file, but e.g. in msys2, the default manifest object is distributed in a separate package (which can be but might not always be installed).
This means that even if user projects only use one single resource object file, the linker can end up with two resource object files, and thus needs to support merging them.
The default manifest has a language id of zero, and GNU ld has got logic for dropping a manifest with a zero language id, if there's another manifest present with a nonzero language id. If there are multiple manifests with a nonzero language id, the merging process errors out.
Replicate the same logic from GNU ld in llvm's WindowsResourceParser class. (Should we limit this behaviour to object files, and/or when the mingw flag is used?)
Does yaml2obj lack any features that prevents it from generating manifest-lang0.o and other object files?