'Inject.Inject' shadows module 'Inject' - Inject does not compile when used in framework

[cakl]

Starting with Xcode_14.3 it seems that it is not possible to use Inject in a framework as the following build error appears:

.../SourcePackages/checkouts/Inject/Sources/Inject/Inject.swift:15:13: warning: public enum 'Inject.Inject' shadows module 'Inject', which may cause failures when importing 'Inject' or its clients in some configurations; please rename either the enum 'Inject.Inject' or the module 'Inject', or see https://github.com/apple/swift/issues/56573 for workarounds

When built with Xcode_14.2 there is just a warning about the shadowing.

Sample project: https://github.com/cakl/MyUIFramework (succeeds with Xcode_14.2, fails with Xcode_14.3.1 or higher).

Similar issue: https://github.com/krzysztofzablocki/Difference/issues/36

I know that there are workarounds (https://github.com/apple/swift/issues/64669#issuecomment-1535335601) but they come with a "high price" as far as I understand them.

Thanks for any help

[krzysztofzablocki]

We can rename Inject to InjectConfiguration and remove namespacing so that Hosts are not namespaced so they can still be referred to by Inject.VIewControllerHost etc

[johnno1962]

Idle thought, do you get this warning if you use a typealias?

[cakl]

Idle thought, do you get this warning if you use a typealias?

A typealias on the integrating side like this: https://github.com/cakl/MyUIFramework/blob/feature/typealias/MyUIFramework/ViewController.swift ? This does not seem to help.

[johnno1962]

Are we sure this is still an issue? I have a class SwiftTrace in a package SwiftTrace which used to give a warning but I've not seen it for a while (Xcode 15). There was talk for a while this would eventually not be allowed but perhaps they realised this would be very disruptive.

[cakl]

Are we sure this is still an issue? I have a class SwiftTrace in a package SwiftTrace which used to give a warning but I've not seen it for a while (Xcode 15). There was talk for a while this would eventually not be allowed but perhaps they realised this would be very disruptive.

I only have the issue if Inject is used in a framework. If I'm not doing anything else wrong, yes, it is still an issue. The behaviour can be reproduced with the linked sample project (https://github.com/cakl/MyUIFramework) with Xcode 14.2 and Xcode 14.3.1 (build the xcframework with the provided shell file). The same behaviour is also reproduceable on GH runners (14.2 build vs 14.3.1 build)

[johnno1962]

OK, I'm with you now. Using your script, I can see that when packaging a binary framework an invalid .swiftinterface file is generated if a type shares its name with the package which is what Xcode warns about - even with Xcode 15.2.

[johnno1962]

Can you not add OTHER_SWIFT_FLAGS=-no-verify-emitted-module-interface to your script? It builds but I don't know if that just kicks the problem down the road. The invalid Inject.swiftinterface doesn't seem to be in the built .xcframework.

[johnno1962]

We've not heard back from you. Are you not able to build your framework? I'm using the following and it seems to work:

#!/bin/bash
set -euxo pipefail

# Builds xcframework from iOS framework template project called MyUIFramework

# Clean build folder
rm -rf ./build

# Archive for iOS
xcodebuild archive -scheme MyUIFramework -destination="iOS" -archivePath ./build/ios.xcarchive -sdk iphoneos SKIP_INSTALL=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES OTHER_SWIFT_FLAGS=-no-verify-emitted-module-interface

# Archive for simulator
xcodebuild archive -scheme MyUIFramework -destination="iOS Simulator" -archivePath ./build/iossimulator.xcarchive -sdk iphonesimulator SKIP_INSTALL=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES OTHER_SWIFT_FLAGS=-no-verify-emitted-module-interface

# Build xcframework with two archives
xcodebuild -create-xcframework -framework ./build/ios.xcarchive/Products/Library/Frameworks/MyUIFramework.framework -framework ./build/iossimulator.xcarchive/Products/Library/Frameworks/MyUIFramework.framework -output ./build/MyUIFramework.xcframework

[cakl]

We've not heard back from you. Are you not able to build your framework? I'm using the following and it seems to work:

#!/bin/bash
set -euxo pipefail

# Builds xcframework from iOS framework template project called MyUIFramework

# Clean build folder
rm -rf ./build

# Archive for iOS
xcodebuild archive -scheme MyUIFramework -destination="iOS" -archivePath ./build/ios.xcarchive -sdk iphoneos SKIP_INSTALL=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES OTHER_SWIFT_FLAGS=-no-verify-emitted-module-interface

# Archive for simulator
xcodebuild archive -scheme MyUIFramework -destination="iOS Simulator" -archivePath ./build/iossimulator.xcarchive -sdk iphonesimulator SKIP_INSTALL=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES OTHER_SWIFT_FLAGS=-no-verify-emitted-module-interface

# Build xcframework with two archives
xcodebuild -create-xcframework -framework ./build/ios.xcarchive/Products/Library/Frameworks/MyUIFramework.framework -framework ./build/iossimulator.xcarchive/Products/Library/Frameworks/MyUIFramework.framework -output ./build/MyUIFramework.xcframework

Sorry for the delayed reply. I will try your script in the production code asap. I just thought that this build flag should be the last option and hoped that @krzysztofzablocki’s proposal of renaming should be the way to go (to prevent to „kick the problem down the road“).

[johnno1962]

I'd go for trying changing your script for your specific use case before we start renaming things which might affect other Inject users.

[cakl]

@krzysztofzablocki Sorry for the late reply and thank you for your changes.

What I observed:

• I updated my demo repo to Inject v1.4.0 and the build fails (see: branch, build with the following error:
  • Error: /Users/runner/work/MyUIFramework/MyUIFramework/MyUIFramework/ViewController.swift:20:23: error: module 'Inject' has no member named 'ViewControllerHost' let childVC = Inject.ViewControllerHost(ChildViewController())
• I observed a similar error in a release config build of a current iOS-project using Inject not in an SDK.

I may not fully understand Inject's code and your change, but to me it looks like in the release build the hosts must be accessed via InjectConfiguration (e.g. InjectConfiguration.ViewControllerHost(...)) and in a Debug build still Inject.ViewControllerHost(...) can be used (because of the global typealias). Or what am I missing?

Thanks for your help...

[Frizlab]

I noticed the same as @cakl with latest version (1.5.2).

[krzysztofzablocki]

@cakl you are right, we need to match up the interface to be 1:1 with debug vs release, I missed this when doing those changes, I won't get to it until next week since I've family coming over the weekend but if either of you would want to contribute PR with it I'd be able to review and merge before hand

[Frizlab]

I created a PR. I’m not sure this is the right fix, but it looks ok.