Dont pass objects to anchor reserves calculator by ref-ref
What changed, and why it matters
This is a minor code cleanup that changes how two objects are passed into an internal helper function. Instead of passing references to references, the function now takes the objects directly. There is no security issue here and no behavior change.
No action needed. This is a benign refactor.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit modifies can_support_additional_anchor_channel in lightning/src/util/anchor_channel_reserves.rs to accept AChannelManagerRef and ChainMonitorRef by value rather than by reference (&AChannelManagerRef, &ChainMonitorRef). Since these types are already reference-like (their names end in Ref and they likely implement Deref), the extra layer of indirection was unnecessary. This is a pure refactor with no functional change.
Changed components
lightning/src/util/anchor_channel_reserves.rsInspect captured patch +2 / −2
diff --git a/lightning/src/util/anchor_channel_reserves.rs b/lightning/src/util/anchor_channel_reserves.rs
index ebae770..e50e103 100644
--- a/lightning/src/util/anchor_channel_reserves.rs
+++ b/lightning/src/util/anchor_channel_reserves.rs
@@ -290,8 +290,8 @@ pub fn can_support_additional_anchor_channel<
>,
>,
>(
- context: &AnchorChannelReserveContext, utxos: &[Utxo], a_channel_manager: &AChannelManagerRef,
- chain_monitor: &ChainMonitorRef,
+ context: &AnchorChannelReserveContext, utxos: &[Utxo], a_channel_manager: AChannelManagerRef,
+ chain_monitor: ChainMonitorRef,
) -> bool
where
AChannelManagerRef::Target: AChannelManager,
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.