Add Sendable to all async return types in tests

[colinmarc]

Without this fix I get errors like the following under Swift 6:

/home/colinmarc/dev/swift-bridge/integration-tests/Sources/SharedLib/Generated/SharedLib.swift:4159:26: error: sending 'rustFnRetVal' risks causing data races
4157 |     return try await withCheckedThrowingContinuation({ (continuation: CheckedContinuation<AsyncResultOkEnum, Error>) in
4158 |         let callback = { rustFnRetVal in
4159 |             continuation.resume(with: rustFnRetVal)
     |                          |- error: sending 'rustFnRetVal' risks causing data races
     |                          `- note: task-isolated 'rustFnRetVal' is passed as a 'sending' parameter; Uses in callee may race with later task-isolated uses
4160 |         }
4161 |

I avoided adding Sendable for RustString since that's being discussed in #296 and elsewhere. Instead, I commented it out and left a TODO.

Fixes #311.

[chinedufn]

Minor feedback around documentation and changing a String to a u32, then we can land this

[chinedufn]

Hmm we'll want to move away from these @unchecked Sendable {}s in favor of enabling swift-bridge to emit Sendable extension.

In the meantime, you can make this @unchecked Sendable safe by replacing the inner String with a primitive such as u32.

swift-bridge/crates/swift-integration-tests/src/async_function.rs

Lines 50 to 54 in 636fa27

	enum AsyncResultOkEnum {
	NoFields,
	UnnamedFields(i32, String),
	NamedFields { value: u8 },
	}

Let's also leave a TODO in this file to ditch @unchecked Sendable in favor of proper Sendable support. Can link to #269

[colinmarc]

For future reference, I think you linked the wrong issue by accident - the relevant one is #150.

[chinedufn]

Currently safe since this struct only contains a primitive

swift-bridge/crates/swift-integration-tests/src/async_function.rs

Lines 8 to 11 in 636fa27

	#[swift_bridge(swift_repr = "struct")]
	struct AsyncRustFnReturnStruct {
	field: u8,
	}

But we'll still eventually want to replace all of these @unchecked Sendable with proper swift-bridge support for emitting Sendable impls as described in #269

[chinedufn]

The TODO describes the problem but not what we should do about it.

Do we need to do research? Do we already know the solution? Is the problem unsolvable? etc.
Let's make it more clear here what the next step is on this TODO.

[colinmarc]

I think I addressed your comments.

[chinedufn]

Looks good just one request.

Can you look over #309 (comment) and confirm that that reasoning is sound?

If so, please add the String code back that you commented out in this PR.

[chinedufn]

RustString should be safe to implement Sendable for today, so long as the Swift code does not make multiple copies of the RustString class.

It will be fully safe once we start using ~Copyable to guarantee that the Swift code cannot copy the RustString (copy as in, copy the class RustString, which is a pointer to the underlying Rust std::string::String.).

So, this code can be added back.

---

Safety claims are here #309 (comment)

[colinmarc]

Uncommenting this line makes it fail to compile on Swift 6, and I think changing core code in this PR would be out of scope, no?

[colinmarc]

Hm, I don't think RustStr should be made sendable until the work in #155 lands. I would merge this as-is and then follow up reenabling the String-based tests after it does.

[chinedufn]

We should make it Sendable and, for now, put the onus on the user to maintain the safety rules outlined in the book.
We shouldn't prevent people from returning String's simply because it's possible to misuse a String.
That's unnecessarily limiting.

If users aren't following the book's safety rules then they're going to hit UB regardless of whether we implement Sendable.

If in the future we're able to guarantee safety at compile time, even better. For now, Swift is fairly limited in this regard.

---

Swift does not yet make it possible for a fully safe FFI boundary. We need to accept that and work with it, rather than wishing that the Swift side had Rust's level of memory safety.

In time we hope that it will get easier and easier to make the Swift side safer and safer.
For now users are responsible for some kinds of memory safety.

[colinmarc]

Regardless of how you want to proceed on the RustStr: Sendable stuff, that needs a fix before I can uncomment the line here. I think I can proceed on #307 without this, however, as long as I don't port the async tests over to the new harness yet.

[debanjanbasu]

Any idea, when this would be merged 🤔?