Skip to content

Fix non-idempotent indentation of consecutive block comments - #7103

Open
saberoueslati wants to merge 1 commit into
rust-lang:mainfrom
saberoueslati:issue-7019-consecutive-block-comment
Open

Fix non-idempotent indentation of consecutive block comments#7103
saberoueslati wants to merge 1 commit into
rust-lang:mainfrom
saberoueslati:issue-7019-consecutive-block-comment

Conversation

@saberoueslati

@saberoueslati saberoueslati commented Sep 5, 2026

Copy link
Copy Markdown

Context

process_comment determined indentation only from the original source. For /*A*/ /*B*/, formatting the first comment added a newline, but the second was still treated as inline and indented by one space, requiring another pass to converge.

The fix also checks whether the output buffer ends with a newline. If so, the comment receives self.block_indent. Genuine trailing comments and already-canonical output remain unchanged, so no style-edition gate is needed.

Tests

Added source and target regression tests covering consecutive comments, nested blocks, comments between statements, trailing comments, and canonical input.

Closes #7019

  • I did not use an LLM to create a change in this PR.
  • I used an LLM to create a change in this PR, and I have explained below how it was used.

Used an LLM to better understand the code surrounding the changes and the issue. Changes made by me

@rustbot rustbot added the S-waiting-on-review Status: awaiting review from the assignee but also interested parties. label Sep 5, 2026
Comment thread src/missed_spans.rs
.find(|rev_c| ![' ', '\t'].contains(rev_c));

let fix_indent = last_char.map_or(true, |rev_c| ['{', '\n'].contains(&rev_c));
let starts_output_line = !self.buffer.is_empty() && self.buffer.ends_with('\n');

@matthewhughes934 matthewhughes934 Sep 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand this fix from a glance, can you explain what is the importance of self.buffer ending in a newline?

View changes since the review

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self.buffer ending in \n means the next comment starts a new output line. For /*A*/ /*B*/, writing /*A*/ adds a newline via the _ => arm at the end of process_comment. But last_char still sees the closing / of /*A*/ in the original source, so fix_indent is false and /*B*/ gets one space instead of the block indent. starts_output_line catches this and applies self.block_indent on the first pass, so reformatting no longer changes the output.

I hope this clears it up

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Non-idempotency in consecutive block comment

3 participants