-
Notifications
You must be signed in to change notification settings - Fork 402
rustfmt
: Run on peer_handler.rs
#3725
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
I've assigned @wpaulino as a reviewer! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good, no code / behavior changes, just formatting. left a minor question
lightning/src/ln/peer_handler.rs
Outdated
let logger = WithContext::from(&self.logger, peer.their_node_id.map(|p| p.0), None, None); | ||
let logger = WithContext::from( | ||
&self.logger, | ||
peer.their_node_id.map(|p| p.0), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extract into a var of to save some lines, there are others like this in the file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
|| peer.awaiting_pong_timer_tick_intervals as u64 | ||
> MAX_BUFFER_DRAIN_TICK_INTERVALS_PER_PEER as u64 | ||
* peers_lock.len() as u64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extract into a var
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be multi-line anyways?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if it doesn't cut down on lines, rustfmt
's breaking up of the pieces here makes it rather unreadable (as the ()s are no longer connected to which indentation things are at).
peers[handler & 1] | ||
.message_handler | ||
.chan_handler | ||
.conn_tracker | ||
.fail_connections | ||
.store(true, Ordering::Release); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are many like this throughout the rest of the file that would not blow up as much if we had some intermediate vars
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced it's that bad tbh?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests that end up spanning three pages of terminal get pretty hard to skim, especially this one which used to be one page :/. Even if individual changes aren't that bad, when there's four changes in a row that all similarly make things super vertical IMO it needs fixing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed most pending feedback.
lightning/src/ln/peer_handler.rs
Outdated
let logger = WithContext::from(&self.logger, peer.their_node_id.map(|p| p.0), None, None); | ||
let logger = WithContext::from( | ||
&self.logger, | ||
peer.their_node_id.map(|p| p.0), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
peers[handler & 1] | ||
.message_handler | ||
.chan_handler | ||
.conn_tracker | ||
.fail_connections | ||
.store(true, Ordering::Release); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced it's that bad tbh?
|| peer.awaiting_pong_timer_tick_intervals as u64 | ||
> MAX_BUFFER_DRAIN_TICK_INTERVALS_PER_PEER as u64 | ||
* peers_lock.len() as u64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be multi-line anyways?
5e7f142
to
6403b34
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3725 +/- ##
==========================================
+ Coverage 89.11% 89.34% +0.23%
==========================================
Files 156 156
Lines 123435 126684 +3249
Branches 123435 126684 +3249
==========================================
+ Hits 109995 113191 +3196
- Misses 10758 10828 +70
+ Partials 2682 2665 -17 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Highlighted a few patterns that could be used to clean up a number of places across the diff.
None | ||
} | ||
fn handle_reply_channel_range( | ||
&self, _their_node_id: PublicKey, _msg: msgs::ReplyChannelRange, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the dummy impls can probably get their parameters all replaced with just _
, which would make them more dense and no less readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no less readable
Hmm, I tend to disagree on this one. Even if they are not used, its adding context what is not being used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean sometimes, sure, but when we're implementing a trait with 20 methods where all of the implementations are just "return nothing", I think we probably don't care too much :p
let next_step = peer.channel_encryptor.get_noise_step(); | ||
match next_step { | ||
NextNoiseStep::ActOne => { | ||
let act_two = try_potential_handleerror!( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot of try_potential_handleerror
calls that would be more readable with an intermediate variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I personally find that these macro calls are not exactly getting more readable if the thing
part of it isn't inlined. Verticality or not, but I personally would prefer to leave them as is. Not sure how strongly feel about them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ISTM that moving the actual thing into an intermediate variable makes much clearer to the reader what the macro is doing. The macro is really just a version of try
with some extra logging (and which may continue
rather than return
ing in some errors). Thus, first building the Result
and then passing it to the macro makes clearer what's going on, vs passing the expression itself to the macro (and it being less clear what the macro does with the expression). While we're at it, we should probably clean up the macro name, something simpler is probably justified given its really just kinda a try
variant, we can call it something simpler like try_peererr
or try_msg_err
or...
6403b34
to
365963c
Compare
MessageSendEvent::SendStfu { ref node_id, ref msg} => { | ||
let logger = WithContext::from(&self.logger, Some(*node_id), Some(msg.channel_id), None); | ||
MessageSendEvent::SendStfu { ref node_id, ref msg } => { | ||
let logger = WithContext::from( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not like it has to happen in this PR but this really makes clearer that we need some kind of logger_from_msg
utility maybe in wire.rs
.
match self.message_handler.route_handler.handle_channel_announcement(None, &msg) { | ||
Ok(_) | Err(LightningError { action: msgs::ErrorAction::IgnoreDuplicateGossip, .. }) => { | ||
match self | ||
.message_handler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Were you gonna clean up down here as well?
|| peer.awaiting_pong_timer_tick_intervals as u64 | ||
> MAX_BUFFER_DRAIN_TICK_INTERVALS_PER_PEER as u64 | ||
* peers_lock.len() as u64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if it doesn't cut down on lines, rustfmt
's breaking up of the pieces here makes it rather unreadable (as the ()s are no longer connected to which indentation things are at).
peers[handler & 1] | ||
.message_handler | ||
.chan_handler | ||
.conn_tracker | ||
.fail_connections | ||
.store(true, Ordering::Release); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests that end up spanning three pages of terminal get pretty hard to skim, especially this one which used to be one page :/. Even if individual changes aren't that bad, when there's four changes in a row that all similarly make things super vertical IMO it needs fixing.
No description provided.