There is no usermode header which has the DXGI1.6 interfaces included
unfortunately. This adds the interfaces to the module which is required
for IDXGIAdapter4 interface.
Add the extensions for the Direct3D v10 API to enable access to the
newer DXGISwapChain interfaces. Additionally, correct the linking to
ensure that we pick up the v10 version of the import library.
* Fix two issues with the SwiftGlibc module map.
The issues are:
- Today, some submodules in `SwiftGlibc` fail to provide definitions that
they should contain. As a consequence, Swift fails to import some code
that compiles correctly with standalone Clang. As just one example,
including `signal.h` should make the type `pid_t` available, but it
currently does not.
- `SwiftGlibc` is not compatible with the libc++ module map. Trying to
include libc++ headers in a C++ module imported into Swift results in an
error message about cyclic dependencies.
This change fixes both of these issues by making it so that `SwiftGlibc`
no actually longer defines a module map for the glibc headers but merely makes
all of the symbols from those headers available in a module that can be
imported into Swift. C / Objective-C / C++ code, on the other hand, will now
include the glibc headers texually.
For more context on the two issues and this fix, see this forum
discussion:
https://forums.swift.org/t/problems-with-swiftglibc-and-proposed-fix/37594
This change only modifies `glibc.modulemap.gyb` for the time being but
leaves `bionic.modulemap.gyb` and `libc-openbsd.modulemap.gyb` unchanged. The
intent is to fix these in the same way, but it will be easier to do this
in separate PRs that can be tested individually.
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
Co-authored-by: Marcel Hlopko <hlopko@google.com>
In some cases when building the `XAudio` module, we would end up going
down C++ paths:
```
C:\Program Files (x86)\Windows Kits\10\/Include/10.0.17763.0/um/xaudio2.h:61:26: error: 'uuid' attribute is not supported in C
interface __declspec(uuid("2B02E3CF-2E0B-4ec3-BE45-1B2A3FE7210D")) IXAudio2;
^
<module-includes>:29:10: note: in file included from <module-includes>:29:
^
```
Although this works with newer SDKs, it does not work with older SDKs.
Filter out the module for the time being with a requirement on `C++`.
This should be possible to use with `-enable-cxx-interop`.
Add the module definitions for:
- Direct3D v12
- XAudio 2.9
- XInput 1.4
Additionally, add the following, unusable modules:
- DXCore
DXCore requires C++ Support (C++11 or newer to be precise) and is not
yet available until C++ interop can be made to work fully.
The SensorsAPI headers are not part of the Windows umbrella header and
do not get pulled into the module through some transitive set.
Explicitly list the SensorsAPIs contract into the WinSDK modulemap to
allow use of the api contract from Swift.
Both `immdev.h` & `windows.h` include `imm.h`, and sometimes this header gets assigned to the module containing `windows.h` (currently `WinSDK.WinSock2`) instead of the Internationalization submodule
This replaces swiftMSVCRT with swiftCRT. The big difference here is
that the `visualc` module is no longer imported nor exported. The
`visualc` module remains in use for a singular test wrt availability,
but this should effectively remove the need for the `visualc` module.
The difference between the MSVCRT and ucrt module was not well
understood by most. MSVCRT provided ucrt AND visualc, combining pieces
of the old MSVCRT and the newer ucrt. The ucrt module is what you
really wanted most of the time, however, would need to use MSVCRT for
the convenience aliases for type-generic math and the deprecated math
constants.
Unfortunately, we cannot shadow the `ucrt` module and create a Swift SDK
overlay for ucrt as that seems to result in circular dependencies when
processing the `_Concurrency` module.
Although this makes using the C library easier for most people, it has a
more important subtle change: it cleaves the dependency on visualc.
This means that this enables use of Swift without Visual Studio for the
singular purpose of providing 3 header files. Additionally, it removes
the need for the installation of 2 of the 4 support files. This greatly
simplifies the deployment process on Windows.
The MSDN documentation indicates that you should link against the
`Pathcch.lib` import library when using functions from `pathcch.h` which
can also be verified by use functions failing to link due to unresolved
symbols. Add the missing linking to enable autolinking for `WinSDK`.
Currently winver.h gets included into `WinSDK.WinSock2`, however its usages might not be related to sockets, and it requires linking against `Version.Lib`
`WinSDK.core.console` only specified `consoleapi.h` header, while `consoleapi2.h` & `consoleapi3.h` were included in the WinSock2 submodule since these headers are included by `windows.h`
When linking on a case sensitive file system, the import library must be
named with the matching case. The import library is named
`ComDlg32.Lib` in the SDK, adjust the case.
The WinSDK module failed to expose WinBase properly for reuse, which the
newer clang seems to object to (via an assertion). Add a separate
module for WinBase which allows reuse of the definitions without causing
conflicts. This caused some additional fallout requiring the creation
of the WinSVC submodule (service handling, part of security and
identity) and splitting up the legacy WinSock header from the WinSock2
module. This allows building Foundation again on Windows.
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.
