Motivation:

In February, @weissi noticed that the nightly builds of Swift could no longer compile the unit tests. We disabled them at that time and reported an upstream bug, https://bugs.swift.org/browse/SR-14268. This is not an ideal situation, but the Swift core team has provided a workaround we can use to re-enable the tests.

Modifications:

Provide free functions that wrap some specific extension methods that are called in unit tests, and amend the call sites to use them.

Result:

We can re-enable the nightly tests.

Motivation:

In February, @weissi noticed that the nightly builds of Swift could no longer compile the unit tests. We disabled them at that time and reported an upstream bug, https://bugs.swift.org/browse/SR-14268. This is not an ideal situation, but the Swift core team has provided a workaround we can use to re-enable the tests.

Modifications:

Provide free functions that wrap some specific extension methods that are called in unit tests, and amend the call sites to use them.

Result:

We can re-enable the nightly tests.

Yeah, this seems useful.

For what it's worth, no other connection backend has ever thrown NIOConnectionError, so currently these errors are separate per backend.

We like speed. To make NIOSingleStepByteToMessageProcessor even faster, we should mark the process method as @inlinable.

NIOSingleStepByteToMessageProcessor overhead is reduced:

Previous:

Inlined:

The important bit is the relative performance improvement between withNonCowBuffer and the actual decode invocation.

Result:

Faster NIOSingleStepByteToMessageProcessor.

So far I still haven't reproduced this. Can you remove your .build and your DerivedData folder to just be 100% sure that we aren't bringing in some weird state from elsewhere?

This may as well be inlinable too, as should init.

Can you prefix this with an underscore so we know it was supposed to be private?

For example:

/Volumes/FBMac/tmp/DerivedData/kate-ios-grpc-swift-aeudckuyjkzqicdqqcwbtlwoieon/SourcePackages/checkouts/swift-nio-ssl/Sources/NIOSSL/SSLContext.swift:401:20: error: ambiguous use of 'CNIOBoringSSL_SSL_CTX_use_PrivateKey_file'
            return CNIOBoringSSL_SSL_CTX_use_PrivateKey_file(context, pointer, fileType)
                   ^
CNIOBoringSSL.CNIOBoringSSL_SSL_CTX_use_PrivateKey_file:1:13: note: found this candidate
public func CNIOBoringSSL_SSL_CTX_use_PrivateKey_file(_ ctx: OpaquePointer!, _ file: UnsafePointer<CChar>!, _ type: Int32) -> Int32
            ^
CNIOBoringSSLShims.CNIOBoringSSL_SSL_CTX_use_PrivateKey_file:1:13: note: found this candidate
public func CNIOBoringSSL_SSL_CTX_use_PrivateKey_file(_ ctx: OpaquePointer!, _ file: UnsafePointer<CChar>!, _ type: Int32) -> Int32

This shows the function CNIOBoringSSL_SSL_CTX_use_PrivateKey_file being available from CNIOBoringSSL and CNIOBoringSSLShims. That shouldn't be the case, we should be resolving only the one.

However, we also see errors like this:

/Volumes/FBMac/tmp/DerivedData/kate-ios-grpc-swift-aeudckuyjkzqicdqqcwbtlwoieon/SourcePackages/checkouts/swift-nio-ssl/Sources/NIOSSL/SSLContext.swift:413:90: error: ambiguous use of 'count'
            CNIOBoringSSL_SSL_CTX_set_alpn_protos(context, $0.baseAddress!, CUnsignedInt($0.count))
                                                                                         ^
Swift.UnsafeBufferPointer:2:16: note: found this candidate
    public let count: Int
               ^
Swift.Collection:5:27: note: found this candidate
    @inlinable public var count: Int { get }

This shouldn't really be ambiguous. For now I'm assuming this error is an awkward follow-on from the former, but it could be something else altogether.

Ah, this second log is more useful. This seems to show a problem with the modulemaps: we're including the same header file through separate paths. I have to admit I don't know why this is causing some of these issues: the compiler seems to be having real trouble resolving a bunch of the includes.

The reason I'm surprised this has anything to do with armv7 is that the errors are primarily the result of whether the X509 structure is opaque or not. This should not be architecture specific.

It should work with real devices using arm64. The issue seems likely to be to do with the way armv7 is building.

This is a very interesting set of errors: they all come from SwiftNIO SSL, but they don't appear when building that project directly so far as I can see. Additionally, the nature of these errors is that there appears to be a header mismatch: we seem to be getting the wrong header files from CNIOBoringSSL.

Can I confirm that this occurs for you on a clean build (that is, if you rm -rf .build)?

To tie a bow on this, the fix is available in SwiftNIO version 2.32.3.

Fix is in #145.

Motivation:

This SourceKitten submodule is not needed, and there isn't any appropriate map, so it can't actually be initialized. This is breaking adopters of swift-nio-extras.

Modifications:

• Delete the submodule.

Results:

Adopters can build again.

@swift-server-bot add to allowlist

In principle, yes.