Xcode 14.3 RC 2 (14E222b)/Swift Compiler 5.8 SwiftVerifyEmittedModuleInterface failed to verify module interface

[Fushj89]

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

SwiftVerifyInterfaceIssue.zip

[CrazyFanFan]

You can try change the default behavior of the Swift compiler by passing -no-verify-emitter-module-interface to OTHER_SWIFT_FLAGS

[Fushj89]

@CrazyFanFan thank you very much, it works.

[HaleXie]

-no-verify-emitted-module-interface

[super-gsevla]

I'm having the exact same issue but with an other module. Where should I put the -no-verify-emitted-module-interface flag? I have tried to add it at the end of Other Swift Flags placed on Xcode Build Settings but it seems to have no effect.

I'm using Xcode 14.3(14E222b) by the way.

edit Already tried to add the flag above the -fmodule-map-file flag.

Being more specific, this issue is happening with BlueCryptor module.

[thanhtanh]

For my side, adding no-verify-emitter-module-interface (without the first -) to OTHER_SWIFT_FLAGS works

[CrazyFanFan]

I'm having the exact same issue but with an other module. Where should I put the -no-verify-emitted-module-interface flag? I have tried to add it at the end of Other Swift Flags placed on Xcode Build Settings but it seems to have no effect.

I'm using Xcode 14.3(14E222b) by the way.

edit Already tried to add the flag above the -fmodule-map-file flag.

Being more specific, this issue is happening with BlueCryptor module.

Are you using Cocoapods as a package management tool? If so, please try "--clean-install".

[Fushj89]

@super-gsevla put the -no-verify-emitted-module-interface flag on the faild target. e.g the SwiftPodA 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

[super-gsevla]

Hey! Sorry about the delay.

We have solved it here by setting only active arch to "no" into cocoapods build_settings post_install hook.

[AnthonyLatsis]

@xymus Does this look like a compiler bug to you?

[cdhoffmann]

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.

[xymus]

This is a known compiler limitation, it doesn't handle well the ambiguity when a type has the same name as a module. It can break the generated swiftinterfaces. Here you see it reported by the swiftinterface verification, but it would likely also break clients of the module when they use a different Xcode or compiler version.

If you see an error like ObjcPod is not a member type of class ObjcPod.ObjcPod with the repeated names, instead of disabling the verification you may be able to fix the swiftinterface by adding the following flags to the Other Swift Flags build setting of the target building the module with the error: -Xfrontend -module-interface-preserve-types-as-written

[CrazyFanFan]

@xymus Thank you for your reply, in my project -xfrontend -module-interface-preserve-types-as-writte not work when SWIFT_INSTALL_OBJC_HEADER=NO

Attached is a demo project. SwiftInterfaceVerifyFailedDemo.zip

[AnthonyLatsis]

Reduced:

// module 'test'

struct test {}
func foo(_: test.test) {} // error: 'test' is not a member type of struct 'test.test'

[pczhu]

None of the solutions worked for me.

[rashadatjou]

As mentioned above, the error is triggered by a dependency. Experiencing the same issue when archiving a framework using the BUILD_LIBRARY_FOR_DISTRIBUTION=YES option. Unfortunately no solution works currently.

Xcode: 14.3 swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-5.8.0.124.2 clang-1403.0.22.11.100) Target: arm64-apple-macosx13.0

[xymus]

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:

1. Even though it’s a common pattern, when possible and when you own the offending module, avoid using the same name for a type and a module. This is the best way to dodge this problem entirely.
2. Add -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 to Hashable and Equatable, which can be avoided by explicitly declaring these conformances in the sources to prevent the compiler from synthesizing them.
3. Add -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.
4. If all else fails, I’d recommend writing a script to post-process the swiftinterface, removing the instances of 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.

[OO-E]

Hello everyone, I was having the same problem with my static library, I created a new static library with xcode 14.3 and moved my codes there and I was able to solve this problem. It gives an error when opening old projects, this error does not occur when opening a new project. This method worked for me, I hope it works for you.

Xcode version = 14.3 cocoapods version = 1.12.1 MacOS = Ventura 13.2.1

[MinaSamir11]

I set it, nothing happens

[AnthonyLatsis]

set it, nothing happens

You got a typo, the option is spelled no-verify-emitted-module-interface (swiftc -h to verify).

[bimawa]

Looks like xcode 14.3 useless for us now.. and should we downgrade to 14.2?

[xymus]

What's new in recent Xcodes is that we report this issue whereas older Xcodes would not detect it, which lead to delayed failures.

For the time being, my advice is to try the workarounds I suggested above first. In last resort you can disable the verification with -no-verify-emitted-module-interface to get the same behavior as older Xcodes.

[bimawa]

What's new in recent Xcodes is that we report this issue whereas older Xcodes would not detect it, which lead to delayed failures.

For the time being, my advice is to try the workarounds I suggested above first. In last resort you can disable the verification with -no-verify-emitted-module-interface to get the same behavior as older Xcodes.

Should we use unsafe flags for SPM? If yes, we can meet with:

As the usage of the word “unsafe” implies, Swift Package Manager can’t safely determine if the build flags have any negative side effect on the build since certain flags can change the behavior of how it performs a build.

As some build flags can be exploited for unsupported or malicious behavior, the use of unsafe flags makes the products containing this target ineligible for use by other packages.

We are making a framework spm, and our clients should be sure about safe code and ABI support. How can we workaround it?

The whole community started renaming all packages. Maybe we should just a wait?

[bimawa]

Related issue: https://github.com/apple/swift/issues/56573

[bimawa]

UPD: Ok I build it for spm:

1. I created Release.xcconfig
2. added one line: OTHER_SWIFT_FLAGS = -no-verify-emitted-module-interface
3. added this file to config as param for xcodebuild

xcodebuild archive -scheme schemeName \                                                                                                                                                 
	 -disableAutomaticPackageResolution \
	 -destination "generic/platform=iOS" \
	 -archivePath Release-iphoneos \
	 -configuration Release \
	 -derivedDataPath ".build" \
	 -xcconfig Release.xcconfig \
	 -UseModernBuildSystem=YES \
	 SKIP_INSTALL=NO \
	 BUILD_LIBRARY_FOR_DISTRIBUTION=YES \
	 DEPLOYMENT_POSTPROCESSING=YES \
	 STRIP_INSTALLED_PRODUCT=YES \
	 SWIFT_INSTALL_OBJC_HEADER=YES \
	 GENERATE_MASTER_OBJECT_FILE=NO \
	 STRIP_STYLE=non-global

4. profit

@xymus Thanks, for your useful advice!

[AnthonyLatsis]

Duplicate of #56573

[mohdmunaf]

The solution of adding -no-verify-emitted-module-interface worked for running on simulator. Fails to run on a real device.