You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Extra blank line inserted before code blocks in doc comments #6695
Doc comment formatting inconsistency when using wrap_comments = true with max_width = 20: an extra blank line is inserted before code blocks.
# rustfmt.tomlwrap_comments = truemax_width = 20
/// Some doc comment with code snippet:///```/// '\u{1F}/// ```pubstructCode{}
Additional Context
This issue was discovered while attempting to fix other issues in rust-lang/rustfmt.
The latest rustfmt (rustfmt 1.8.0-nightly (6ac1fcd7a3 2025-10-09)) produces the correct output without the extra blank line. This issue is being filed to track this regression and verify whether it gets fixed after the next sync from rust-lang/rustfmt to rust-lang/rust.
@siddhardh-codemonk Maybe you can take a look at this one. To test is out I'd create an input file (issue_6695.rs):
/// Some doc comment with code snippet:///```/// '\u{1F}/// ```pubstructCode{}
You can run cargo run --bin rustfmt -- --emit=stdout --config=max_width=20,wrap_comments=true path/to/issue_6695.rs from the root of the rustfmt repo to build run and from source. I'm setting --emit=stdout so that we don't override the original input file and --config=max_width=20,wrap_comments=true just passes all the configuration options needed to reproduce.
With all that, rustfmt produces this:
Output:
/// Some doc comment/// with code snippet:/// /// ```/// '\u{1F}/// ```pubstructCode{}
error[internal]: line formatted, but exceeded maximum width (maximum: 20 (see `max_width` option), found: 22)
--> path/to/issue_6695.rs:2:2:21
|
2 | /// with code snippet:
| ^^
|
= note: set `error_on_unformatted = false` to suppress the warning against comments or string literals
error[internal]: left behind trailing whitespace
--> path/to/issue_6695.rs:3:3:4
|
3 | ///
| ^
|
= note: set `error_on_unformatted = false` to suppress the warning against comments or string literals
warning: rustfmt has failed to format. See previous 2 errors.
If you're having issues / have questions you can leave comments here or message me on Zulip
Thanks again for the repro! I dug into this and found there are actually two separate bugs causing the two errors:
Trailing whitespace — traced to how handle_line pushes a space for continuation, then separately pushes a newline when a code block starts, without cleaning up the earlier space. Opened a PR fixing this: #7083
Width overflow — this one's in break_string's MIN_STRING threshold rejecting a valid break point and falling through to a forward search that doesn't re-check the width limit. It's more involved since it's shared wrapping logic used elsewhere, so I wanted to flag it here first rather than guess at a fix. Happy to take a swing at it if you can confirm the right direction (e.g. should the forward-search fallback verify width before accepting, or should MIN_STRING behave differently in this case?).
Activity
ytmimi commentedon Aug 28, 2026
@siddhardh-codemonk Maybe you can take a look at this one. To test is out I'd create an input file (
issue_6695.rs):You can run
cargo run --bin rustfmt -- --emit=stdout --config=max_width=20,wrap_comments=true path/to/issue_6695.rsfrom the root of the rustfmt repo to build run and from source. I'm setting--emit=stdoutso that we don't override the original input file and--config=max_width=20,wrap_comments=truejust passes all the configuration options needed to reproduce.With all that, rustfmt produces this:
Output:
If you're having issues / have questions you can leave comments here or message me on Zulip
siddhardh-codemonk commentedon Aug 29, 2026
Thanks again for the repro! I dug into this and found there are actually two separate bugs causing the two errors:
Trailing whitespace — traced to how handle_line pushes a space for continuation, then separately pushes a newline when a code block starts, without cleaning up the earlier space. Opened a PR fixing this: #7083
Width overflow — this one's in break_string's MIN_STRING threshold rejecting a valid break point and falling through to a forward search that doesn't re-check the width limit. It's more involved since it's shared wrapping logic used elsewhere, so I wanted to flag it here first rather than guess at a fix. Happy to take a swing at it if you can confirm the right direction (e.g. should the forward-search fallback verify width before accepting, or should MIN_STRING behave differently in this case?).