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

Adjust rhs shape width to account for next line indentation #5327

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

Conversation

ytmimi
Copy link
Contributor

@ytmimi ytmimi commented Apr 30, 2022

Fixes #5321

Previously the Shape returned from expr::shape_from_rhs_tactic would always return a Shape with a width == config.max_width when the rhs_tactic was RhsTactics::ForceNextLineWithoutIndent and the
indentation was 0. For example, when rewriting generic trait bounds at the top level of a file.

In this case, trait bounds that were between (max_width - tab_spaces) and max_width, would be considered properly formatted and wouldn't wrap.

Now, the shape takes into account the whitespace to properly wrap when the max_width is exceeded.

@calebcartwright
Copy link
Member

Need to think on this for a bit to determine whether it meets the criteria of a true bug or if it's at risk of violating our stability guarantee and would need to be gated. It's likely going to end up being the latter even though there's a reasonable case to be made for the former

ytmimi added 2 commits May 19, 2022 11:50
Fixes 5321

Previously the `Shape` returned from `expr::shape_from_rhs_tactic` would
always return a `Shape` with a `width` == `config.max_width` when the
`rhs_tactic` was `RhsTactics::ForceNextLineWithoutIndent` and the
indentation was 0. For example, when rewriting generic trait bounds at
the top level of a file.

In this case, trait bounds that were between (`max_width` - `tab_spaces`)
and `max_width`, would be considered properly formatted and wouldn't
wrap.

Now, the shape takes into account the whitespace to properly wrap
when the `max_width` is exceeded.
Although the issue described in 5321 could be considered a bug, it might
also lead to breaking formatting changes. For that reason the fix is
only applied when `version=Two`
@ytmimi
Copy link
Contributor Author

ytmimi commented May 19, 2022

@calebcartwright I went ahead and version gated the changes. If we decide that It doesn't need to be version gated it should be easy to revert the 2nd commit.

@ytmimi ytmimi added the p-low label Jul 28, 2022
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.

Supertrait bounds sometimes exceed max_width after formatting
2 participants