Address GUID type definition errors

[mhegazy]

In #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.

[mhegazy]

@grynspan can i get your thoughts about this. I ran into this issue of missing _GUID definiton and duplicate defintion for == operator.

here is my repro:

PS C:> cat .\test.swift
import WinSDK
public func usesGUID(_ x: GUID) {}

PS C:> swiftc.exe -windows-sdk-version 10.0.26100.0 -cxx-interoperability-mode=default test.swift

[grynspan]

GUID is already a typealias of _GUID, so adding a typealias in the other direction will not compile.

I did not see an issue with duplicate definitions of == when building the toolchain from source. I suspect this is an edge case in C++ interop we need to account for on the C++ side (i.e. a competing operator overload from C++ should defer to one defined in Swift.) There is currently no way to specify a symbol should be exposed differently when a client has C++ interop enabled.

What toolchain version are you testing with? There hasn't been a Windows toolchain in a while and the most recent one (Oct 2) has a broken WinSDK.modulemap.

[grynspan]

@compnerd Thoughts?

[compnerd]

GUID is already a typealias of _GUID, so adding a typealias in the other direction will not compile.

I did not see an issue with duplicate definitions of == when building the toolchain from source. I suspect this is an edge case in C++ interop we need to account for on the C++ side (i.e. a competing operator overload from C++ should defer to one defined in Swift.) There is currently no way to specify a symbol should be exposed differently when a client has C++ interop enabled.

I don't think that we have a spelling for this currently. I wonder if we can add a disfavored overload annotation on the native definition via APINotes.

What toolchain version are you testing with? There hasn't been a Windows toolchain in a while and the most recent one (Oct 2) has a broken WinSDK.modulemap.

The builds from https://github.com/thebrowsercompany/swift-build tend to be newer and have more features than the ones from swift.org.

@compnerd Thoughts?

I would be okay with dropping the equatable conformance until we enhance the C++ interop machinery in the compiler. However, canImport(Cxx) definitely does not work - this is already in effect dropping the equatable conformance always.

[grynspan]

We may want to revert the change to add conformances for the moment if it's causing problems, but I'd like to see what the C++ interop folks think before we do that.

[grynspan]

I believe we can cut the knot here by renaming the new == to __equals (or something similar) and using @_implements:

@_implements(Equatable, ==(_:_:))
public static func __equals(lhs: Self, rhs: Self) -> Bool { ... }

[mhegazy]

@grynspan __equals seem to work. updated the PR.

any thoughts about why the alias is needed.

without the alias, the generared name has _ prefix:

extension _GUIDDef._GUID {
  @usableFromInline
  @_transparent internal var uint128Value: Swift.UInt128 {
    @_transparent get {
    withUnsafeBytes(of: self) { buffer in
       
      buffer.baseAddress!.loadUnaligned(as: UInt128.self)
    }
  }
  }
}
extension _GUIDDef._GUID : @retroactive Swift.Equatable {
  @_transparent public static func == (lhs: _GUIDDef._GUID, rhs: _GUIDDef._GUID) -> Swift.Bool {
    lhs.uint128Value == rhs.uint128Value
  }
}

this results in errors about undefined type _GUID

[grynspan]

_GUIDDef._GUID is the actual typename of GUID, which is a typealias of _GUIDDef._GUID. What are the errors you're actually seeing?

[mhegazy]

@grynspan

Error: C:\Users\mhegazy\AppData\Local\Programs\Swift\Platforms\0.0.0\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\WinSDK.swiftmodule\x86_64-unknown-windows-msvc.swiftinterface:276:20: error: no type named '_GUID' in module '_GUIDDef'

274 | }

275 | }

