In https://github.com/swiftlang/swift/pull/84792 we have added
implementation to `Equatable` and `Hashable` there are two issues with
this.
1. Uses of type `GUID` would be emitted in the `swiftinterface` file as
`_GUIDDef._GUID` since it is an external type. but the type name in the
imported header file is `GUID` and not `_GUID`
2. When compiling using `-cxx-interoperability-mode=default`, there are
duplicate definition errors for `==` since the c++ header file defines
the same operator.
Proposed changes:
1. Add a type alias `typealias _GUID = GUID` to address the naming
mismatch in the generated interface file
2. Add conditional definitions of the equatable implementation to avoid
duplicate definitions.
---------
Co-authored-by: Jonathan Grynspan <grynspan@me.com>
On Windows, `GUID` is a currency type and (along with its various
typedefs) is used pervasively Windows offers `IsEqualGUID()` and
`UuidHash()` for comparing and hashing them, respectively, but
`IsEqualGUID()` is a macro in C mode and `UuidHash()` only provides a
16-bit hash. We should provide conformance to these protocols in the
WinSDK overlay to provide equivalent functionality in Swift.
This PR changes the name of the clang module introduced in #83914 from
`_GUID` to `_GUIDDef`. This change is necessary because the Windows SDK
declares a type named `_GUID` and Swift gets confused when a module and
a type have the same name.
This confusion is the motivation for
[SE-0491](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0491-module-selectors.md),
but we can't just wait for a fix because the new module is a
source-breaking change and clients won't be able to adopt the proposed
syntax for some time.
This fixes modularization errors that arise when importing a C++ header that contains `#include <guiddef.h>`, which might hijack this header from the WinSDK module where it belongs.
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 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.
