-
Notifications
You must be signed in to change notification settings - Fork 54
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
Run cargo fmt #76
base: master
Are you sure you want to change the base?
Run cargo fmt #76
Conversation
Hey there, There's a lot of nice cleanup changes in there, but cargo fmt also messes up the structure / bloats some code significantly. I feel like this needs a manual pass (and/or some use of |
@CensoredUsername I think we need to find a compromise: we need to rather set an agreement upon the rustfmt configs, so that we can have still have a standard to agree on while being less invasive on code changes. |
That makes sense. It's slightly complicated by the fact that I've never used rustfmt on this project, so I do not have a rustfmt config to share here. That said, I really don't have problems with most of the reformatting, but rustfmt's insistence to unroll long enum declarations unnecessary, and its prospensity to remove vertically aligned spacing where it really adds readability is a problem. If just those sections were rustfmt_skip exempted I'd be fine with this changeset. I'll try provide some pointers to what I mean 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.
I hope this helps clarify the few points that I have problems with.
I didn't label every change because for instance, there's a lot of register listings that just need a rustfmt_skip. But it should give a decent idea of what I mean.
@@ -83,11 +83,11 @@ pub enum Matcher { | |||
#[derive(Debug, Clone, Copy, PartialEq, Eq)] | |||
pub enum Command { | |||
// commands that advance the argument pointer | |||
R(u8), // encode a register, or reference base, into a 5-bit bitfield. | |||
R(u8), // encode a register, or reference base, into a 5-bit bitfield. |
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 is what I mean with rustfmt disliking vertical alignment. The comments here were indented to the same line for readability.
X20= 0x14, X21= 0x15, X22= 0x16, X23= 0x17, | ||
X24= 0x18, X25= 0x19, X26= 0x1A, X27= 0x1B, | ||
X28= 0x1C, X29= 0x1D, X30= 0x1E, | ||
X0 = 0x00, |
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.
And here is an example of it unrolling large enums for little reason. This doesn't make the file easier to read. dynasm-rs contains a significant amount of these tables, and the file really doesn't get more readable from multiple chunks of 32 lines of just register numbering.
INTEGERSP = 1, | ||
SIMD = 2, | ||
SIMD = 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.
Another example of rustfmt ignoring vertical alignment.
Matcher::VElement(s) => write!(buf, "V{}.{}[{}]", arg_names[0], size_to_string(*s), arg_names[1]).unwrap(), | ||
Matcher::VElementStatic(s, element) => write!(buf, "V{}.{}[{}]", arg_names[0], size_to_string(*s), element).unwrap(), | ||
Matcher::VStaticElement(s, c) => write!(buf, "V{}.{}{}[{}]", arg_names[0], size_to_string(*s), c, arg_names[1]).unwrap(), | ||
write!( |
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.
These ones I'm a bit on edge about. I think they're being triggered by a column width check? Looks like it rejects over 100 characters. Personally I'm fine with 120 at least, although the last does go over that so maybe just exempting this section is for the best.
("x7" , (X7 , Some(QWORD))), | ||
("x8" , (X8 , Some(QWORD))), | ||
("x9" , (X9 , Some(QWORD))), | ||
("x0", (X0, Some(QWORD))), |
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.
Vertical alignment shenanigans again.
kind, | ||
], | ||
), | ||
Stmt::PrefixStmt(s) | Stmt::Stmt(s) => { |
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 torn on this one, the original had quite long lines but this feels a bit overkill as well.
ref_offset, | ||
.. | ||
}, | ||
) => { |
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 is just bloat.
X28 = 0x1C, | ||
X29 = 0x1D, | ||
X30 = 0x1E, | ||
XZR = 0x1F, |
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.
And we've seen this before.
20, 0, 0x00, 0x00, 16, 0, 0, 0, 0x00, 0x00, 0x00, 0x00, 0xD8, 0xFF, 0xFF, 0xFF, | ||
0xFF, 0xFF, 0xFF, 0xFFu8, | ||
] as &[u8] | ||
); |
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.
The grouping by 8's was completely intended here.
CR12 = 0xC, | ||
CR13 = 0xD, | ||
CR14 = 0xE, | ||
CR15 = 0xF, |
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.
And yeah, these are both in the runtime and plugin crates. Can't import from a plugin and a dependency the other way...
FWIW, I accidentally ran Personally I like If we are not using it, I wonder if there's a way to prevent |
@vext01 I've just not used it in this repo before, as I didn't feel the need for it when it was mostly me using it. If people want to use it I'm fine with it (see this pull), but there's some places where cargo fmt makes the code significantly harder to read, and I'd like those to be addressed instead of people just blanket running cargo fmt, not looking at how it affects the output, and adding exemptions for where it is needed. I wrote down some notes on where it felt necessary to me in the requested changes above if you're interested. |
The change set in #67 looks very long and I don't like that. I realized most of the code are not formatted correctly and as such I blended in
cargo fmt
result there. Let's make sure the change set is clean first