Fix comments rewritten too long by matthewhughes934 · Pull Request #6802 · rust-lang/rustfmt

matthewhughes934 · 2026-02-13T21:14:10Z

Simplify test case for issue 5023

By replacing the code quoted from the issue with a single comment that
more directly exposes the issue. This is to
1. Make the underlying issue easier to reason about
2. Make this test not behave upon the behaviour of indentation length
  when rewriting lines (my main motivation for this change, since it
  makes the followup patch simpler)
This was tested by partially reverting
368a9b7 with the patch:
```
diff --git i/src/string.rs w/src/string.rs
index 3b971188..561e70ac 100644
--- i/src/string.rs
+++ w/src/string.rs
@@ -278,9 +278,6 @@ fn break_string(max_width: usize, trim_end: bool, line_end: &str, input: &[&str]
         }
         cur_index
     };
-    if max_width_index_in_input == 0 {
-        return SnippetState::EndOfInput(input.concat());
-    }

     // Find the position in input for breaking the string
     if line_end.is_empty()
```
The re-running tests, or executing rustmft directly on this test,
triggered the panic from the original bug.
Make comment wrapping indent aware

When formatting 'missed' spans (I'm still not sure I understand exactly
what 'missed' means).

Previously, if comment_width was less than max_width - $current_indent we would format the comment ignoring the length of any
indentation, so e.g. the following, with comment_width=38 would not be
formatted
```
  fn foo() {
      // The '.' is at 'comment_width' . A

      ()
  }
```
This involved rewriting some existing tests, without impacting what
they're meant to be asserting on. This emphasises that this patch is
not backwards compatible: while I believe the change to be correct
(some tests had comments longer than comment_width that weren't being
formatted). So there's a trade-off to be made between correctness and
stability, since comment_width is still not stabilised this may be
acceptable.

Closes: #6801

jieyouxu

This seems largely reasonable to me. Some nits
@rustbot author

jieyouxu · 2026-06-08T01:38:55Z


        let comment_width = ::std::cmp::min(
-            self.config.comment_width(),
+            self.config.comment_width() - self.block_indent.width(),


Question: can block_indent ever be > comment_width? 🤔

Question: can block_indent ever be > comment_width? 🤔

Yes it can, and previously this would panic. I've pushed changes to the second commit and used Shape::comment directly instead (which does a saturating sub). I also updated the test to cover this case, see the indentation means this comment starts after 'comment_width' comment in the added test.

jieyouxu · 2026-06-08T01:41:08Z

Suggestion: can you include a comment (heh) in this test re. what is being demonstrated specifically? I.e. comment_width versus max_width?

Suggestion: can you include a comment (heh) in this test re. what is being demonstrated specifically? I.e. comment_width versus max_width?

See latest changes the second commit, I've tried to make it clear exactly what we're testing/expecting to see.

rustbot · 2026-06-08T01:41:41Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

matthewhughes934 · 2026-08-16T18:10:18Z

@rustbot ready

ytmimi

Let's revert those test simplification changes. We almost never modify existing test cases. I'm fine with adding additional things to the test case though.

Also had one question for you regarding the change in missed_spans.

View changes since this review

ytmimi · 2026-08-19T21:35:03Z

Let's not modify the content of any existing test cases.

If you want to add your changes in addition to what's there that seems fine to me, but I don't want to remove the fn main() { ... } .

ytmimi · 2026-08-19T21:36:50Z

-	// pulvinar lacus orci eget nibh.  Maecenas sed nibh non lacus tempor faucibus.
-	// In hac habitasse platea dictumst. Vivamus a orci at nulla tristique
-	// condimentum. Donec arcu quam, dictum accumsan, convallis accumsan, cursus sit
-	// amet, ipsum.  In pharetra sagittis nunc.
+	// pulvinar lacus orci eget nibh.  Maecenas sed nibh non lacus tempor
+	// faucibus. In hac habitasse platea dictumst. Vivamus a orci at nulla
+	// tristique condimentum. Donec arcu quam, dictum accumsan, convallis
+	// accumsan, cursus sit amet, ipsum.  In pharetra sagittis nunc.


Is this wrapping too soon?

Is this wrapping too soon?

This file is configured with

// rustfmt-style_edition: 2024 // rustfmt-wrap_comments: true // rustfmt-hard_tabs: true

>>> len("// pulvinar lacus orci eget nibh. Maecenas sed nibh non lacus tempor faucibus.") 79

Pushing faucibis to the following line would make it

>>> len("// faucibus. In hac habitasse platea dictumst. Vivamus a orci at nulla tristique")

And there's

>>> len("// condimentum. Donec arcu quam, dictum accumsan, convallis accumsan, cursus sit") 80

With the default tab_spaces=4 those are al over the comment_width default of 80

ytmimi · 2026-08-19T21:37:31Z

Same as above. Let's keep fn main() { ... }.

Same as above. Let's keep fn main() { ... }.

Done: first commit now is just adding the new example

ytmimi · 2026-08-19T21:45:58Z

-            self.config.max_width() - self.block_indent.width(),
-        );
-        let comment_shape = Shape::legacy(comment_width, comment_indent);
+        let comment_shape = Shape::indented(comment_indent, self.config).comment(self.config);


