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.
`Result` is in the standard prelude, so no need to ever use it.
Sadly, returning a Features<T> in the `impl Futures {}` block
will confuse our new alias-impl-printing logic, as we end up
running through the normal impl-block-printing logic as if we had
an explicit `impl ConcreteFeatures` block.
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.
This adds a utility method, `KeysManager::spend_spendable_outputs`,
which constructs a Transaction from a given set of
`SpendableOutputDescriptor`s, deriving relevant keys as needed.
It also adds methods which can sign individual inputs where
channel-specific key derivation is required to
`InMemoryChannelKeys`, making it easy to sign transaction inputs
when a custom `KeysInterface` is used with `InMemoryChannelKeys`.
Previously, test_dynamic_spendable_outputs_local_htlc_success_tx
called connect_block with two identical transactions, which
resulted in duplicate SpendableOutputs Events back-to-back. This
is a test issue as such a block_connected call represents an
invalid block.
KeyManager::new() took a bitcoin::Network parameter which needs to
be passed to the BIP 32 Extended Key constructor, but because we
never write out the BIP 32 serialization, it isn't used. Instead,
we just pass a dummy value into `ExtendedPrivKey`, dropping the
unused argument to KeysManager::new().
Both SpendableOutputDescriptor::DynamicOutputP2WSH and
SpendableOutputDescriptor::StaticOutputCounterpartyPayment are
relevant only in the context of a given channel, making them
candidates for being passed into helper functions in
`InMemoryChannelKeys`. This moves them into their own structs so
that they can later be used standalone.
We previously counted 35 bytes for a length + public key, but in
reality they are never larger than 34 bytes - 33 for the key and 1
for the push length.
Sadly rust upstream never really figured out the benchmark story,
and it looks like the API we use here may not be long for this
world. Luckily, we can switch to criterion with largely the same
API if that happens before upstream finishes ongoing work with the
custom test framework stuff.
Sadly, it requires fetching the current network graph, which I did
using Val's route-testing script written to test the MPP router.
This adds a channel_value_satoshis field to
SpendableOutputDescriptors as it is required to recreate our
InMemoryChannelKeys. It also slightly expands documentation.
Instead of `key_derivation_params` being a rather strange type, we
call it `channel_keys_id` and give it a generic 32 byte array. This
should be much clearer for users and also more flexible.
