These constants should be freely inlined as they are simply casts or
redeclarations of macros which are not importable due to the "complex"
nature of them (they involve casts or otherwise non-integral constants).
Conditionalise some of the conformances of `WindowsBool` to not be
available without reflection or on embedded. This matches how
`DarwinBoolean` is handled.
ucrt symbols are already implicitly available after an `import WinSDK` statement, however, WinSDK generated Swift interface does not indicate that.
Besides, WinSDK Swift overlay uses `time_t` in its public interface, which is declared in ucrt, but there is no corresponding import statement.
This change adds the import statement, to make the dependencies & exports more clear for the users, and to help with IDE integration.
Rather than stored properties for constants that are not imported via
the clang importer, use computed properties. Although this breaks ABI,
there is no guarantee of ABI stability on Windows. The remaining
strings are left as stored properties as they may be interned by the
system.
Due to the type differences between 32-bit and 64-bit, the SDK overlay
would fail to build on Windows. This adjusts that to allow building the
SDK overlay on 32-bit Windows again.
The WinReg.h constants for the register hives are not imported through
the clang importer due to the complicated casting. Duplicate the values
to allow usage in Swift.
This makes it more explicit what the install component of a target
library is if you don't see one (and its marked as IS_SDK_OVERLAY).
Explicit in this case makes more sense, as you don't have to rely on
knowledge of how `add_swift_target_library` is implemented to understand
what component is used to install the target.
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
This allows the conversion of the Windows `BOOL` type to be converted to
`Bool` implicitly. The implicit bridging allows for a more ergonomic
use of the native Windows APIs in Swift.
Due to the ambiguity between the Objective C `BOOL` and the Windows
`BOOL`, we must manually map the `BOOL` type to the appropriate type.
This required lifting the mapping entry for `ObjCBool` from the mapped
types XMACRO definition into the inline definition in the importer.
Take the opportunity to simplify the mapping code.
Adjust the standard library usage of the `BOOL` type which is now
eclipsed by the new `WindowsBool` type, preferring to use `Bool`
whenever possible.
Thanks to Jordan Rose for the suggestion to do this and a couple of
hints along the way.
This is the bare minimum of the WinSock2 constants that are needed for
the Foundation port to Windows which uses the socket APIs for
`-[NSTask run]` internal signalling.
This constant is needed for SHFileOperation which is needed for
Foundation. Unfortunately, it is a complex macro which will not be
imported by the ClangImporter.
Since handle's are so common place on Windows and the clang importer cannot
import the complex macro for INVALID_HANDLE_VALUE, define it locally to provide
an easier path to writing swift code on Windows. This repairs the Windows
builds.
Introduce a WinSDK overlay for Windows. This allows us to define some
shared constants that are not correctly imported right now. This cleans
up the logic in the swift side of things and aids in the bring up.
Now that we have a SDK overlay for Windows, we should structure the tree
according to the OS family.
