Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

leverage itemize_list and write_list to recover trait bound comments #6048

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ytmimi
Copy link
Contributor

@ytmimi ytmimi commented Jan 29, 2024

Fixes #2055

Now when using version::Two, rustfmt will permit comments within trait bounds and actually reformat them instead of refusing to rewrite the entire trait definition because there are comments in the bounds.

This follows the approach hinted at in #2055 (comment).

Edit -- Other issues fixed by this change:
Fixes #6127

Comment on lines -26 to +27
> + fmt::Write
>
+ fmt::Write
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Taking a look at the style guide description for traits

emphasis mine:

Prefer not to line-break in the bounds if possible (consider using a where clause). Prefer to break between bounds than to break any individual bound. If you must break the bounds, put each bound (including the first) on its own block-indented line, break before the + and put the opening brace on its own line:

I think these changes align more closely with the language in the guide than the formatting that we had before, but please let me know if I'm misinterpreting the guide.

} else {
indented.indent.to_string_with_newline(&context.config)
};
result.push(':');
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should we apply space_before_colon?

Comment on lines +1228 to +1230
// `offset_left` takes into account what we've rewritten already + 1 for `:`
// `sub_width` take into account the trailing `{`
shape.offset_left(header.width() + 1)?.sub_width(1)?
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Might need to be header.width() + 2 if we're applying space_before_colon, Also I'm realizing that the header doesn't contain any rewritten generics. Might be better to move the shape derivation into rewrite_bounds

Fixes 2055

Now when using `version::Two`, rustfmt will permit comments within trait
bounds and actually reformat them instead of refusing to rewrite the
entire trait definition because there are comments in the bounds.
@ytmimi
Copy link
Contributor Author

ytmimi commented Mar 30, 2024

TODO: add test case for #5321, which I think this also fixes

@gui1117
Copy link

gui1117 commented Sep 7, 2024

I tried a bit, I think we can do better for supertrait:

I have this code:

pub trait MyLongTraitName:
	MyLongBoundName<
		MyLongAssociatedType:
			SomeAnotherBound<
				YetAnotherType: YetAnotherBound,
				YetAnotherType2: YetAnotherBound2
			>,
		OtherType: SmallBound
			+ SmallBound2
			+ AnotherLongBound<
				WithSomeType: BeingBound,
				WithSomeType2: BeingBound,
				WithSomeType3: BeingBound
			>
			+ SmallBound3
			+ AnotherLongBound2<
				WithSomeType: BeingBound,
				WithSomeType2: BeingBound,
				WithSomeType3: BeingBound
			>,
	>
{}

It gets formatted into this with this PR:

pub trait MyLongTraitName:
    MyLongBoundName<
        MyLongAssociatedType: SomeAnotherBound<
            YetAnotherType: YetAnotherBound,
            YetAnotherType2: YetAnotherBound2,
        >,
        OtherType: SmallBound
                       + SmallBound2
                       + AnotherLongBound<
            WithSomeType: BeingBound,
            WithSomeType2: BeingBound,
            WithSomeType3: BeingBound,
        > + SmallBound3
                       + AnotherLongBound2<
            WithSomeType: BeingBound,
            WithSomeType2: BeingBound,
            WithSomeType3: BeingBound,
        >,
    >
{
}

we can see the generics inside AnotherLongBound are not correctly formatted.
And the + is maybe too far on the right?

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

Successfully merging this pull request may close these issues.

Multi-line Fn supertraits are indented improperly trait bounds with comments are not formatted
3 participants