Fix async JNI strict concurrency#730
Conversation
|
Hi thanks for the PR, I’m on holiday so unable to review deeply here this week. im worried about unsafe wrappers like this, and would like to explore other options |
|
@ktoso yes, I agree. I used an unsafe wrapper to avoid changing the approach you were using, because previously there was already an unsafe constant there 🫣 |
|
|
||
| /// Temporary values created by this parameter conversion that must be moved | ||
| /// into async task bodies through an unchecked Sendable wrapper. | ||
| let asyncTaskCaptureNames: [String] |
There was a problem hiding this comment.
NativeParameter represents a single parameter for original swift functions.
It seems unnatural to include the names of multiple values you want to send.
|
@sidepelican I updated this PR, and if I understood you correctly, I tried to move the async capture information out of |
|
@nerzh It seems my explanation wasn't clear enough. It seems multiple I'd like you to first define an async function taking a tuple argument in |
Problem found:
Swift Java generated JNI wrappers for
asyncSwift functions no longer compile with newer Swift strict concurrency checks. The generatedTaskclosures capture JNI values and temporary Swift conversion values that are notSendable, so Swift reports data-race risk errors during compilation.How it was fixed:
I added an unchecked
Sendablewrapper for values that must cross into the generated asyncTaskbody. The generator now tracks, structurally, which temporary values are created during JNI-to-Swift parameter conversion and wraps only those values before creating the task. Inside the task, the original values are restored from the wrapper and used as before.This avoids fragile string parsing of generated Swift code and keeps the fix limited to async JNI generation. Existing async JNI tests were updated to match the new generated output.