Skip to content

fix: don't duplicate type bounds when a comment precedes the where clause - #6980

Open
shulaoda wants to merge 1 commit into
rust-lang:mainfrom
shulaoda:07-26-fix_don_t_duplicate_type_bounds_when_a_comment_precedes_the_where_clause
Open

fix: don't duplicate type bounds when a comment precedes the where clause#6980
shulaoda wants to merge 1 commit into
rust-lang:mainfrom
shulaoda:07-26-fix_don_t_duplicate_type_bounds_when_a_comment_precedes_the_where_clause

Conversation

@shulaoda

Copy link
Copy Markdown
Contributor

Summary

Closes #6234.

rewrite_where_clause takes a span_end_before_where argument marking where the source it still has to account for begins. missing_span_before_after_where turns it into the span handed to rewrite_missing_comment:

let missing_span_before = mk_sp(before_item_span_end, where_span.lo());

rewrite_ty passed generics.span.hi() for that argument, which points just past the type alias generics. The bounds sit between there and the where keyword, and rewrite_ty writes them into result itself a few lines earlier, so the span covered text that had already been emitted. When that region also holds a comment, rewrite_missing_comment emits the whole region and the bounds come out a second time.

type Bar<'a>: Baz1 // comment followed by a where clause formatted to type Bar<'a>: Baz1 and then : Baz1 // comment on the next line, which does not parse.

Recording the end of the last bound as the span start, in the same branch that writes the bounds, restores the contract. Aliases without bounds keep generics.span.hi(), since nothing between the generics and the where has been written at that point.

Review notes

#6815 was forked out of this issue and is not addressed here. There the comment sits between the bounds and the ; of an alias that has no where clause, a region no span is computed for at all, so it needs new handling rather than a corrected argument.

@rustbot rustbot added the S-waiting-on-review Status: awaiting review from the assignee but also interested parties. label Jul 25, 2026
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.

Rustfmt duplicate associated type bound in the presence of comment

2 participants