`from_c_conversion_container_new_var` should use var_access when
it wishes to access the variable being converted, not `var_name`,
but in a few cases it did not. Note that this has no impact on the
generated bindings as of this commit.
This handles, for example, the `impl<X: Y> for Features<X>` blocks
which are generic across a number of different contexts. We do so
by walking the set of structs which alias Features and then walking
their generic arguments to check that they meet the bounds
specified in the impl block. For each alias which does, we create
a dummy, explicit, `impl XFeatures` block with the same content as
the original and recurse.
We already map type aliases which alias private types as opaque,
but we don't resolve them like we would any other opaque type,
preventing conversion printing or type use.
Instead of walking individual rust files and reading the AST from
those, we instead call
`RUSTC_BOOTSTRAP=1 cargo rustc --profile=check -- -Zunstable-options --pretty=expanded`
and let it create one giant lib.rs which we can parse as a whole.
This allows us to parse a post-macro crate, working with structs
and functions created inside macros just fine. It does require
handling a few things that we didn't previously, most notably Clone
via `impl ::core::clone::Clone` blocks instead of just looking for
`#![derive(Clone)]`.
This ends up resolving a few types slightly differently, resulting
in different bindings, but only in ways which don't impact the
runtime.
In traits with associated types which are returned in generics (ie
`trait T { type A: B; fn c() -> Result<Self::A, ()> {} }`), we
created a new generic mapping with the local type name (in this
case A) instead of using the real type (in this case B). This is
confusing as it results in generic manglings that don't reference
the real type (eg `LDKCResult_ChanKeySignerDecodeErrorZ`) and
may have multiple generic definitions that are identical.
Instead, we now use the final ident in the resolved mapping. The
biggest win is `LDKCResult_ChanKeySignerDecodeErrorZ` changing to
`CResult_ChannelKeysDecodeErrorZ`. However, there are several types
where `secp256k1::Error` was imported as `SecpError` and types like
`LDKCResult_SecretKeySecpErrorZ` are now
`LDKCResult_SecretKeyErrorZ` instead. Still, the type of the error
field remains `LDKSecp256k1Error`, which should avoid any confusion.
Previously we'd segfault trying to deref the NULL page, but there
is no reason to not simply clone by creating another opaque instance
with a null inner. This comes up specifically when cloning
ChannelSigners as the pubkeys instance is NULL on construction
before get_pubkeys is called.
While the type aliasing trick works great for cbindgen,
wasm_bindgen doesn't support it and requires fully-concrete types.
In order to better support wasm_bindgen in the future, we do so
here, adding a function which manually writes out almost the exact
thing which was templated previously in concrete form.
As a nice side-effect, we no longer have to allocate and free a u8
for generic parameters which were `()` (though we still do in some
conversion functions, which we can get rid of when we similarly
concretize all generics fully).
This adds a move-assignment operator (`A& operator=(A&& o)`) to our
C++ wrapper classes as well as requiring an rvalue for the move
auto-convert operator (`operator CStruct()() &&`).
The second makes the C++ wrapper classes much easier to work with
by requiring an explicit `std::move` when the bindings will
automatically move a C++-wrapper object into a C object.
Previously, references and pointers ended up identical in C, so
there was little reason to differentiate. With the addition of
nullability annotations, there is a (very slight) reason to prefer
references, so use them in a few places where its a trivial change.
This adds a new annotation for objects we take by reference in the
C header indicating the pointers must not be null. We have to
disable some warning clang now dumps that we haven't annotated all
pointers, as cbindgen is not yet able to add a nullable annotation.
This (finally) exposes `ChannelManager`/`ChannelMonitor` _write
methods, which were (needlessly) excluded as the structs themselves
have generic parameters. Sadly, we also now need to parse
`(C-not exported)` doc comments on impl blocks as we otherwise try
to expose _write methods for `&Vec<RouteHop>`, which doesn't work
(and isn't particularly interesting for users anyway). We add such
doc comments there.
This is most of the code to expose `ChannelManager`/`ChannelMonitor`
deserialization in our C bindings, using the new infrastructure to
map types in `maybe_convert_trait_impl` and passing generics in
from the callsites.
We also call `maybe_convert_trait_impl` for tuple types, as the
`ChannelManager`/`ChannelMonitor` deserialization returns a
`(BlockHash, T)` to indicate the block hash at which users need to
start resyncing the chain.
The final step to expose them is in the next commit.
This expands the manual implementation logic for `*_write` and
`*_read` methods to most types, converting the `*_write` path to
the common type-conversion logic to ensure it works.
Note that `*_write_void` is still only implemented for has-inner
types, as its unclear what the `void*` would point to for others.
Previously, manual `*_read` implementations were only defined for
types with inner fields, which were set to NULL to indicate read
errors. This prevents exposing `*_read` for several other types,
including tuples (which are needed for `ChannelManager`/
`ChannelMonitors`) and enums (which includes `Event`s, though users
likely never need to call that directly). Further, this means we
don't expose the actual error enum (which is likely no big deal,
but is still nice).
Here, we instead create the `Result<Object, DecodeError>` type and
then pass it through the normal type conversion functions, giving
us access to any types which we can convert normally.
We can fail to resolve a part of a tuple, resulting in a panic in
write_template_constructor even if we're calling
`understood_c_type` with the intent of figuring out whether we can
print a type at all. Instead, we should pipe errors back and let
`understood_c_type` return false as a result.
If you try to call take_ptr on a pointer to an object which
implements Deref, rustc hits the deref recursion limit.
To avoid this, we can explicitly tell rustc that we want to treat
the pointer as a pointer and call take_ptr on it directly.
Previously, types which were declared and used in the same file
would fail if the use was before the declaration. This makes sense
in a few cases where a "parent" class returns a reference to a
"child" class and there's no reason we shouldn't support it.
This change adds a second pass to our file processing which gathers
the structs and enums whicha re declared in the file and adds them
to the type resolver first, before doing the real conversion.
Instead of having manually-written lightning-specific code in a
supertrait walk in the middle of a large function, move it to a
utility function up next to the other manually-written-impl-block
functions.
This is a rather trivial cleanup to ensure we always have the full
path when we walk supertraits even if the supertrait is specified
with only a single ident.
In the case that we return an associated type to C (ie when
implementing a trait which returns an associated type, we had to
convert the Rust-returned concrete Rust type to the C trait struct),
we had code to manually create the neccessary trait struct at the
return site.
This was special-cased in the method-body-writing function instead
of letting the type conversion logic handle it. As a result, we are
unable to do the same conversion when it appears in a different
context, for example inside of a generic like
`Result<Self::AssocType, ErrorType>`.
To solve this, we do the actual work in a
`impl From<nativeType> for CTraitStruct` implementation and then
call `into()` from within the type conversion logic.
Instead of handling associated types separately, we can just shove
them into the same generics resolution logic we use for template
types. While we should probably have some precedence logic,
aliasing type names seems like a bad idea anyway so no effort is
made to handle it.
This removes a good chunk of code and, more importantly, tees us up
for supporting `Type<Self::AssociatedType>`-style generics.
When a trait is required to implement eq/clone (eg in the case of
`SocketDescriptor`), the generated trait struct contains an
eq/clone function which takes a `this_arg` pointer. Since the trait
object can always be read to get the `this_arg` pointer, there is
no loss of generality to pass the trait object itself, and it
provides a bit more flexibility when the trait could be one of
several implementations (which we use in the Java higher-level
bindings).
Previously we'd ignored generic arguments in traits, leading to
bogus code generation after the Persister trait was added in #681.
This adds minimal support for it, fixing code generation on latest
upstream.
Because the C++ wrappers require being able to memset(0) the C
structs to skip free(), we'd previously mapped tuples with two
pointer indirections. However, because all other types already
support memset(0)'ing to disable free() logic, we can skip the
pointer indirections and the behavior is still correct.
