Feature: Add Bolt12 Uniffi Type Wrappers #542
Open
+934
−113
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I've assigned @valentinewallace as a reviewer! |
| match LdkBolt11InvoiceDescription::try_from(self) { | ||
| Ok(ldk_description) => ldk_description, | ||
| Err(e) => { | ||
| panic!("Failed to convert Bolt11InvoiceDescription to LDK type: {:?}", e) |
There was a problem hiding this comment.
Not a fan of this myself. We could refactor the Bolt11InvoiceDescription to be a struct that holds the LdkType in an inner field (similar to what we did to other types) to make this conversion safer. Looking for advice on whether it's worth introducing a breaking change for this!
Implement Offer struct in uniffi_types to provide a wrapper around LDK's Offer for cross-language bindings. Modified payment handling in bolt12.rs to: - Support both native and FFI-compatible types via type aliasing - Implement conditional compilation for transparent FFI support - Update payment functions to handle wrapped types Added testing to verify that properties are preserved when wrapping/unwrapping between native and FFI types.
Implement Refund struct in uniffi_types to provide a wrapper around LDK's Refund for cross-language bindings. Modified payment handling in bolt12.rs to: - Support both native and FFI-compatible types via type aliasing - Implement conditional compilation for transparent FFI support - Update payment functions to handle wrapped types Added testing to verify that properties are preserved when wrapping/unwrapping between native and FFI types.
Implement Bolt12Invoice struct in uniffi_types to provide a wrapper around LDK's Bolt12Invoice for cross-language bindings. Modified payment handling in bolt12.rs to: - Support both native and FFI-compatible types via type aliasing - Implement conditional compilation for transparent FFI support - Update payment functions to handle wrapped types Added testing to verify that properties are preserved when wrapping/unwrapping between native and FFI types.
Implement UniffiType trait to standardize conversion between native LDK types and their FFI-compatible wrappers. Enhanced uniffi_conversions module to: - Add a generic trait-based approach to type conversions - Support all wrapped Lightning types (Offer, Refund, Bolt11Invoice, Bolt12Invoice, Bolt11InvoiceDescription) - Provide consistent maybe_convert and maybe_wrap utilities for conditional compilation - Ensure correct type handling with compile-time feature flags Designed for maintainability and consistency when adding new FFI type wrappers in the future.
alexanderwiederin
force-pushed
the
uniffi-bolt12-clean
branch
from
f07aa51 to
e85a185
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Second PR for #504.
This PR adds full Offer-, Refund- and Bolt12Invoice- types for the FFI bindings.
Changes:
ldk_node.udlanduniffi_types.rsuniffi_conversions.rsbolt12.rsandunified_qr.rsBenefits:
Note:
Appreciate that this PR is big. Happy to break down into smaller parts if preferred.