-
Notifications
You must be signed in to change notification settings - Fork 376
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
Add rustfmt
support
#2648
Add rustfmt
support
#2648
Conversation
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2648 +/- ##
==========================================
+ Coverage 89.14% 89.97% +0.83%
==========================================
Files 116 112 -4
Lines 93205 116864 +23659
Branches 93205 116864 +23659
==========================================
+ Hits 83089 105151 +22062
- Misses 7583 9622 +2039
+ Partials 2533 2091 -442 ☔ View full report in Codecov by Sentry. |
Huge concept ack |
0548f9f
to
4281566
Compare
Now included a commit reformatting the project for preview purposes. Please anybody let me know if something in particular looks off and if we should change any of the config parameters. I'll try to accommodate wishes as far as possible, at least as long as nobody voices a conflicting opinion. When in doubt, I'll go with the default setting. |
This is a big one for me, though I'm not sure how practical adding
|
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.
Just scanned a few files and comments anything that jumped out as strange.
lightning-block-sync/src/gossip.rs
Outdated
impl< | ||
A: Future<Output=Result<(BlockHash, Option<u32>), BlockSourceError>> + Unpin, | ||
B: Future<Output=Result<BlockHash, BlockSourceError>> + Unpin, | ||
> Joiner<A, B> { | ||
A: Future<Output = Result<(BlockHash, Option<u32>), BlockSourceError>> + Unpin, | ||
B: Future<Output = Result<BlockHash, BlockSourceError>> + Unpin, | ||
> Joiner<A, B> |
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.
Wondering why this gets an extra indentation? Is there a way to configure this?
|
||
#![deny(missing_docs)] | ||
#![deny(unsafe_code)] | ||
|
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 great that it removes these given the comment may not apply to all the lines below.
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.
Yeah, I'm not sure if there is a config option to leave this alone.
Btw. we could consider setting blank_lines_lower_bound
/blank_lines_upper_bound
to 1/2?
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.
Eh, that would be more disruptive, IMO. It would put a bank line before the opening line of a method body and between statements, IIUC.
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.
Oh my, totally missed that this also applies to each line inside bodies, thought this would only reformat lines between blocks. Forget what I wrote.
let mut notifier = ChainNotifier { | ||
header_cache: &mut chain.header_cache(0..=1), | ||
chain_listener, | ||
}; | ||
let mut notifier = | ||
ChainNotifier { header_cache: &mut chain.header_cache(0..=1), chain_listener }; |
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.
Would be preferable if it deferred to the author for how to format a struct initializer, IMHO.
&Init { | ||
features: nodes[j].node.init_features(), | ||
networks: None, | ||
remote_network_address: None, | ||
}, |
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.
Some of these would probably be better formatted if we extract something like this into a local variable. Makes me wonder if we should do a file-by-file transition to catch these.
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.
Yeah, also happy to go this way if it would be preferred. We could go file-by-file, do some doc cleanups in the process (intended to do that for a while) until we have 80% or so of the codebase covered, at which point we could just bite the bullet and run fmt
project-wide (and enforce it fully in CI).
59badbd
to
5271c89
Compare
rustfmt.toml
Outdated
@@ -6,4 +6,3 @@ use_small_heuristics = "Max" | |||
fn_params_layout = "Compressed" | |||
match_block_trailing_comma = true | |||
overflow_delimited_expr = true | |||
format_strings = true |
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 personally like this option... it seems worth it to me even if we don't add custom skips, though that would be nice too.
lightning/src/util/chacha20.rs
Outdated
let lens = [ | ||
a1,a2,a3,a4, | ||
b1,b2,b3,b4, | ||
c1,c2,c3,c4, | ||
d1,d2,d3,d4 | ||
]; | ||
let lens = [a1, a2, a3, a4, b1, b2, b3, b4, c1, c2, c3, c4, d1, d2, d3, d4]; |
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.
Could use a skip here.
lightning/src/util/poly1305.rs
Outdated
r : [u32; 5], | ||
h : [u32; 5], | ||
pad : [u32; 4], | ||
leftover : usize, | ||
buffer : [u8; 16], | ||
finalized : bool, | ||
r: [u32; 5], | ||
h: [u32; 5], | ||
pad: [u32; 4], | ||
leftover: usize, | ||
buffer: [u8; 16], | ||
finalized: bool, |
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.
Candidate for a skip, and several other custom whitespaces used for alignment in this file.
fn get_closing_transaction_weight( | ||
&self, a_scriptpubkey: Option<&Script>, b_scriptpubkey: Option<&Script>, | ||
) -> u64 { | ||
let mut ret = (4 + // version |
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.
Some of the custom alignment is off in this method now.
Reading that comment, it seems like this isn't a priority?
How onerous would it be to use edit: I see Jeff's comment now that it is a lot of places. Any idea how many though? Or, could we live with too many lines in some places? |
The current thinking seems to be that when we do this we'll migrate the codebase file-by-file and clean up particularly bad cases, e.g., by pulling out more into variables before matching on them., so that the formatting of the actual @jkczyz @valentinewallace @TheBlueMatt Does this sound like a reasonable plan to you? |
I'd be happy to see a PR for just one file (maybe a small one that will demonstrate some of the worst cases in our code, like onion_utils or so?) that uses the current rustfmt and moves things into variables to at least get the best we can to see how bad it is. Not sure if we want to commit to something before we at least have a sample? |
Yeah, I'd also prefer a file-by-file approach. |
We add some unstable featues that might be nice to have, but are currently unstable. So we probably don't want to use them right away.
5271c89
to
45c7439
Compare
Important Auto Review SkippedDraft detected. Please check the settings in the CodeRabbit UI or the To trigger a single review, invoke the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
Yeah, generally makes sense to go file-by-file. Given that we'll have to commit to one So, last call for general comments here. Start of next week I'll close this general PR and open the first per-file PR. Might go with |
I now opened the first |
Another attempt to address #410.
TODO:
rustfmt
devs plan to add support (see allow optional programmer discretion on chain length/function arguments per line rust-lang/rustfmt#4306 (comment))#[rustfmt::skip]
blocks as an interim solution until that happens.