Swift 6 language mode compatibility #286
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Unfortunately, `@LazyThreadLocal static var` is considered as concurrency-unsafe in Swift 6 mode even though the underlying PW storage is read-only and concurrency-safe. Also Swift bans `static let` with `@propertyWrapper` syntax, so we need to use `LazyThreadLocal` directly. See the discussion in the Swift forum: https://forums.swift.org/t/static-property-wrappers-and-strict-concurrency-in-5-10/70116/27
…d(unsafe)` Even though `JSObject` is not a `Sendable` type, `JSError` must be `Sendable` because of `Error` conformance. For this reason, we need to annotate the `jsObject` property as `nonisolated(unsafe)` to suppress the compiler error. Accessing this property from a different isolation domain scheduled on a different thread will result in a runtime assertion failure, but better than corrupting memory.
`Error` protocol now requires `Sendable` conformance, which is not possible for `JSError` because `JSObject` is not `Sendable`.
They are accessed from a single thread, so there is no need to enforce
`@Sendable` requirement on them. And also the following code is not
working with `@Sendable` requirement because the captured `JSPromise`
is not `Sendable`.
```
let promise = JSPromise(resolver: { resolver -> Void in
resolver(.success(.undefined))
})
let setTimeout = JSObject.global.setTimeout.function!
let eventLoop = JavaScriptEventLoop(
queueTask: { job in
// TODO(katei): Should prefer `queueMicrotask` if available?
// We should measure if there is performance advantage.
promise.then { _ in
job()
return JSValue.undefined
}
},
setTimeout: { delay, job in
setTimeout(JSOneshotClosure { _ in
job()
return JSValue.undefined
}, delay)
}
)
```
…rom `JSValue` This is a breaking change. It introduces a new `JSException` type to represent exceptions thrown from JavaScript code. This change is necessary to remove `Sendable` conformance from `JSValue`, which is derived from `Error` conformance.
|
Time Change: +65ms (0%) Total Time: 9,726ms
View Unchanged
View Baselines
|
…Promise.result` To reduce burden type casting, it's better to remove the wrapper from the API.
…xecutor` The installation of the global executor should be done before any job scheduling, so it should be able to be called at top-level immediately executed code.
Our new code htis assertion in 2024-10-30-a, but it's fixed in 2025-02-26-a.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Breaking changes
JSValueno longer conformsSendablenorErrorJSErrorno longer conformsSendablenorErrorSendable-related API adjustmentAdded APIs
JSExceptiontype is added to replace usage ofErrorconformance ofJSValueRationale for removal of
Sendableconformance fromJSValueSendabletype values:Sendabletype values:sendingconvention.JSValueThe problem is that there is no way to express "values that are accessible from multiple isolation domains living on the same thread" in the current type system.
There are some ways to send non-Sendable values to other isolation domains, so removing
Sendableconformance can't fully ban sending JSValue to other threads. However, it's still useful to prevent accessing JSValue from other threads for some cases.It might be considerable option to introduce something like
JSRemotethat allows asynchronously accessing objects living in different threads in the future.