NIOCore fails to build with error "No such module 'DequeModule"

[olegbraginontarget]

Expected behavior

I build my project successfully. Project uses latest swift toolchain version.

Actual behavior

Project fails to build with error: SourcePackages/checkouts/swift-nio/Sources/NIOCore/AsyncSequences/NIOAsyncSequenceProducer.swift:16:8: error: no such module 'DequeModule' import DequeModule

Steps to reproduce

1. Open .xcodeproj
2. Start the build

If possible, minimal yet complete reproducer code (or URL to code)

SwiftNIO version/commit hash

[the SwiftNIO tag/commit hash]

System & version information

macOS 12.6, building for iOS 16, swift version 5.7

Info

Can't provide diagnose run, since my project fails to build. I'm posting the issue here, since compiler tells me that there is a build issue with NIOCore module. But my main goal was to use swift-log + swift-log-elk inside my project. Going through the package references, I see that swift-log-elk depends on another package which in turn references SwiftNIO.

[Lukasa]

This appears to be either a misconfiguration on your end or an issue with Xcode. NIOCore depends on DequeModule from swift-collections, a dependency that is expressed here: https://github.com/apple/swift-nio/blob/683f6236924de64fb398343ea930d9d19a9d1512/Package.swift#L23.

How did you express the dependency on swift-log-elk?

[olegbraginontarget]

I don't use Package.swift in the project, just adding all via Xcode UI. This is what I have in .xcodeproj file:

/* XCRemoteSwiftPackageReference "swift-log-elk" */ = {
            isa = XCRemoteSwiftPackageReference;
            repositoryURL = "https://github.com/Apodini/swift-log-elk.git";
            requirement = {
                kind = upToNextMajorVersion;
                minimumVersion = 0.2.2;
            };
        };

[Lukasa]

Can you clear your derived data and do a clean build?

[olegbraginontarget]

I did that a dozen times, didn't help. Here are dependencies of swift-log-elk:

dependencies: [
        .package(url: "https://github.com/apple/swift-log.git", .upToNextMinor(from: "1.4.0")),
        .package(url: "https://github.com/swift-server/async-http-client.git", .upToNextMinor(from: "1.5.0"))
    ]

And here dependencies of async-http-client (those dependencies refer to SwiftNIO):

dependencies: [
        .package(url: "https://github.com/apple/swift-nio.git", from: "2.30.0"),
        .package(url: "https://github.com/apple/swift-nio-ssl.git", from: "2.14.0"),
        .package(url: "https://github.com/apple/swift-nio-http2.git", from: "1.18.0"),
        .package(url: "https://github.com/apple/swift-nio-extras.git", from: "1.10.0"),
        .package(url: "https://github.com/apple/swift-nio-transport-services.git", from: "1.11.0"),
        .package(url: "https://github.com/apple/swift-log.git", from: "1.4.0"),
    ]

[Lukasa]

Can you show me a screenshot of the packages resolved by Xcode in your sidebar?

[olegbraginontarget]

[Lukasa]

Ah, interesting: something seems to have triggered the checkout of swift-collections at main. This is not compatible with what NIO is asking for, which is swift-collections at 1.0.2.

Did you add a dependency on swift-collections yourself?

[olegbraginontarget]

Yes, after version 1.0.2 did trigger the error.

[Lukasa]

Can you revert that change? I expect 1.0.2 to work sufficiently. Can you then expand the contents of swift-collections at 1.0.2?

[olegbraginontarget]

Sure. I tried to revert the the version to 1.0.2 exact. Still same error. Here is the expansion:

I'm starting to think there might be something else involved, not the SwiftNIO lib.

[Lukasa]

Can you provide the full compile log from a clean compile, please?

[olegbraginontarget]

I'm afraid that one I'm not able to provide. But I can cut the piece where the error begins, everything else is green.

Or do you need the compile command?

[Lukasa]

So I think I want to investigate earlier in the build. swift-collections should be building quite early, and I want to confirm that the build is actually working correctly.

[olegbraginontarget]

Yes, it's about 5 or 6 projects earlier and the build is fine:

[olegbraginontarget]

Seems like the problem was in swift-log-elk itself. There was a compilation error in this project which prevented something along the way of building other packages. As soon as I fixed the error in swift-log-elk, I was able to build and the my app. Thanks a lot for prominent reaction @Lukasa !

[Lukasa]

I'm pleased to hear that you solved it!

[Jerry-Carter]

Interestingly, I'm seeing this exact same problem in completely unrelated code via swift-nio 2.45.0 and referencing swift-collections 1.0.3. If either of you have any ideas what sort of compilation errors earlier in the build might cause this error, I'd appreciate your insights. Thanks for your time.

The only warnings I see in the build log are a single "Invalid character in Bundle Identifier" from _NIODataStructures before NIOCore is compiled and later about two dozen integer conversion warnings from CNIOBoringSSL. Neither of these looks like a likely candidate.

[Lukasa]

How are you running the build? Can you provide the output of swift build -v?

[Jerry-Carter]

Xcode (as SPM doesn't support platform independent targets).

[Lukasa]

Can you provide a complete build log?

[Jerry-Carter]

Build CMServer_2022-11-29T11-46-46.txt

[olegbragin]

From experience I see that compilation error comes up when there are several target or packages referencing swift-collections one way or another. In my case it my main target referencing api client (via .xcodeproj), which was dependent on swift-nio and then swift-log-elk package doing the same thing (depending on swift-nio). In both cases swift-nio depends on swift-collection DequeuModule. And here I got the collision. Again from my personal experience the only way I could rules this out was extracting evrerything which depended on swift-nio to separate packages and reference those in a main target.

[Jerry-Carter]

Thanks. That is an unfortunate observation but immensely helpful. For our immediate needs, the build process can be restructured and we can move forward. 🥳

SPECULATION: This feels like either a bug in the swift tool chain or the swift analogue of the #ifdef guards to prevent C headers from being included multiple times. The only new capability I see being used is the @frozen attribute on the Deque structure; perhaps one dependency path to swift-collections is in library evolution mode and another path is not.

For the Swift-NIO project, this issue can remain closed. I don't believe Swift-NIO is doing anything incorrect.

[Lukasa]

Can I suggest filing an issue on apple/swift-package-manager? If we're hitting issues here, it'd be good to know.

[olegbragin]

Sure, just need to know how to properly word that issue there.

[olegbragin]

I created a test project to try to replicate the problem and it's build ok. No issues. So, whatever it was it may be fixed with some new versions of the packages or SPM update, I don't know. This particular issue can remain closed. If I face the same build problem again I'll file a bug.

[cassianomonteiro]

I'm facing the same issue, my structure is like Main App (xcodeproj) -> My internal framework (SPM) -> grpc-swift -> swift-nio -> swift-collections. No other packages depend on swift-nio or swift-collections. My internal framework builds fine both using an xcodeproj or the package, but then I get that error No such module 'DequeModule' when building the main app target that depends on my internal framework.

[Lukasa]

I think this is likely to be an Xcode issue: can I recommend filing an issue with feedbackassistant.apple.com?

[Lukasa]

Hi @danielaisen, your issue doesn't seem to be SwiftNIO related so I don't think I can help you here. Can I suggest you file a report using Feedback Assistant?

[danielaisen]

Hi @Lukasa thx for the fast reply. I thought it was on the same subject. there were issues with the paths of the other library. feel free to delete this message.