-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
https://github.com/reviewdog/reviewdog might be of a help here |
Needs to be run with |
I think this is the closest style to ours that we can currently get with |
utils/browser/src/lib.rs
Outdated
@@ -151,12 +152,11 @@ pub fn start_client(mut task_manager: TaskManager, rpc_handlers: RpcHandlers) -> | |||
Box::pin(async move { | |||
let _ = task_manager.future().await; | |||
}), | |||
).map(drop) | |||
) | |||
.map(drop), |
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 curious, can this newline be disabled? I donno substrate's exiting style though.
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.
overflow_delimited_expr can help sometimes in these situations but on balence I think the code works better left to the default value.
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 think the original is indeed better readable here.
Ideally would be a rule to:
- keep
(..).map(drop),
as such - while letting
(..).map(drop).foo(bar)
gets split eventually, whether always or dependending on the line width (I would be fine with both options eitherway)
It maybe does not come up in substrate much, but how do you preserve rustfmt mangling a significant mixture of new lines and one liners when running rust fmt? It helps distinguish mathematical stuff going on in long iterator chains ala https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs#L967-L969 It'd be doable by using named temporaries, except then closures break NLL. |
I don't think it's a problem to use |
let first_benchmark = &mapped_results.get( | ||
&("first_pallet".to_string(), "instance".to_string()) | ||
).unwrap()[0]; | ||
let mapped_results = map_results( |
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.
Is there a way to tune the insertion of \n
between (
and &[
. A few pages down the reverse change is introduced.
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 might be due to inconsistent formatting in the original code, but I'm not sure.
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 don't think that the formatting of the original code matters much to rustfmt. I suspect this is just an artifact of its line-packing heuristics acting up.
overflow_delimited_expr = true
might improve the situation though.
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 didn't see an improvement when I tried this.
I highly recommend
as well to clean up all of our docstring (which is totally arbitrary-length atm). |
I'd like to have these as well, but they occasionally fail to format strings correctly: diff --git a/utils/wasm-builder/src/builder.rs b/utils/wasm-builder/src/builder.rs
index 20f33583b8..1d6f936fe3 100644
--- a/utils/wasm-builder/src/builder.rs
+++ b/utils/wasm-builder/src/builder.rs
@@ -195,8 +195,8 @@ fn provide_dummy_wasm_binary_if_not_exist(file_path: &Path) {
if !file_path.exists() {
crate::write_file_if_changed(
file_path,
- "pub const WASM_BINARY: Option<&[u8]> = None;\
- pub const WASM_BINARY_BLOATY: Option<&[u8]> = None;",
+ "pub const WASM_BINARY: Option<&[u8]> = None;pub const WASM_BINARY_BLOATY: \
+ Option<&[u8]> = None;",
);
}
} Would it be acceptable to save these changes for a future PR? |
Why? The changes above look weird. Not sure we really need |
We might find a way for them to not be weird. But it doesn't matter, we won't include them for now. |
@expenses I think we can find small details to fix for such a PR pretty much forever :) I also added a comment but overall, I find the result very positive. Of course, when it comes to formattings, the merging of this PR will generate extra work (potentially) subsequent changes to the standard are a bit of a pain, especially for open PRs that will need to rebase and fix a bunch of conflicts. In short, if we can be 90% happy (and that's the case AFAIC) with the current PR, I think we should freeze its state and share the agreed config for open PRs to get ready. I would recommend to:
|
Do you guys want it as a blocking check in CI or is it good enough, for now, to have it launched locally? |
Okay great. Yeah @chevdor that's a good idea. I think that with the number of approvals we've got so far, we can go ahead and at least commit the |
Then let's get rid of |
We only want this in CI once we've done the initial formatting of the code. |
rustfmt.toml
and run cargo fmt
on utils
rustfmt.toml
bot merge |
Waiting for commit status. |
Quickly attempt to use the used toml in substrate, filed this upstream issue for |
See #8981. My idea for this PR is to attempt to come up with some
rustfmt.toml
settings that fit the current style of the codebase as much as possible. I've only ran it the stuff inutils
so far as there are less files here than elsewhere.