-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Fix some of the rustfmt fallout in Miri #67833
Closed
Closed
Changes from 3 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Imo the diff doesn't seem like that much of an improvement to justify this... I'm concerned about people starting to use this in various places throughout the compiler to fit their personal tastes rather than having a uniform style.
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 tend to agree with @Centril here that I would like to avoid
#[rustfmt::skip]
. I'd rather find ways to structure the code that make rustfmt happy, or else open issues on rustfmt for extreme cases.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.
(Tweaking rustfmt.toml seems ok too, though I'd prefer to avoid even that when we can.)
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.
Uh... for me this diff is the difference between "unreadable garbage" and "reasonable code". Like, without this PR, the
write!
is formatted in one of three different ways depending on the length of the message and the phase of the moon. Sometimes it's entirely in the same line as the pattern, sometimes it is in a line on its own, and sometimes thewrite!
is on the line of the pattern but its arguments are in separate lines. On top of that, some arms have curly braces and some don't, even though all just contain a singlewrite!
. How is that not just bad style? The style should be consistent across all arms of thismatch
. But what rustfmt does is inconsistent, it's hard to parse visually. The entire point of rustfmt, I thought, is to get consistent formatting, but clearly it is doing the opposite here (and formatch
es in general). The code is very symmetric, but visually in rustfmt style, there's no symmetry at all.I opened a rustfmt issue at rust-lang/rustfmt#3995. But until that gets fixed, I don't see any good reason to let a tool's deficiency (rustfmt overall works fairly poorly on
match
arms) dictate the format.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.
Also Cc @Mark-Simulacrum, whose suggestion it was to use
rustfmt::skip
on this 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.
I appreciate that's useful for folks who went through the hoops of setting that up. Even as someone who didn't, I appreciate the consistent formatting of function signatures, the sorted imports, stuff like that.
But when considering
match
es like this, I honestly don't understand how you can call this a "uniform reading experience" -- there's nothing uniform about how rustfmt formats this match. As far as I am concerned, the formatting of this match after rustfmt is literally worse than anything I ever saw anywhere in the rustc codebase before rustfmt. The way it formats matches will make it much harder for me to work on and review this code-base, due to how it degrades readability. I appreciate that is subjective, but the part where it is very inconsistent and using different styles to do the exact same thing is objectively neither uniform nor consistent.I think the style in this diff is by far egregious enough to justify
rustfmt::skip
. I also don't get the principled opposition to that: we don't usually make ourselves slaves to our own tools, do we? Tidy has had exceptions that were and are applied where reasonable. Not allowing reasonable exceptions would be quite unprecedented. In fact, I count around 30 occurrences ofrustfmt::skip
in the rustc repo already (excluding tools and tests). Many of them are for some sort of table or another (but in some sense, thismatch
is a table), but this one is not. And that makes sense -- rustfmt is a great tool, but like all tools it has its limitations. We should apply the tool where it makes sense, but not mindlessly submit ourselves to whatever the tool happens to do.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'll just note that sometimes (sometimes) I find
let val; ...; val = expr
more readable.(Not when its mutable state; that's almost never more readable. I'm talking about lazily initialized state here.)
Why do I find it more readable? Well, sometimes the `let val = { ... }; ends up with something where the result expression is so far from the binding that it doesn't fit in my editor's view at once, which means I've effectively lost the relationship (or at least have to keep in in my mental cache).
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.
Split your functions Felix, so that "doesn't fit" doesn't happen :P
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.
Sure, when that's an option, it can work well. And I suppose you might also suggest that I ensure that the enums I process never have more than four or five variants.
but sometimes you have to play the hand you are dealt, and I'm glad that I have
let x; ... x = ...;
as a tool in my back pocket, even you all aren't willing to use it yourself.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 really, but you can split
match
arms into separate functions when thematch
gets too long, e.g. as in https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_typeck/check/expr.rs.html#213-289 or https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_typeck/check/pat.rs.html#119-219 which were unreadable messes before I split those functions apart.