I've verified that all of the header files in this module already
contain their own `extern "C"` blocks that are activated if compiling as
C++.
The additional [extern_c] attribute causes problems for some headers,
like PathCch.h, that define additional overloads of functions when
compiled as C++. The "global" [extern_c] essentially switches off name
mangling with these overloads, which causes them to conflict with the
functions they are overloading.
See here for more context:
https://github.com/apple/swift/pull/30233#issuecomment-601594221
See here for an example of failures caused by the [extern_c]:
https://ci-external.swift.org/job/swift-PR-windows/869/console
(Search for "PathCch.h".)
This extends the WinSDK module definition further to better modularise
the headers. This should improve the header organisation as well as
setup additional autolink rules.
Be more aggressive about using the autolinking functionality of modules
on Windows. This makes it easier to use WinSDK in Swift as the link
dependencies are implicitly taken care of.
Split out the User32 interfaces from the previously owning module
(WinSock2). This improves the debugging experience and more accurately
reflects the module structure but should not impact the ability to build
the swift runtime.
Additional APISets are required to implement the Foundation API surface.
Expand the module to include that. Unfortunately, I have not been able
to get the ImageHelp or the DebugHelp APIs or the RTLSupport APISet
covered under the module. Those are required to get stack captures to
work.
