Matt Corallo [Sat, 7 Aug 2021 19:03:27 +0000 (19:03 +0000)]
Add utility method to construct new complex enums
This is incredibly useful for downstream languages eg Java as it
avoids having to manually implement constructors and can just use
common function-mapping logic.
Matt Corallo [Thu, 5 Aug 2021 01:53:48 +0000 (01:53 +0000)]
Note which parameters or return values are (secretly) Options
Because `Option<OpaqueType>` is mapped the same as `OpaqueType` its
not immediately clear which values in the API are actually
`Option<>`al. Thus, we should at least have documentation noting
this.
Matt Corallo [Wed, 21 Jul 2021 18:51:54 +0000 (18:51 +0000)]
Expose struct method calls on trait structs to C++ directly
We can add method calls for non-trait structs later, but this is
particularly useful as otherwise you need to extract both the
method and the `this_arg` to make the call.
Matt Corallo [Sun, 18 Jul 2021 02:09:45 +0000 (02:09 +0000)]
Provide full (new) struct to trait clone functions
Previously, when we went to clone a trait-implementation struct,
we'd provide only the `this_arg` void pointer, requiring that the
`this_arg` pointer be cloned into a new object while all remaining
fields are copied over exactly.
This has a few important limitations:
* When a struct is cloned, it is not possible to set a `free`
function to free any new data placed in `this_arg` without it
also being set on the original struct.
* Supertrait fields cannot be updated in the subtrait clone
method, including the `this_arg` and `free` methods.
The first limitation prevents us from setting `free` after a clone
when the original trait may or may not have had `free` set. For
example, if the original trait was created with a `Obj_as_Trait`
method, cloned copies would never be free'd.
The second limitation prevents us from keeping the super and
subtrait `this_arg` fields in sync, in addition to limitations
similar to the above.
This resulted in Java code double-free'ing the `this_arg` field in
`InMemorySigner` objects which were accessed as both `Sign` and
`BaseSign` traits.
Matt Corallo [Wed, 28 Jul 2021 00:39:47 +0000 (00:39 +0000)]
If we're leaving binaries around, use -fPIC for ldk_net.o
This is needed if downstream projects want to just take our
ldk_net.o binary and link them in directly, eg with addrsan to
avoid figuring out exact compile flags.
Matt Corallo [Tue, 6 Jul 2021 22:07:42 +0000 (22:07 +0000)]
Drop -flto from non-cross-language-lto C++ demo builds
It appears somehow the LLVM IR is slipping into the Rust library,
causing Ubunto link to fail with the following error:
/usr/bin/ld: error: LLVM gold plugin has failed to create LTO module: Invalid record
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Matt Corallo [Wed, 14 Apr 2021 02:58:12 +0000 (22:58 -0400)]
Impl Send+Sync for every trait, not just those with it explicit
Because Send+Sync are generated by the compiler for us, we don't
really know when we should or should not generate it. That said,
Send+Sync aren't exposed outside of Rust, so it only impacts
whether we can use a type when passed to Rust, not how users will
ultimately interact with types.
Matt Corallo [Sun, 30 May 2021 16:17:25 +0000 (16:17 +0000)]
Add an export tag to indicate users cannot implement a given trait
Specifically, for the LDK `EventsProvider` trait, we can't
(trivially) implement the `process_pending_events` function,
defined as:
`fn process_pending_events<H: Deref>(&self, handler: H) where H::Target: EventHandler;`
We currently do not support implementing generic methods, as we'd
need to wrap them in a generic Rust-trait-to-C-trait conversion
utility, which we do not currently have. Thus, because users
almost certainly have no reason to implement the `EventsProvider`
themselves, its simpler to simply prevent the use of the C trait
struct as the Rust trait.
Concretely, this means just skipping the
`impl rustEventsProvider for CEventsProvider` block, which works
fine as no Rust functions take an `EventsProvider` as an argument.
Matt Corallo [Mon, 3 May 2021 17:52:43 +0000 (17:52 +0000)]
Fix handling of returning Option<&Object> from Rust functions
Specifically, these were previously mapped by calling
`<object.as_ref().unwrap() as *const _>`, taking a pointer to the
option on stack instead of a pointer to the option itself.
We just need to drop the `as_ref()` to make it correct.
Matt Corallo [Fri, 30 Apr 2021 23:41:18 +0000 (23:41 +0000)]
Map enum tuple variants with no contents as unitary enum variants
cbindgen maps `enum A { V() }` with a `struct A_V_Body {}` which
has different size on C and C++ (0 and 1 bytes). While this is
fine if a different variant has non-0 size as the union will be
correctly sized. However, there isn't a lot of reason to rely on
this when we can just have a unitary variant as well.
Matt Corallo [Fri, 30 Apr 2021 23:09:05 +0000 (23:09 +0000)]
Resolve issues with Str introduced when it became ownable
When converting from a Str to an &str, we previously took ownership
of the Str, copied the pointer to its characters to an &str and
returned the &str. This made the returned bytes always unreadable.
Further, there is now no reason to use Vec_u8Z for owned Strs, so
we swap for Str as well.
Matt Corallo [Thu, 29 Apr 2021 22:49:40 +0000 (22:49 +0000)]
Take parameters to trait functions as mut
In keeping with "generally, make all variables mut so that
converters can assume inputs are mut", we should do the same for
trait implementation blocks.