276 | extension _GUIDDef._GUID : @retroactive Swift.Hashable {

| `- error: no type named '_GUID' in module '_GUIDDef'

277 | @_transparent public func hash(into hasher: inout Swift.Hasher) {

278 | hasher.combine(uint128Value)

Error: C:\Users\mhegazy\AppData\Local\Programs\Swift\Platforms\0.0.0\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\Synchronization.swiftmodule\x86_64-unknown-windows-msvc.swiftinterface:7:8: error: failed to build module 'WinSDK' for importation due to the errors above; the textual interface may be broken by project issues or a compiler bug

5 | import Builtin

6 | import Swift

7 | import WinSDK

| - error: failed to build module 'WinSDK' for importation due to the errors above; the textual interface may be broken by project issues or a compiler bug

[grynspan]

@mhegazy I think we can proceed with the change to ==, but the typealias for GUID doesn't really make sense so I'd remove that.

[grynspan]

@swift-ci test

[mhegazy]

@grynspan i am happy to remove the type alias. do you have any pointers on figuring out why the generated interface file has refrences to the undfined type

[grynspan]

I am not able to reproduce the issue you're seeing, so I honestly don't have an answer for you.

A new main-branch toolchain for Windows was just pushed to swift.org. Are you able to try it out and see if the issue reproduces there?

[grynspan]

@swift-ci test

[compnerd]

@swift-ci please test Windows platform

[hjyamauchi]

I encountered a similar _GUID not found error with explicit module builds #85495 There is a small repro test, though it requires a new toolchain build.

[grynspan]

What isn't clear right now is why your toolchain can't find that type. It would help if you could share a repro case including a sample package.

[hjyamauchi]

What isn't clear right now is why your toolchain can't find that type. It would help if you could share a repro case including a sample package.

Right, that's what I think is the issue. A repro needs a new toolchain build and a source file winsdk.swift that just has one line import WinSDK.

[hjyamauchi]

In case you mean you want me to send you a toolchain build, I confirmed that this BCNY build https://github.com/thebrowsercompany/swift-build/releases/tag/20251113.2 reproduces it, if you are okay with a BCNY build. I don't think there are swift.org builds yet.

[grynspan]

@compnerd Are you able to investigate? The most recent official Swift toolchain release has this change in place but doesn't show the problem.

[compnerd]

I think that the issue is unrelated:

PS S:\tmp> swiftc -v .\test.swift -cxx-interoperability-mode=default
Swift version 6.3-dev (LLVM 191c2c1d0ca1eb5, Swift 38fb8e236a546b5)
Target: x86_64-unknown-windows-msvc
"S:\Program Files\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe" -frontend -c -primary-file .\test.swift -target x86_64-unknown-windows-msvc -disable-objc-interop -cxx-interoperability-mode=default -sdk "S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk" -color-diagnostics -Xcc -fcolor-diagnostics -empty-abi-descriptor -no-auto-bridging-header-chaining -module-name test -in-process-plugin-server-path "S:\Program Files\Swift\Toolchains\0.0.0+Asserts\usr\bin\SwiftInProcPluginServer.dll" -plugin-path "S:\Program Files\Swift\Toolchains\0.0.0+Asserts\usr\bin" -plugin-path "S:\Program Files\Swift\Toolchains\0.0.0+Asserts\usr\local\bin" -autolink-library oldnames -autolink-library msvcrt -Xcc -D_MT -Xcc -D_DLL -o C:\Users\abdulras\AppData\Local\Temp\TemporaryDirectory.wcsiZF\test-1.o
"S:\Program Files\Swift\Toolchains\0.0.0+Asserts\usr\bin\clang++.exe" --rsp-quoting=windows -target x86_64-unknown-windows-msvc -nostartfiles -L "S:\Program Files\Swift\Toolchains\0.0.0+Asserts\usr\lib\swift\windows" -L "S:\Program Files\Swift\Toolchains\0.0.0+Asserts\usr\lib\swift\windows\x86_64" -L "S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows" -L "S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\x86_64" "S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\windows\x86_64\swiftrt.obj" C:\Users\abdulras\AppData\Local\Temp\TemporaryDirectory.wcsiZF\test-1.o -I "S:\Program Files\Swift\Platforms\Windows.platform\Developer\SDKs\Windows.sdk" -v -o test.exe
   Creating library test.lib and object test.exp
clang version 21.1.6
Target: x86_64-unknown-windows-msvc
Thread model: posix
InstalledDir: S:\Program Files\Swift\Toolchains\0.0.0+Asserts\usr\bin
Build config: +assertions
 "C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\VC\\Tools\\MSVC\\14.42.34433\\bin\\Hostx64\\x64\\link.exe" -out:test.exe "-libpath:C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\VC\\Tools\\MSVC\\14.42.34433\\lib\\x64" "-libpath:C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\VC\\Tools\\MSVC\\14.42.34433\\atlmfc\\lib\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.22621.0\\ucrt\\x64" "-libpath:C:\\Program Files (x86)\\Windows Kits\\10\\Lib\\10.0.22621.0\\um\\x64" "-libpath:S:\\Program Files\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\lib\\swift\\windows" "-libpath:S:\\Program Files\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\lib\\swift\\windows\\x86_64" "-libpath:S:\\Program Files\\Swift\\Platforms\\Windows.platform\\Developer\\SDKs\\Windows.sdk\\usr\\lib\\swift\\windows" "-libpath:S:\\Program Files\\Swift\\Platforms\\Windows.platform\\Developer\\SDKs\\Windows.sdk\\usr\\lib\\swift\\windows\\x86_64" "-libpath:S:\\Program Files\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\lib\\clang\\21\\lib\\x86_64-unknown-windows-msvc" -nologo "S:\\Program Files\\Swift\\Platforms\\Windows.platform\\Developer\\SDKs\\Windows.sdk\\usr\\lib\\swift\\windows\\x86_64\\swiftrt.obj" "C:\\Users\\abdulras\\AppData\\Local\\Temp\\TemporaryDirectory.wcsiZF\\test-1.o"
PS S:\tmp> type test.swift
import WinSDK
public func f(_ g: GUID) { }

This might be an explicit modules issue?