Matt Corallo [Wed, 22 Sep 2021 06:04:50 +0000 (06:04 +0000)]
Use `GenericTypes`'s type resolver instead of re-resolving
When we resolve a type with `GenericTypes::maybe_resolve_path` it
returns a resolved-path string as well as a syn::Path. When
resolving we'd previously then re-resolve the Path with the current
type/import information, instead of just accepting what was already
resolved. Simply accepting what was already resolved not only
simplifies a few cases, but also allows us to clean up where the
"crate::" prefix is printed, keeping "crate::" prefixes out of all
type resolution.
Matt Corallo [Wed, 22 Sep 2021 02:46:10 +0000 (02:46 +0000)]
Avoid mapping optionals as owned pointers
Using an owned pointer to map an optional turned out to be quite
annoying to avoid downstream memory issues. Instead, we use the
much more explicit `COption_TypeZ` enums everywhere.
Matt Corallo [Wed, 22 Sep 2021 18:39:46 +0000 (18:39 +0000)]
Correct printing generic methods in traits
If a trait method is generic (and not the object itself), we
previously would print the concrete resolved types in the
`impl nativeTrait for TraitStruct` block instead of the generic
names, leading to compilation failures.
Matt Corallo [Mon, 6 Sep 2021 00:53:56 +0000 (00:53 +0000)]
Map Vecs to slices when constructing a getter for a public field
This adds logic to allow constructing a getter for a public Vec
field where the inner items are opaque structs. In order to do this
we map them as slices, which will end up generating Vecs with
elements which all have their `is_owned` flags unset.
Matt Corallo [Wed, 18 Aug 2021 21:51:28 +0000 (21:51 +0000)]
Differentiate `inner` pointers representing `None` and `Some(ZST)`
For zero-sized-types, rust `Box::into_inner(Box::new(ZST {}))`
returns `1usize as *mut ZST`, which confuses our Java bindings
which check for `None` by checking if `inner < 1024`. While we
could convert the Java bindings to check for `inner == 0`, the
magic value for ZST pointers is not, to my knowledge, an ABI
guarantee Rust provides.
Instead, we add an offset to the `inner` pointers to push them
past the zero page for ZSTs, taking this opportunity to clean up
some of our pointer conversion and push them through a common set
of utility functions.
We also add testing infrastructure to add similar offsets to
non-ZSTs to get good test coverage of the offset addition-removal,
though Rust should largely be ignoring pointer values for ZSTs
anyway so there should be little risk in anything going wrong here.
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)
projects / ldk-c-bindings / log