-
Notifications
You must be signed in to change notification settings - Fork 148
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
Strict Concurrency #298
Strict Concurrency #298
Conversation
So there are spots in ViewInspector where a type might conform to Now the reality about Swift's concurrency model is mostly that it brings visibility where there was none before and it forces deliberate choices. Realistically, I'm going to propose this solution: https://developer.apple.com/documentation/swift/mainactor/assumeisolated(_:file:line:)-swift.type.method All this does is take the assumption that was there previously (it was main actor isolated) and codify it. If this gets run from a different thread (it shouldn't, realistically since ViewInspector can control much of that) it'll simply crash. The reality is that's what would happen before, too. Since you could've taken this collection which wasn't thread safe and caused a BAD_ACCESS type crash by monkeying with it on a background thread. FWIW an alternative option would be to change |
On my first attempt to resolve the emerged strict concurrency warnings I faced a problem that as soon as something is marked as So I was thinking - maybe we should not explicitly appeal to |
Hmm, so far I'm not running into any issues with having to mark tests as |
Also, the library doesn't use much of the shared state, we can consider introducing a custom actor to keep that state in sync with minimum efforts. I haven't tried yet, but I suspect attribution with |
name: "ViewInspector", | ||
dependencies: [], | ||
swiftSettings: [ | ||
.enableExperimentalFeature("StrictConcurrency") |
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.
We may not need to declare it at the package level - if you open the project through ViewInspector.xcodeproj
instead of Package.swift
, that should be possible to enable this setting internally in the project
This is not true. It can be safely called from any actor context. @MainActor struct Foo {
func f() -> Bool { true }
}
final class FooTestCase: XCTestCase {
@MainActor
func test1() {
// isolated to MainActor.
let foo = Foo()
XCTAssertTrue(foo.f())
}
func test2() {
MainActor.assumeIsolated {
// crash if it's not isolated to MainActor.
let foo = Foo()
XCTAssertTrue(foo.f())
}
}
func test3() async {
// not necessarily isolated to MainActor, but fine.
let foo = Foo()
let res = await foo.f()
XCTAssertTrue(res)
}
} |
Closing in favor of #302 which is more fleshed out. |
#291 took a first crack at support async/await. While this certainly gets us moving in the short term Swift 6 is threatening to cause all kinds of issues around the corner.
This PR adds the strict concurrency flag and takes a crack at fixing most, if not all issues when that's on.
Most of this is somewhat obvious, view protocols (Like
KnownViewType
) just need to be main actor isolated and then their public declarations need to be marked@preconcurrency
.There's some less obvious changes, like for example when a main actor isolated type conforms to
Collection
. I'll tackle that in a future comment.