-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to bridge function that receives &str and returns result #265
Comments
Thanks for taking the time to make a detailed and easy to follow issue. Glad you have a workaround. I'll explain the problem and solution in case someone needs the signature to work in the future. Looks like the problem is that we're using public protocol ToRustStr {
func toRustStr<T> (_ withUnsafeRustStr: (RustStr) -> T) -> T;
} swift-bridge/crates/swift-bridge-build/src/generate_core/string.swift Lines 71 to 82 in 7fc3d3c
But the codegen is using a closure of that can throw, meaning it has type // The closure that is being passed into `toRustStr` can throw an exception,
// but `toRustStr` is defined to take a closure that does not throw an exception.
return receives.toRustStr({ receivesAsRustStr in
try {
let val = __swift_bridge__$RustApp$resultTest(ptr, receivesAsRustStr)
if val != nil { throw RustString(ptr: val!) } else { return }
}()
}) Potential SolutionHere's a potential solution in case someone in the future needs this signature to work.
|
I also ran into this. The change from having a |
When given the following bridge definition:
The generated swift code produces a compiler error:
Invalid conversion from throwing function of type '(RustStr) throws -> ()' to non-throwing function type '(RustStr) -> ()'
I have included the following in my project:
If instead my bridge function is defined as follows, then the project compiles fine:
That generates the following Swift:
I'm not sure if this is expected behavior or not. So far I've been able to send Swift
String
values into Rust as&str
fine for any function that does not return a result.For my project, it's fine for it to use owned strings, but I did lose a bit of time before I tried switching the inputs. Even if there is no resulting change to swift-bridge, though, maybe at least having it documented in an issue will save others some heartache!
The text was updated successfully, but these errors were encountered: