Commit Graph

13 Commits

Author SHA1 Message Date
Jordan Rose
f19815b938 swift: Add a low-level helper invokeFnReturningValueByPointer
...and use it to avoid having to name return types for bridge
functions, which return by out-parameter.
2025-10-14 11:22:22 -07:00
moiseev-signal
0e9c85c354 keytrans: Unify errors with other typed APIs 2025-09-26 11:47:40 -07:00
Jordan Rose
9e13263581 Switch to swift-format for formatting instead of swiftformat
swift-format is owned by the Swift project and is generally less
opinionated than swiftformat (but better at formatting to a limited
line length).
2025-06-25 11:24:57 -07:00
Alex Bakon
30f7bf7c5d Silence pod lint warning on test-only conformances 2025-06-16 12:57:03 -04:00
Alex Bakon
bf1e08b427 Check for cancellation of Rust task in test 2025-05-20 14:15:23 -04:00
Alex Konradi
33b8e9c3d8 Use strong pointer types for Swift bridge
Wrap the raw pointers exposed across the bridge as named types that approximate 
Swift's OpaquePointer?. Parameterize NativeHandleOwner with the native handle 
type.
2024-12-18 10:00:07 -05:00
Jordan Rose
e2b453fb18 swift: Initial audit for Sendable
- All public Swift-defined structs except CdsiLookupResponse,
  which wraps LookupResponseEntryList, which can *probably* be made
  Sendable but I didn't spend time on it.

- All public Swift-defined enums except those being used purely as
  namespaces.

- All zkgroup types, since they are immutable and can be serialized
  and deserialized to send them anyway

- ServiceId and its subclasses, an immutable class hierarchy

- ProtocolAddress, PinHash, SenderCertificate and ServerCertificate,
  and all public and private Key types, immutable wrappers around
  immutable Rust objects

More of our wrapper types could be made Sendable as well if there's a
need to. See CODING_GUIDELINES for more info.
2024-10-23 13:10:16 -07:00
Jordan Rose
7dc63b99af ffi: Expose cancellation to Swift 2024-05-17 11:30:24 -07:00
Jordan Rose
6d3c192208 ffi: Wrap promise callbacks and contexts in a struct
...and pass that struct by reference.

This has some benefits and some drawbacks:

+ Type inference is (usually) more reliable; invokeAsyncFunction no
  longer needs a "returning:" parameter for disambiguation.

+ We can add more fields to the promise structs as needed.

+ We can use the same argument for input and output.

- Before, every promise that produced an OpaquePointer could share one
  protocol implementation on the Swift side. Now, they're separate.

- The manual type erasure code in the implementation of Completer has
  gotten worse.

- Using the same argument for input and output may be confusing.
2024-05-17 11:30:24 -07:00
moiseev-signal
58f43107ab Enforce Swift code formatting 2024-02-23 09:56:38 -08:00
Alex Konradi
1f2d761889 Allow returning handle types from Swift invokeAsyncFunction
Implement the Completable protocol for OpaquePointer and add a test that runs
futures that return handle types to prove that it works.
2023-12-04 16:39:32 -05:00
Jordan Rose
55a1958a15 Test various error and panic scenarios for bridge_fn and bridge_io 2023-10-12 12:23:22 -07:00
Jordan Rose
17d97859ec bridge: Implement bridge_io for Swift
On the Rust side, this expects a typical C callback function with a
"context" parameter. On the Swift side, we pass a manually-refcounted
object as that "context" which can be used to complete a
CheckedContinuation, bridging into the language 'async' functionality.

The main obstacle to this approach is that Swift does not allow C
function pointers to be used in generic ways, due to its run-time
generics model. AsyncUtils.swift describes the workarounds needed to
deal with this.
2023-10-10 11:52:45 -07:00