Extract _internal macro for new mon update handling
What the developer wrote
Authored by Valentine Wallace
Extract _internal macro for new mon update handling
Finishes work over the past few commits of breaking up the
handle_new_monitor_update macro.
What changed, and why it matters
This commit is a routine internal code cleanup in the Lightning Dev Kit's Rust implementation. It splits one large Rust macro into two smaller ones, with no change to what the code actually does. There is no security issue visible in the change.
No action required. This is a non-functional refactoring commit.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit refactors the handle_new_monitor_update! macro in lightning/src/ln/channelmanager.rs. It extracts the inner implementation into a new macro named handle_new_monitor_update_internal! and updates the three existing call sites (handle_post_close_monitor_update!, handle_new_monitor_update_actions_deferred!, and the public handle_new_monitor_update!) to invoke the internal macro directly. The _internal_outer token is removed from the macro pattern because it is no longer needed. The logic, variable bindings, and control flow remain identical; only macro structure is reorganized.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +8 / −8
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 263dc94..5ff1fcb 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -3684,7 +3684,7 @@ macro_rules! handle_post_close_monitor_update {
WithContext::from(&$self.logger, Some($counterparty_node_id), Some($channel_id), None);
let in_flight_updates;
let idx;
- handle_new_monitor_update!(
+ handle_new_monitor_update_internal!(
$self,
$funding_txo,
$update,
@@ -3694,7 +3694,6 @@ macro_rules! handle_post_close_monitor_update {
$counterparty_node_id,
in_flight_updates,
idx,
- _internal_outer,
{
let _ = in_flight_updates.remove(idx);
if in_flight_updates.is_empty() {
@@ -3731,7 +3730,7 @@ macro_rules! handle_new_monitor_update_actions_deferred {
let counterparty_node_id = $chan_context.get_counterparty_node_id();
let in_flight_updates;
let idx;
- handle_new_monitor_update!(
+ handle_new_monitor_update_internal!(
$self,
$funding_txo,
$update,
@@ -3741,7 +3740,6 @@ macro_rules! handle_new_monitor_update_actions_deferred {
counterparty_node_id,
in_flight_updates,
idx,
- _internal_outer,
{
let _ = in_flight_updates.remove(idx);
}
@@ -3749,11 +3747,11 @@ macro_rules! handle_new_monitor_update_actions_deferred {
}};
}
-macro_rules! handle_new_monitor_update {
+macro_rules! handle_new_monitor_update_internal {
(
$self: ident, $funding_txo: expr, $update: expr, $peer_state: expr, $logger: expr,
$chan_id: expr, $counterparty_node_id: expr, $in_flight_updates: ident, $update_idx: ident,
- _internal_outer, $completed: expr
+ $completed: expr
) => {{
$in_flight_updates = &mut $peer_state
.in_flight_monitor_updates
@@ -3798,6 +3796,9 @@ macro_rules! handle_new_monitor_update {
false
}
}};
+}
+
+macro_rules! handle_new_monitor_update {
(
$self: ident, $funding_txo: expr, $update: expr, $peer_state_lock: expr, $peer_state: expr,
$per_peer_state_lock: expr, $chan: expr
@@ -3807,7 +3808,7 @@ macro_rules! handle_new_monitor_update {
let counterparty_node_id = $chan.context.get_counterparty_node_id();
let in_flight_updates;
let idx;
- handle_new_monitor_update!(
+ handle_new_monitor_update_internal!(
$self,
$funding_txo,
$update,
@@ -3817,7 +3818,6 @@ macro_rules! handle_new_monitor_update {
counterparty_node_id,
in_flight_updates,
idx,
- _internal_outer,
{
let _ = in_flight_updates.remove(idx);
if in_flight_updates.is_empty() && $chan.blocked_monitor_updates_pending() == 0 {
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.