A minor update to the Windows SDK broke our module maps. This fixes the
issue by re-separating a few modules. For backward-compatibility and
proper export of symbols, the split headers are also included in the
main `ucrt` module.
Building with the Windows static SDK uncovered issues in the Windows
module maps. Some of the headers were missing and others had incorrect
layering. This updates the module maps to build with the static Windows
SDK.
These were split out in #79751. However, this split is not needed for
these. Furthermore, modulemaps have bugs when it comes to re-exporting
some modules, resulting in missing exports.
Add a couple of submodules for these modules to further modularise the
headers. This might expose additional APIs now as some of these headers
would not have been indirectly included and wind up in the wrong module.
On Unicies `sys/stat.h` will provide `mkdir`. Windows provides the
POSIX requirement through the portable name `_mkdir` which is declared
in the `direct.h` header. This adds the additional header to the `ucrt`
module to allow access to this function.
Because Microsoft inlines the definitions of the printf family of
functions, we end up with undefined references to them. Add an explicit
request to link against the `legacy_stdio_definitions` library when
`ucrt.C.stdio` is used which provides out-of-line definitions for them.
This fixes the building of the `stdlib/VarArgs' test.
Since `stdin`, `stdout`, and `stderr` are defined via macros, we cannot see them
on the swift side. Replicate these by hand. Expose `STDIN_FILENO`,
`STDOUT_FILENO`, and `STDERR_FILENO` for compatibility with other libc
implementations. This reduces the need for changing the codebase unnecessarily
for MSVCRT.
This adds the swiftMSVCRT module which is similar in spirit to swiftGlibc and
swiftDarwin, exposing the Microsoft C Runtime library to swift. Furthermore,
disable pieces of the standard library which are not immediately trivially
portable to Windows. A lot of this functionality can still be implemented and
exposed to the user, however, this is the quickest means to a PoC for native
windows support.
As a temporary solution, add a -DCYGWIN flag to indicate that we are building
for the cygwin windows target. This allows us to continue supporting the cygwin
environment whilst making the windows port work natively against the windows
environment (msvc). Eventually, that will hopefully be replaced with an
environment check in swift.
