swift-bridge
swift-bridge copied to clipboard
Make data-carrying enums emit `#[derive(Debug)]` on the Rust side
- fix: Add Debug to derived traits on Rust side even if one of the variants has data to hopefully avoid confusing the developer
- fix: don't generate Debug functions in C header and Swift if any variants have data to avoid confusing the developer with undefined symbol build errors
Previously, this would cause a "undefined symbol" build error and cause the error not to implement Debug
trait from Rust:
#[swift_bridge::bridge]
mod ffi {
#[derive(Debug)]
enum DeriveDebugEnum {
Variant(String),
}
}
When generating C headers and Swift, there was no check to ensure that the enum has no variants with data, but this check was added when generated Rust tokens. This causes undefined symbol if a variant has data since C and Swift thinks the method exists, but it actually doesn't.
This PR fixes the undefined symbol error and also makes the enum implement Debug
, even if only from Rust.
Hey, thanks for working on this.
Mind updating your PR to more clearly explain the problem and how this PR solves the problem, as well as to include an example bridge module that illustrates what this PR enables?
Thanks!
Added!
@chinedufn Sorry to bother you, but any chance of this being merged?
Can we add some tests?
What tests need to be added?
Is there any progress on this? This change is quite a bit critical to one of our projects.
@junepark678 You could add my branch as a dependency to use it early. I'll sync up the branch
Is there anyone interested in picking up this PR? I am not actively working on anything that depends on swift-bridge and finishing this up seems like a lot for something that was intended to be a quick fix for a bug.
As for the error message, it's just ld
or the Swift compiler saying it can't find a symbol that some swift code needed.
@chinedufn
https://github.com/chinedufn/swift-bridge/pull/209#issuecomment-2290199332
May I take over this PR if no one addresses this by next week?
Absolutely, feel free. Thanks.