match_arm_blocks = false
interacts poorly on some lines that are exactly max_width + 2
long.
#6136
Labels
a-matches
match arms, patterns, blocks, etc
e-max width
error[internal]: line formatted, but exceeded maximum width
only-with-option
requires a non-default option value to reproduce
I believe this to be a somewhat pathological off-by-one error.
I set up a reproduction repository, which I expect will also be the clearest description of this issue that I can give.
Attempting to summarize; given a
max_width
of60
,match_arm_blocks = false
, and something like line 4 below, runningcargo +nightly fmt
will result in a line that is 61 characters wide. (NB. The specificmax_width
is unimportant; I'm using 60 here only to make the example slightly more concise.)This could be avoided if the arguments in the
println!
invocation were moved into the vertical style. Interestingly, if you add one more_
to line 4 (making that line 63 characters wide), those arguments will be moved into a vertical form, andmax_width
won't be exceeded. Also, if you setmatch_arm_blocks = true
, there will be no trailing comma after theprintln!(..)
(the comma will be moved to a},
on the line below), andmax_width
won't be exceeded.I only noticed this edge case because the repository I'm working in also has
error_on_line_overflow = true
anderror_on_unformatted = true
set, which causes rustfmt to yield an error when run against a line like the one above. Which we somehow managed to already have in our repo when I started experimenting withmatch_arm_blocks = false
.The text was updated successfully, but these errors were encountered: