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-written
to 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 toHashable
andEquatable
, which can be avoided by explicitly declaring these conformances in the sources to prevent the compiler from synthesizing them.-alias-module-names-in-module-interface
to 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-interface
to 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=YES
automatically 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 -h
to verify).@super-gsevla put the
-no-verify-emitted-module-interface
flag on the faild target. e.g theSwiftPodA
compile failed because of verify module interface, then put-no-verify-emitted-module-interface
on 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-interface
You can try change the default behavior of the Swift compiler by passing
-no-verify-emitter-module-interface
toOTHER_SWIFT_FLAGS
The solution of adding
-no-verify-emitted-module-interface
worked for running on simulator. Fails to run on a real device.UPD: Ok I build it for spm:
Release.xcconfig
OTHER_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_FLAGS
works