-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swift 6 compatibility #108
Conversation
Thank you for looking into this @Supereg! |
@PSchmiedmayer the Xcode 15 toolchain still triggers some concurrency warnings that are not triggered with the Xcode 16 beta 3 toolchain (e.g., Logger has now Sendable conformance with the latest SDKs). Should we aim to host some Xcode 16 runners soon? This could also be useful to enable Swift 6 language mode in which Concurrency warnings are treated as errors which would make efforts in StanfordSpezi/.github#50 to be non-essential. We could either move with all runners to the beta toolchain for the Spezi Org. Seems relatively stable by now and is probably the easiest to maintain. Otherwise, we could allocate some dedicated Swift 6 runners if we have the capacity. Let me know what you think. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #108 +/- ##
==========================================
- Coverage 87.64% 85.85% -1.78%
==========================================
Files 46 45 -1
Lines 1375 1392 +17
==========================================
- Hits 1205 1195 -10
- Misses 170 197 +27
Continue to review full report in Codecov by Sentry.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for all the improvements to get the package Swift 6-ready.
I have also installed Xcode 16.0 Beta 3 on our runners so we check that with the latest encode version and validate that the package builds with Xcode 16 and Swift 6.
One thing I noticed. Out of curiosity I tried to update the Swift tools version in the Package.swift to 6.0 but got multiple compiler errors without any direct references to source code errors. I am not sure if you can verify this on your machine or if this is a general issue that might be related to the Xcode beta?
Would be great if we bump the tools version to 6.0 after Swift 6 is released.
# Allow to specify Swift version with xcodebuild ## ♻️ Current situation & Problem This PR adds a new input to specify the swift version when running with xcodebuild. ## ⚙️ Release Notes * Add new `swiftVersion` input to the xcodebuild-or-fastlane action. * Specify more clearly that the `test` input only has an effect when using xcodebuild. ## 📚 Documentation -- ## ✅ Testing Verified in StanfordSpezi/Spezi#108 (both with not specifying swift version and with specifying a swift version). ## 📝 Code of Conduct & Contributing Guidelines By submitting creating this pull request, you agree to follow our [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md): - [x] I agree to follow the [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md).
Swift 6 compatibility
♻️ Current situation & Problem
This PR fixes the swift concurrency flag. There weren't any concurrency warnings left when compiling with the latest Swift 6 toolchain that is part of Xcode 16 beta 3. Note, that Xcode 15 will trigger some warnings as some symbols aren't annotated as Sendable in the previous SDK. Further, some sendability checks changed.
This PR changes some actor isolations of some types and interfaces. Most importantly, we add
@MainActor
isolation to theModule/configure()
method. We found, that a lot of modules manipulate@MainActor
isolated properties in their configure method (those that are relevant for UI components) but cannot do so without spawning a new Task, as the configure method previously didn't have@MainActor
guarantees. Except for out-of-band module loading,configure()
would have always been called on the Main Actor (through SwiftUI initialization). Making all module interactions to be isolated to@MainActor
greatly simplifies some of our internal state handling.⚙️ Release Notes
Breaking Changes
Module/configure()
is now isolated to@MainActor
.Spezi/loadModule(_:ownership:)
andSpezi/unloadModule(_:)
are now isolated to@MainActor
.📚 Documentation
Minor documentation files.
✅ Testing
Test target was updated to latest concurrency changes as well.
📝 Code of Conduct & Contributing Guidelines
By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines: