swift: Xcode 14.3 RC 2 (14E222b)/Swift Compiler 5.8 SwiftVerifyEmittedModuleInterface failed to verify module interface
Description
Use  Xcode 14.3 RC 2  compile a swift file which import a objc clang module, and a framework with swiftinterface, verify module interface happened error.   The clang module path is explicitly passed by  -fmodule-map-file.
Steps to reproduce 1、download SwiftVerifyInterfaceIssue.zip and unzip 2、Use Xcode 14.3 RC 2 open SwiftVerifyInterfaceIssue.xcworkspace, and then build
Expected behavior build success

Environment
- Swift compiler version info swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-5.8.0.124.2 clang-1403.0.22.11.100)
 - Xcode version info Xcode 14.3 Build version 14E222b
 
About this issue
- Original URL
 - State: closed
 - Created a year ago
 - Reactions: 7
 - Comments: 26 (8 by maintainers)
 
Commits related to this issue
- Rename product to StructuredWebSocketClient This works around a problem of having a type and module share the same name. Xcode 14.3 doesn't like it in textual swiftinterface files, and in xcodebuild ... — committed to stairtree/StructuredWebSocketClient by tkrajacic a year ago
 - Rename product to StructuredWebSocketClient This works around a problem of having a type and module share the same name. Xcode 14.3 doesn't like it in textual swiftinterface files, and in xcodebuild ... — committed to stairtree/StructuredWebSocketClient by tkrajacic a year ago
 - Avoid issues when build the framework due to AppsFlyerLib framework having a class named AppsFlyerLib https://github.com/apple/swift/issues/64669#issuecomment-1535335601 — committed to Tealium/tealium-ios-appsflyer-remote-command by Enricoza 4 months ago
 - [MT-1218] Version 3.0.0 (#11) * Remove TealiumRegistration and notification handling in favour of onReady * Make sure that every onReady publishes old registered callbacks in case it detects a man... — committed to Tealium/tealium-ios-appsflyer-remote-command by Enricoza 4 months ago
 
There are a few alternatives I would recommend to workaround the issue of name ambiguities and get a usable swiftinterface. Here they are in order of reliability:
-module-interface-preserve-types-as-writtento Other Swift Flags to print type references in the swiftinterface the way they were written in code. There may still be errors on synthesized code, usually conformances toHashableandEquatable, which can be avoided by explicitly declaring these conformances in the sources to prevent the compiler from synthesizing them.-alias-module-names-in-module-interfaceto Other Swift Flags for the compiler to print modules references in swiftinterfaces in a way to avoid ambiguities. This one is more experimental, there could be rough edges. Please file issues or feedbacks if it causes any problems.MyModule.is often enough. Since the scripts usually run after the verification, you may have to disable the verification by adding-no-verify-emitted-module-interfaceto Other Swift Flags.In the future, the proper fix to this issue is the language support for fully qualified names. This feature was discussed in the forums at https://forums.swift.org/t/pitch-fully-qualified-name-syntax/28482
Also note that
SWIFT_INSTALL_OBJC_HEADER=YESautomatically disables the verification, so even if you don’t see an error the swiftinterface may still be broken.You got a typo, the option is spelled
no-verify-emitted-module-interface(swiftc -hto verify).@super-gsevla put the
-no-verify-emitted-module-interfaceflag on the faild target. e.g theSwiftPodAcompile failed because of verify module interface, then put-no-verify-emitted-module-interfaceon the SwiftPodA target.if you use CocoaPods, you can add
s.xcconfig = { 'OTHER_SWIFT_FLAGS' => '-no-verify-emitted-module-interface' }to the SwiftPodA.podspec-no-verify-emitted-module-interfaceYou can try change the default behavior of the Swift compiler by passing
-no-verify-emitter-module-interfacetoOTHER_SWIFT_FLAGSThe solution of adding
-no-verify-emitted-module-interfaceworked for running on simulator. Fails to run on a real device.UPD: Ok I build it for spm:
Release.xcconfigOTHER_SWIFT_FLAGS = -no-verify-emitted-module-interface@xymus Thanks, for your useful advice!
Looks like xcode 14.3 useless for us now… and should we downgrade to 14.2?
The workarounds are working for us but we would like to know if this is intended behavior as of Xcode 14.3, or if this is a bug. We created the following radar under our team.
For my side, adding
no-verify-emitter-module-interface(without the first-) toOTHER_SWIFT_FLAGSworks