Closed Bright-Shard closed 5 months ago
Looks like tests are failing:
error[E0412]: cannot find type `OptTestOpaqueSwiftType` in module `super`
--> crates/swift-integration-tests/src/option.rs:128:14
|
128 | type OptTestOpaqueSwiftType;
| ^^^^^^^^^^^^^^^^^^^^^^ help: a struct with a similar name exists: `OptTestOpaqueRustType`
...
202 | pub struct OptTestOpaqueRustType {
| -------------------------------- similarly named struct `OptTestOpaqueRustType` defined here
For more information about this error, try `rustc --explain E0412`.
error: could not compile `swift-integration-tests` (lib) due to 1 previous error
That's embarrassing... I'd removed a use ffi::SwiftType
statement and used absolute paths instead... but apparently you have to import the ffi types or it won't compile.
I commented on #270 with the output but on nightly some of the ui
tests fail to run as well. Everything seems to pass now on stable though.
Hmm, not sure what happened.
Paths should work https://github.com/chinedufn/swift-bridge/blob/58f4a40f96bb050607c746376422ab3c62e0e771/crates/swift-integration-tests/src/option.rs#L326-L330
Cool. Looks good. I'll merge once tests pass.
Thanks!
Published as 0.1.54
https://crates.io/crates/swift-bridge/0.1.54
Replaced the pointer::cast
s with more explicit as *mut SomeType
.
Explained here https://github.com/chinedufn/swift-bridge/commit/b4ba1a72a682c3917d78d6650ffb249c7109999b
When I was working on b4ba1a72a682c3917d78d6650ffb249c7109999b I noticed that when returning Swift types from Rust -> Swift
we were running the Drop
impl on the Rust representation of the Swift type.
It looks like this #272 PR was avoiding that Drop by incrementing the Swift type's retain count twice instead of once.
This means that we were leaking memory.
My apologies for not thinking of this during review.
That makes a lot more sense... I'd assumed for some reason it wasn't automatically incrementing the retain count, and thought I was just doing it once.
This adds support for bridging
Option<OpaqueSwiftType>
inextern "Rust"
functions. This fixes #268, and makes the following now possible: