Open
Description
The big rustc format made some code I care about much less readable. Here's an example:
- ref mut local @ LocalValue::Live(Operand::Immediate(_)) |
- ref mut local @ LocalValue::Uninitialized => {
- Ok(Ok(local))
- }
+ ref mut local @ LocalValue::Live(Operand::Immediate(_))
+ | ref mut local @ LocalValue::Uninitialized => Ok(Ok(local)),
The actual code running here for this branch got moved onto the same line as the last line of a pattern. That makes it quite hard to visually identify this code -- compared to the old version of the code, the visual separation of pattern and code got lost.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
RalfJung commentedon Jan 3, 2020
More generally, I disagree with the way rustfmt eagerly turns
pat => very_long_expr, pat => short_expr
into
pat => very_long_expr, pat => short_expr
and it also turns
into
In a long
match
, I think it is a good idea to consistently either have pattern and expression on the same line, or on different lines, for all arms in that match. The visual similarities make it much easier to parse this code. But unfortunately, running rustfmt on such manually formatted code turns something symmetric into an inconsistent chaos. One really bad example is this: before -> after. (Yes, thewrite!
arguments were not formatted properly before, and I am totally fine with those being formatted like rustfmt does. This is about the match arms, not thewrite!
arguments.)IMO, rustfmt should honor my choice to start
expr
in a new line, and never remove that newline. That would make it maintain good manual formatting, unlike now where it actively makes code less consistently formatted.Alternatively, if you want to enforce some rule, my proposal would be to only ever have
expr
on the same line aspat
if we can do this for every branch of thematch
(so all branches have just one pattern, and the expression is short enough). That would ensure consistency.[-]Don't put code into the line after `=>` after a multi-line pattern[/-][+]rustfmt puts too much code into the line after `=>`[/+]RalfJung commentedon Jan 3, 2020
(Moved to separate issue: #4004)
original comment
Ah, and I just realized that yet another formatting choice of rustfmt that I strongly dislike is also related: rustfmt will turn
into
I think this is a total no-go. In a long
match
, like for example this, that means that some of the indented lines are statements but some are just function arguments. When skimming thatmatch
, it is very easy to miss the fact that there is a function call after the=>
, and then nothing makes any sense.We also don't generate code like this
so why is it okay to do the equivalent things for match arms?
RalfJung commentedon Jan 3, 2020
(Moved to separate issue: #4005)
original comment
Another way in which rustfmt introduces inconsistency into long
match
is by putting multiple patterns on the same line, so we end up with matches like this:Before rustfmt ran, this was neatly formatted with one pattern per line and never mixing patterns and code on the same line. Now it's all over the place. Should I open a separate bug for this?
RalfJung commentedon Jan 3, 2020
Here's an example diff of what rustfmt does where I disagree with every single change it is making: rust-lang/rust@ff5b102. These all introduce inconsistencies in match formatting.
And here's how I manually formatted a long match, I had to disable rustfmt for that as there seems to be no way to make rustfmt not destroy the formatting: rust-lang/rust@e44f3e7
varkor commentedon Jan 4, 2020
Regarding the third comment, isn't this incorrect behaviour as per the specification?
I was under the impression that
should be reformatted into
as it's not a single-line expression.
RalfJung commentedon Jan 8, 2020
@varkor good catch, I don't see any justification for putting the first line of a multi-line expression onto the line of the
=>
. I moved that to a separate issue: #4004.RalfJung commentedon Jan 8, 2020
Turns out this was already a concern back when the formatting got implemented:
AFAIK, no such option exists yet. And indeed I agree entirely. I'd maybe add one thing: even when none of the branches are wrapped, there's still the choice of putting the expression on the same line as the
=>
, or into a new line. The simplest solution would be to always put it on a new line -- I think that would overall be an improvement today, though some matches would suffer. If we go with having two styles of non-wrapped match arms, then that, too, should be consistent within a match: either all arms should use the line of the=>
, or none of them should.[-]rustfmt puts too much code into the line after `=>`[/-][+]rustfmt formats different arms of the same match inconsistently[/+]RalfJung commentedon Jan 8, 2020
I moved formatting of pattern alternatives to a separate issue: #4005. So this one is now just about making the body of the various match arms of the same match more consistent.
16 remaining items