Fix compiling lightning-invoice for no-std + serde #2187
Conversation
Codecov ReportPatch coverage:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #2187 +/- ##
==========================================
- Coverage 91.35% 91.35% -0.01%
==========================================
Files 102 102
Lines 50382 50431 +49
Branches 50382 50431 +49
==========================================
+ Hits 46027 46069 +42
- Misses 4355 4362 +7
... and 11 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
benthecarman
force-pushed
the
invoice-serde-no-std
branch
from
d2f8817
to
36f610c
Compare
| @@ -1648,7 +1648,7 @@ impl<'de> Deserialize<'de> for Invoice { | |||
| fn deserialize<D>(deserializer: D) -> Result<Invoice, D::Error> where D: Deserializer<'de> { | |||
| let bolt11 = String::deserialize(deserializer)? | |||
| .parse::<Invoice>() | |||
| .map_err(|e| D::Error::custom(format!("{:?}", e)))?; | |||
| .map_err(|e| D::Error::custom(alloc::format!("{:?}", e)))?; | |||
There was a problem hiding this comment.
Just changing format! to format_args! would've been better since it may avoid allocation.
There was a problem hiding this comment.
I don't think so? format_args holds a reference to everything passed, which in this case would mean it has a lifetime bound on the lifetime of e.
More generally, in practice would that ever actually avoid allocation? I'm not particularly farmiliar with serde, but we're passing a Display-implementing object to a generic error type, presumably it'll ~always store the string version of it?
There was a problem hiding this comment.
Firstly, if you call format! you have two allocations - one for the string stored inside serde error, the other for the temporary string. So it should be always better to use format_args!.
Secondly while it's true that most if not all serializers in practice do store string, it's possible that someone somewhere decides to write a serializer that directly logs the errors instead of storing them just to minimize allocations here.
There was a problem hiding this comment.
Right, but none of that addresses the fact that the extra lifetime implies this won't compile :)
There was a problem hiding this comment.
What extra lifetime? serde::de::Error::custom takes any T: Display, there's not 'static bound.
There was a problem hiding this comment.
Yes, but the format_args will have a lifetime which is bounded by the e here which we're map_err'ing. That lifetime bound will fail because it's no longer a live reference once we return from the closure. Similar to how you can't use format_args in if let bounds.
There was a problem hiding this comment.
That's not a problem because E::custom doesn't store the argument inside (the signature prevents it). It either stores a String (possibly something exotic like Arc<str>) or logs it.
Anyway, no point in trying to convince you by arguing if I can make a PR :)
There was a problem hiding this comment.
Oh oh, I'd somehow read that as a enum variant, rather than a method, missing that the method turns it into a string, instead of trying to place the Display in an enum variant. I really hate Rust sometimes, so many cases of easily seeing what's going on, and a handful of cases where you can't tell what's up from reading the code.
There was a problem hiding this comment.
I see. I think casing (custom vs Custom) should've made it clear?
There was a problem hiding this comment.
If I'd read it more carefully it would have.
`<E as serde::de::Error>::custom()` accepts any `T: Display`, not just `String`. Therefore it accepts `Arguments<'_>` too so we can use `format_args!()` instead of `format!()`. See lightningdevkit#2187 (comment)
`<E as serde::de::Error>::custom()` accepts any `T: Display`, not just `String`. Therefore it accepts `Arguments<'_>` too so we can use `format_args!()` instead of `format!()`. See lightningdevkit#2187 (comment)
`<E as serde::de::Error>::custom()` accepts any `T: Display`, not just `String`. Therefore it accepts `Arguments<'_>` too so we can use `format_args!()` instead of `format!()`. See lightningdevkit#2187 (comment)
`<E as serde::de::Error>::custom()` accepts any `T: Display`, not just `String`. Therefore it accepts `Arguments<'_>` too so we can use `format_args!()` instead of `format!()`. See lightningdevkit#2187 (comment)
0.0.115 - Apr 24, 2023 - "Rebroadcast the Bugfixes" API Updates =========== * The MSRV of the main LDK crates has been increased to 1.48 (lightningdevkit#2107). * Attempting to claim an un-expired payment on a channel which has closed no longer fails. The expiry time of payments is exposed via `PaymentClaimable::claim_deadline` (lightningdevkit#2148). * `payment_metadata` is now supported in `Invoice` deserialization, sending, and receiving (via a new `RecipientOnionFields` struct) (lightningdevkit#2139, lightningdevkit#2127). * `Event::PaymentFailed` now exposes a failure reason (lightningdevkit#2142). * BOLT12 messages now support stateless generation and validation (lightningdevkit#1989). * The `NetworkGraph` is now pruned of stale data after RGS processing (lightningdevkit#2161). * Max inbound HTLCs in-flight can be changed in the handshake config (lightningdevkit#2138). * `lightning-transaction-sync` feature `esplora-async-https` was added (lightningdevkit#2085). * A `ChannelPending` event is now emitted after the initial handshake (lightningdevkit#2098). * `PaymentForwarded::outbound_amount_forwarded_msat` was added (lightningdevkit#2136). * `ChannelManager::list_channels_by_counterparty` was added (lightningdevkit#2079). * `ChannelDetails::feerate_sat_per_1000_weight` was added (lightningdevkit#2094). * `Invoice::fallback_addresses` was added to fetch `bitcoin` types (lightningdevkit#2023). * The offer/refund description is now exposed in `Invoice{,Request}` (lightningdevkit#2206). Backwards Compatibility ======================= * Payments sent with the legacy `*_with_route` methods on LDK 0.0.115+ will no longer be retryable via the LDK 0.0.114- `retry_payment` method (lightningdevkit#2139). * `Event::PaymentPathFailed::retry` was removed and will always be `None` for payments initiated on 0.0.115 which fail on an earlier version (lightningdevkit#2063). * `Route`s and `PaymentParameters` with blinded path information will not be readable on prior versions of LDK. Such objects are not currently constructed by LDK, but may be when processing BOLT12 data in a coming release (lightningdevkit#2146). * Providing `ChannelMonitorUpdate`s generated by LDK 0.0.115 to a `ChannelMonitor` on 0.0.114 or before may panic (lightningdevkit#2059). Note that this is in general unsupported, and included here only for completeness. Bug Fixes ========= * Fixed a case where `process_events_async` may `poll` a `Future` which has already completed (lightningdevkit#2081). * Fixed deserialization of `u16` arrays. This bug may have previously corrupted the historical buckets in a `ProbabilisticScorer`. Users relying on the historical buckets may wish to wipe their scorer on upgrade to remove corrupt data rather than waiting on it to decay (lightningdevkit#2191). * The `process_events_async` task is now `Send` and can thus be polled on a multi-threaded runtime (lightningdevkit#2199). * Fixed a missing macro export causing `impl_writeable_tlv_based_enum{,_upgradable}` calls to not compile (lightningdevkit#2091). * Fixed compilation of `lightning-invoice` with both `no-std` and serde (lightningdevkit#2187) * Fix an issue where the `background-processor` would not wake when a `ChannelMonitorUpdate` completed asynchronously, causing delays (lightningdevkit#2090). * Fix an issue where `process_events_async` would exit immediately (lightningdevkit#2145). * `Router` calls from the `ChannelManager` now call `find_route_with_id` rather than `find_route`, as was intended and described in the API (lightningdevkit#2092). * Ensure `process_events_async` always exits if any sleep future returns true, not just if all sleep futures repeatedly return true (lightningdevkit#2145). * `channel_update` messages no longer set the disable bit unless the peer has been disconnected for some time. This should resolve cases where channels are disabled for extended periods of time (lightningdevkit#2198). * We no longer remove CLN nodes from the network graph for violating the BOLT spec in some cases after failing to pay through them (lightningdevkit#2220). * Fixed a debug assertion which may panic under heavy load (lightningdevkit#2172). * `CounterpartyForceClosed::peer_msg` is now wrapped in UntrustedString (lightningdevkit#2114) * Fixed a potential deadlock in `funding_transaction_generated` (lightningdevkit#2158). Security ======== * Transaction re-broadcasting is now substantially more aggressive, including a new regular rebroadcast feature called on a timer from the `background-processor` or from `ChainMonitor::rebroadcast_pending_claims`. This should substantially increase transaction confirmation reliability without relying on downstream `TransactionBroadcaster` implementations for rebroadcasting (lightningdevkit#2203, lightningdevkit#2205, lightningdevkit#2208). * Implemented the changes from BOLT PRs lightningdevkit#1031, lightningdevkit#1032, and lightningdevkit#1040 which resolve a privacy vulnerability which allows an intermediate node on the path to discover the final destination for a payment (lightningdevkit#2062). In total, this release features 110 files changed, 11928 insertions, 6368 deletions in 215 commits from 21 authors, in alphabetical order: * Advait * Alan Cohen * Alec Chen * Allan Douglas R. de Oliveira * Arik Sosman * Elias Rohrer * Evan Feenstra * Jeffrey Czyz * John Cantrell * Lucas Soriano del Pino * Marc Tyndel * Matt Corallo * Paul Miller * Steven * Steven Williamson * Steven Zhao * Tony Giorgio * Valentine Wallace * Wilmer Paulino * benthecarman * munjesi
Fixes #2185
Not sure if this the best way to fix but it fixes the issue. Maybe a CI task should be added as well?