Non-sendable type DispatchTimeInterval exiting main actor-isolated context when using toEventually

[Daniel Vera]

• I have read CONTRIBUTING and have done my best to follow them.

What did you do?

I changed the SWIFT_STRICT_CONCURRENCY flag to targeted and now the tests that are annotated as a main actor and use toEventually now show the following warning:

Non-sendable type DispatchTimeInterval exiting main actor-isolated context in call to non-isolated instance method toEventually(_:timeout:pollInterval:description:) cannot cross actor boundary

The warning can be disabled by using the @preconcurrency annotation in the Dispatch import but I would prefer not adding that annotation.

What did you expect to happen?

Not showing the DispatchTimeInterval warning.

What actually happened instead?

Shows the following warning

Non-sendable type DispatchTimeInterval exiting main actor-isolated context in call to non-isolated instance method toEventually(_:timeout:pollInterval:description:) cannot cross actor boundary

Environment

List the software versions you're using:

• Quick: 6.1.0
• Nimble: 11.2.1
• Xcode Version: 14.2
• Swift Version: Xcode Default

Please also mention which package manager you used and its version. Delete the
other package managers in this list:

• Cocoapods: 1.11.3

Project that demonstrates the issue

import XCTest
import Nimble

@testable import ConcurrencyTest

@MainActor
class Test {

  var completed: (() -> Void)?

  func testing() {
    Task {
      sleep(1)
      completed?()
    }
  }
}

@MainActor
final class ConcurrencyTestTests: XCTestCase {

  func testExample() async throws {
    var completionCalled: Bool = false
    let test = Test()
    test.completed = {
      completionCalled = true
    }
    test.testing()

    await expect(completionCalled).toEventually(beTrue())
  }

}

[Rachel Brindle]

Hi @danielvera64! Sorry for the delay in this!

Enabling concurrency checking is a goal for Nimble 13 (as of this writing, Nimble 13 is 2 major versions away). If you're interested, #1040 is a draft PR with some very early work on this. At this point, I don't know what I'll be doing about Nimble's usage of DispatchTimeInterval (I'm against making it conform to Sendable in Nimble, so unless Apple makes it & related APIs conform to Sendable, then likely the path is to create our own API for specifying a time interval). This is clearly on my radar.

Again, thanks for raising the priority of enabling concurrency checking for Nimble!