Could you help me understand what calling .comment() here changes?

Could you help me understand what calling .comment() here changes?

it means we consider the indentation + comment width when determining the width of a line.

Previously, the cmp::min would result in the minimum of:

self.config.max_width() - self.block_indent.width() i.e. content width - indent, or

self.config.comment_width() i.e. just the comment width

So if we took self.config.comment_width() as the width, and you had a line that was 4 indent + 80 comment characters, it would be considered to be 80 characters wide, so e.g. it would fit in the default comment_width even through it was 84 characters wide

Thanks for explaining that. Sometimes the Shape code can be confusing 😅

Sometimes the Shape code can be confusing

Good to know I'm not the only one that finds if confusing 😅

When formatting 'missed' spans (I'm still not sure I understand exactly what 'missed' means). Previously, if `comment_width` was less than `max_width - $current_indent` we would format the comment ignoring the length of any indentation, so e.g. the following, with `comment_width=38` would not be formatted fn foo() { // The '.' is at 'comment_width' . A () } This involved rewriting some existing tests, without impacting what they're meant to be asserting on. This emphasises that this patch _is not_ backwards compatible: while I believe the change to be correct (some tests had comments longer than `comment_width` that weren't being formatted). So there's a trade-off to be made between correctness and stability, since `comment_width` is still not stabilised this may be acceptable. Issue: rust-lang#6801

rustbot · 2026-08-20T20:46:17Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

ytmimi

Thanks for answering my questions + applying feedback. We're good here.

View changes since this review

This changed in rust-lang/rustfmt#6802

The daily format check using the Rust nightly toolchain began returning errors starting with the run at 21:00 UTC on August 30. The newer nightly includes [rustfmt #6802][1], which changed comment wrapping behavior. [1]: rust-lang/rustfmt#6802

`comment_width = 80` counts the whole line, indentation included, which wraps far more aggressively than intended; the latest nightly rustfmt (rust-lang/rustfmt#6802) started enforcing it on comments it previously left alone. Turn `wrap_comments` off rather than reformat everything. `max_width = 100`, `comment_width = 80` and `use_small_heuristics = "Default"` are rustfmt's defaults, so drop them too; only the two nightly-only import options remain.

The daily format check using the Rust nightly toolchain began returning errors starting with the run at 21:00 UTC on August 30. The newer nightly includes [rustfmt #6802][1], which changed comment wrapping behavior. [1]: rust-lang/rustfmt#6802 (cherry picked from commit 7f5fc4c)

Reformat with a current nightly rustfmt (>= 2026-08-20) that includes upstream fix rust-lang/rustfmt#6802 ("Fix comments rewritten too long"). Previously, comment_width wrapping ignored the current indentation level, so deeply indented comments wrapped too close to max_width (100) instead of the intended comment_width (80). This commit only reflows existing comment text produced by rustfmt; no code, string literals, or doc-test examples were touched.

With rust-lang/rustfmt#6802, `rustfmt` updates many comments in the code. Thi patch is the result of `rustfmt **/*.rs`.

rustbot added the S-waiting-on-review Status: awaiting review from the assignee but also interested parties. label Feb 13, 2026

matthewhughes934 force-pushed the fix-comments-rewritten-too-long branch from cecee09 to 9b9090f Compare February 13, 2026 21:15

jieyouxu added X-impacts-unstable-options Expected formatting impact: only affects code formatted by unstable options UO-wrap_comments Unstable option: wrap_comments and removed X-impacts-unstable-options Expected formatting impact: only affects code formatted by unstable options labels Feb 18, 2026

matthewhughes934 force-pushed the fix-comments-rewritten-too-long branch from 9b9090f to fc0c610 Compare February 25, 2026 19:01

This comment has been minimized.

Sign in to view

jieyouxu self-assigned this May 30, 2026

jieyouxu reviewed Jun 8, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: awaiting review from the assignee but also interested parties. labels Jun 8, 2026

matthewhughes934 force-pushed the fix-comments-rewritten-too-long branch from fc0c610 to 6988476 Compare August 16, 2026 18:08

This comment has been minimized.

Sign in to view

rustbot added S-waiting-on-review Status: awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: awaiting some action (such as code changes or more information) from the author. labels Aug 16, 2026

ytmimi requested changes Aug 19, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: awaiting review from the assignee but also interested parties. labels Aug 19, 2026

matthewhughes934 added 2 commits August 20, 2026 21:45

Add clearer test example for issue 5023

a778e81

matthewhughes934 force-pushed the fix-comments-rewritten-too-long branch from 6988476 to e325046 Compare August 20, 2026 20:46

ytmimi approved these changes Aug 20, 2026

View reviewed changes

ytmimi added this pull request to the merge queue Aug 20, 2026

Merged via the queue into rust-lang:main with commit 701c02e Aug 20, 2026
27 checks passed

rustbot added the release-notes Needs an associated changelog entry label Aug 20, 2026

rustbot removed the S-waiting-on-author Status: awaiting some action (such as code changes or more information) from the author. label Aug 20, 2026

papazof mentioned this pull request Aug 31, 2026

ci: Pin the comment-reflow nightly and check it for drift brig-sh/hvi-vmm#63

Merged

3 of 6 tasks

brozorec mentioned this pull request Sep 1, 2026

fix(ci): rewrap comments for indent-aware rustfmt OpenZeppelin/stellar-contracts#862

Merged

flip1995 added a commit to flip1995/rust-clippy that referenced this pull request Sep 1, 2026

Update comment_width in rustfmt.toml

12bb61d

This changed in rust-lang/rustfmt#6802

sandhose mentioned this pull request Sep 2, 2026

Stop wrapping comments in rustfmt, drop redundant options element-hq/matrix-authentication-service#5956

Merged

ustorbeck mentioned this pull request Sep 4, 2026

style: reflow comments to match rustfmt comment_width network-analytics/NetCalyx#51

Merged

alan-source-dev mentioned this pull request Sep 7, 2026

Rustfmt nightly now wraps comments it didn't use to, inflicting formatting churn #7106

Closed

Hywan added a commit to Hywan/matrix-rust-sdk that referenced this pull request Sep 8, 2026

chore: rustfmt the whole project.

0630c1f

With rust-lang/rustfmt#6802, `rustfmt` updates many comments in the code. Thi patch is the result of `rustfmt **/*.rs`.

Hywan mentioned this pull request Sep 8, 2026

chore: rustfmt the whole project matrix-org/matrix-rust-sdk#6995

Closed

2 tasks

maciekglowka mentioned this pull request Sep 8, 2026

Reformat comment wrap asynchronics/nexosim#181

Merged

sirewix mentioned this pull request Sep 18, 2026

fix(rustfmt): Restore previous behavior of comment_width interpretation famedly/engineering-standards#99

Merged

poljar mentioned this pull request Sep 18, 2026

feat(sdk): expose the SendHandle internal transaction id matrix-org/matrix-rust-sdk#7069

Merged

1 of 2 tasks

ytmimi added this to the 1.100.0 milestone Sep 24, 2026

ytmimi removed the release-notes Needs an associated changelog entry label Sep 24, 2026

m4tx mentioned this pull request Sep 25, 2026

style: reformat google/dtoolkit#74

Merged

larstobi mentioned this pull request Sep 25, 2026

Remove syn_derive to address RUSTSEC-2026-0173 rs-tml/rstml#70

Merged

csmulhern mentioned this pull request Nov 3, 2026

comment_width should be independent of indent #7230

Open

Conversation

matthewhughes934 commented Feb 13, 2026 • edited by ytmimi Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

jieyouxu left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jun 8, 2026

Uh oh!

This comment has been minimized.

matthewhughes934 commented Aug 16, 2026

Uh oh!

ytmimi left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Aug 20, 2026

Uh oh!

ytmimi left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

matthewhughes934 commented Feb 13, 2026 •

edited by ytmimi

Loading

jieyouxu left a comment •

edited by rustbot

Loading

ytmimi left a comment •

edited by rustbot

Loading

ytmimi left a comment •

edited by rustbot

Loading