We are intending to release without having completed our async
signing logic, which sadly means we need to cfg-gate it to ensure
we restore the previous state of panicking on signer errors, rather
than putting us in a stuck state with no way to recover.
Here we add a new `async_signing` cfg flag and use it to gate all
the new logic from #2558 effectively reverting commits
1da29290e7 through
014a336e59.
Rust is fairly relaxed in checking the validity of arguments
passed to #[cfg]. While it should probably be more strict when
checking features, it cannot be strict when checking loose cfg
tags, because those can be anything and are simply passed to rustc
via unconstrained arguments.
Thus, we do it for rustc manually, but scanning all our source and
checking that all our cfg tags match a known cfg tag.
Fixes#2184
Previously, we used the auto-download feature of the
`electrsd`/`bitcoind` crates. While convenient, they unnecessarily
introduced a lot of dependecies (`zip`, `zstd`, `time`, etc.) to our
test environment which needed pinning for the MSRV of 1.63.
Here, we introduce a new `no_download` config flag to the
`lightning-transaction-sync` crate allowing us to disable this
auto-download feature in CI, where we now opt to download the
corresponding binaries manually. We keep the default-auto-download as a
convenience feature for running tests locally though.
Recently github appears to have reduced the available free disk
space in actions runs, causing CI to fail with out of space errors.
Here we simply run `cargo clean` a few times in CI to reduce our
disk usage somewhat.
Sadly the pinning introduced in 050f5a9029
was brittle in the face of any further syn updates, and has already
broken.
Here we fix it by looking up the actual version of syn to pin.
Note that this dependency is somewhat nonsense as its actually only
a `criterion` dependency, pulled in even though we haven't set the
bench flag (as we aren't yet using `resolver = 2`).
We're working with rust-bitcoin to remove the `core2` dependency
at https://github.com/rust-bitcoin/rust-bitcoin/pull/2066 but until
that lands and we can upgrade rust-bitcoin we're stuck with it. In
the mean time, we should still pass our MSRV tests.
Doing `cargo test` causes us to build both the crate(s) themselves
and the test binaries, which depend on the main builds. However, it
can start building the test code while the actual program code for
the main crate(s) themselves are being built, making a
build -> test flow slightly slower than test -> build.
Its not really a huge deal, but I'm using `ci/ci-tests.sh` more
locally and it meaningfully changes the time-to-test-run.
This should at least marginally more aggressively target things
which are more likely to have changed in CI, making `ci-tests.sh`
more useful as a "default" script for developers to run locally.
Now that all of the core functionality for anchor outputs has landed,
we're ready to remove the config flag that was temporarily hiding it
from our API.
The `log` crate decided to break support for rustc 1.48 (Debian
bullseye) the day the next release of Debian comes out, obviously
before anyone has had a chance to upgrade to the new Debian
bookworm (at https://github.com/rust-lang/log/pull/543). Thus, we
have to manually pin it back to the previous release.
Sadly, the `log` crate is a transitive dependency of `tokio` until
0.20, which requires rustc 1.49. Luckily at least we won't have to
deal with this again, as `log` won't be a dependency of ours
anymore soon.
To match the local signatures found in test vectors, we must make sure
we don't use any additional randomess when generating signatures, as
we'll arrive at a different signature otherwise.
