Support returning Result<(), OpaqueRust> from Rust functions

[jfaust]

Adds partial support for #177 - supports returning Result<(), OpaqueRust> but not passing as an arg.

The change to examples/rust-binary-calls-swift-package/build.rs was to support xcode not existing in the default location (I use the xcodes tool).

This PR also supports empty types, based on @chinedufn's recommendation.

This enables the following:

#[swift_bridge::bridge]
mod ffi {
    struct UnitType;
    extern "Rust" {
        type OpaqueType;
        fn null_result() -> Result<(), OpaqueType>;
        fn unit_result() -> Result<UnitType, OpaqueType>;
    }
}

fn null_result() -> Result<(), OpaqueType> {
    Ok(())
}

fn unit_result() -> Result<UnitType, OpaqueType> {
    Ok(UnitType {})
}

[chinedufn]

This is AWESOME work, thanks.

Left some minor comments then we can merge this.

---

If you don't mind, how did you figure out where/how to implement this?

I'm asking because the goal is to make it easier for folks to contribute, so I'm curious about how hard or easy it was to make your first contribution?

Cheers and thanks!

[chinedufn]

@jfaust mind updating your PR body to include a bridge module that illustrates what this PR enables?

Here are some other PRs to use as inspiration:

#169
#158
#178

---

The example will get used in our release notes, and also makes old PRs that much more useful (in case we want to link someone to another PR that implemented something similar).

[jfaust]

@chinedufn happy to make these changes, though it may take me a couple days to get to them.

Honestly making the changes was fairly straightforward - I found result.rs, read through it and got a bare-minimum understanding of what it was doing, and then grepped the code for ResultPtrAndPtr, which found most of the places I needed to make changes. From there it was mostly copy/paste with minor changes from the other Result code, which made it pretty easy.

I was testing it all using my codebase, so once it was working I found the rust & swift Result tests, and added test cases to them.

I'm guessing this was probably one of the easier changes to make as a first-time contributor.

swift-analyzer's "Expand macro recursively" command in vscode was also a huge help.

Thanks for building/maintaining this project!

[jfaust]

@chinedufn I think I've resolved all your comments. Let me know if there's anything else to do!

[chinedufn]

Looks great!! Once tests are passing we can merge!

[chinedufn]

nice

[jfaust]

@chinedufn I'm not sure why the Swift tests aren't compiling - they work fine on my machine with Xcode 14.2. Do you know what version of xcode is in use in the Action?

[chinedufn]

I see this in the CI output

/Applications/Xcode_13.2.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-frontend

So I'm assuming we're on 13.2.1 in CI.

I'm seeing this as the error:

Unable to infer complex closure return type; add explicit type to disambiguate

Hmm...

[chinedufn]

I'm on Xcode 13.3.1 and can reproduce the error locally.

public func rust_func_return_result_null_opaque_rust(_ succeed: Bool) throws -> () {
    try { let val = __swift_bridge__$rust_func_return_result_null_opaque_rust(succeed); if val.is_ok { return () } else { throw ResultTestOpaqueRustType(ptr: val.err!) } }()
}

[chinedufn]

Hmm.. so this fails to compile:

func foo() {
    { let foo = 5; return () }()
}

But this compiles successfully:

func foo() {
    { let foo = 5; return }()
}

[chinedufn]

Ok, looks like it's possible to add an explicit signature at the beginning of the closure.

For example, this compiles:

struct MyStruct {}

func foo() {
    { () -> () in let foo = 5; return () }()
}

func bar() {
    { () -> MyStruct in let foo = 5; return MyStruct() }()
}

---

So our options (assuming we want to continue to support Xcode 13) are to either:

1. For the null type use return instead of return (), along with a comment explaining that it's due to an Xcode 13 bug
2. For the null type use an explicit () -> () in at the beginning of the closure, along with a comment explaining that it's due to an Xcode 13 bug
3. OR, add the explicit () -> ReturnType in to the beginning of the closure regardless of the type

---

I would have assumed that having explicit types always leads to better compile times, but I did some quick googling (only looked at one result) and found that using explicit types was slower in the one link that I read (did not verify results myself, did not do thorough research, this post is two years old) https://forums.swift.org/t/regarding-swift-type-inference-compile-time-performance/49748/16

So... for now I like option 1 or 2.

Option 2 boils down to:

let mut maybe_closure_type = "";

// There is a Swift compiler bug in Xcode 13 where using an explicit `()` here somehow leads
// the Swift compiler to a compile time error:
// "Unable to infer complex closure return type; add explicit type to disambiguate"
//
// It's asking us to add a `{ () -> () in .. }` explicit type to the beginning of our closure.
//
// We can remove this if statement whenever we stop supporting Xcode 13;
if self.is_null() {
    maybe_closure_type = " () -> () in "
}

format!("try {{{maybe_closure_type} let val = {expression}; if val.is_ok {{ return {ok} }} else {{ throw {err} }} }}()")

On line 176 in bridgeable_result.rs