What bugs me most about the situation is Apple’s poor communication. And in fact, if you turn strict sendability checking on when compiling against that SDK, you will get a diagnostic about calling withUnsafeContinuation because it thinks that you’re violating the rules (because withUnsafeContinuation doesn’t properly inherit the execution context of its caller). It does, however, break Swift’s data isolation guarantees because it causes withUnsafeContinuation, when called from an actor-isolated context, to send a non- Sendable function to a non-isolated executor and then call it, which is completely against the rules. That bug doesn’t actually break any of the ordering properties above. Now, there is a bug in Xcode 14 when compiling for the macOS SDK because it ships with an old SDK. That will be fixed by the release of the new macOS SDK. And yes, there is a related actor-isolation issue because of this bug. This guarantee is unfortunately broken with Xcode 14 when compiling for macOS because it’s shipping with an old macOS SDK that doesn’t declare that withUnsafeContinuation inherits its caller’s execution context. withUnsafeContinuation can break actor isolation ()Īnd explanations of the cause from John McCall of the Swift team at Apple:.Concurrency is broken in Xcode 14 for macOS ().Here are all related bug reports that I know of: The version mismatch occurs when the final Xcode release in September reverts back to the old macOS SDK to accommodate the different release schedules of iOS and macOS.īreaking concurrency invariants is a serious issue, though I’m not sure how much of a problem this is in actual production apps. Third-party developers had little chance of discovering the bug during the Xcode 14.0 beta phase because the betas ship with the new beta macOS SDK. As soon as Xcode 14.1 gets released with the macOS 13 SDK, the version mismatch will go away, and Mac targets built with Xcode 14.1 won’t exhibit these bugs. The standard library version used by the compiled app at run-time (which depends on the OS version the app runs on) isn’t relevant. Note that the issue is caused purely by the version mismatch at compile-time. But for macOS targets, Xcode 14.0 uses the Swift 5.7 compiler with the standard library from Swift 5.6, which doesn’t contain the attribute. This is fine for iOS because compiler version and the SDK’s standard library version match in Xcode 14.0. The attribute is only present in the Swift 5.7 standard library, i.e. When the Swift 5.7 compiler sees this attribute, it generates different executor hops. They are annotated with a new, unofficial attribute which was introduced for this purpose. Some standard library functions need to opt out of the new rules. Because of SE-0338, when compiling concurrency code, the Swift 5.7 compiler places executor hops in different places than Swift 5.6. Swift 5.7 implements SE-0338: Clarify the Execution of Non-Actor-Isolated Async Functions, which introduces new rules how async functions hop between executors. If you distribute Mac apps, you should build them with Xcode 13.4.1 until Xcode 14.1 is released. Mac apps built with Xcode 14.0 and 14.0.1 may contain concurrency bugs because the Swift 5.7 compiler can generate invalid code when targeting the macOS 12.3 SDK.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |