async: Fix returning Result<(), OpaqueType>

[jfaust]

Fixes #220

This supports bridges of the form:

#[swift_bridge::bridge]
mod ffi {
    extern "Rust" {
        type ErrorType;
        async fn some_function() -> Result<(), ErrorType>;
    }
}

async fn some_function() -> Result<(), ErrorType> {
  Ok(())
}

[chinedufn]

Thanks a lot for whipping this up!!

Looks great. Left very minor feedback then this can land.

[chinedufn]

Also, please update your PR body with an example bridge module illustrating what this PR has fixed.

You can find examples of this here https://github.com/chinedufn/swift-bridge/pulls?q=is%3Apr+is%3Aclosed

[jfaust]

@chinedufn think I've resolved all your requests.

One thing I'd like to note as a relatively new contributor - getting the right Rust code for the codegen tests for a change like this was the most difficult part - this small change has outside effects on the code being output that I really didn't have much insight into. If I hadn't discovered that rust-analyzer has an option for macro expansion I'm not sure how I would have done it.

Swift & C are of course easy, because they're written to files directly.

[chinedufn]

One thing I'd like to note as a relatively new contributor

Thanks a lot for leaving feedback.

I can't tell what you mean by getting the right Rust code for the codegen test.

Do you mean knowing what to put inside of the expected Rust tokens, or being able to track down the difference between the expected Rust tokens and the actual generated ones?

[jfaust]

@chinedufn both of those - the output from the test when it fails is stripped of whitespace, which makes it hard to parse what's different, even when doing a side by side diff.

But initially yes, knowing what to put for the Rust tokens. In my first PR a little while ago it was fairly easy, because all the changes to the output were ones I had explicitly made. With this PR, the actual change was tiny and caused large differences in output due to code paths I have no familiarity with. So I had to make the assumption that the code being generated was correct (it compiled and ran), and use the rust-analyzer: Expand macro recursively option in VSCode to find what was necessary to put into the test.

[chinedufn]

Gotcha, thanks for explaining. Any suggestions for what could have made your contribution process easier?

[jfaust]

@chinedufn For the first part, if it's possible to output the input tokens instead of the whitespace-stripped ones that'd be extremely helpful.

For the second, maybe something in the contributing section of the book about how to figure out what the code should look like? e.g. explain where to look for the Swift & C code, and how to get the output from the macro? I don't have a lot of time, but can look at writing something up.

[chinedufn]

Hmm yeah we could probably use something like prettyplease for that, good idea.

That'd be great if you have the time.

Thanks for the ideas!