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

Fix unnecessary space around power op in overlong f-string expressions #14489

Merged
merged 3 commits into from
Nov 22, 2024

Conversation

MichaReiser
Copy link
Member

Summary

Fixes #14487

The RemoveSoftLineBuffer should remove any content "expanded"-only content. For example, it removes all soft line breaks and replaces soft_line_break_or_space with a space.
However, it didn't remove any if_group_breaks usages.

This PR extends the RemoveSoftLineBuffer to also remove any content inside if_group_breaks. This is slightly more complicated because it requires removing multiple elements and
if_group_breaks call can be nested.

Test Plan

Added test

@MichaReiser MichaReiser added bug Something isn't working formatter Related to the formatter preview Related to preview mode features labels Nov 20, 2024
@MichaReiser MichaReiser force-pushed the micha/remove-soft-line-conditional-content branch from 2bd63c3 to 719e57b Compare November 20, 2024 14:33
@MichaReiser MichaReiser marked this pull request as ready for review November 20, 2024 14:34
Copy link
Contributor

github-actions bot commented Nov 20, 2024

ruff-ecosystem results

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

crates/ruff_formatter/src/buffer.rs Outdated Show resolved Hide resolved
Comment on lines 471 to 466
FormatElement::Tag(Tag::StartConditionalContent(condition))
if condition.mode.is_expanded() =>
{
self.state.increment_conditional_content();
return;
}

Copy link
Member

Choose a reason for hiding this comment

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

This is just for my understanding - the reason this exists here in addition to being in should_drop as well is because of the Default state which would mean that the should_drop will return false. But, we don't need to match against EndConditionalContent as it'll be taken care during the should_drop check.

I wonder if this could be simplified to only have a counter where any value > 0 indicates that we're in "if_group_breaks" and 0 indicates that we're outside of it. Or, do you foresee any other states that we might want to track in RemoveSoftLineBreaksState?

Copy link
Member Author

Choose a reason for hiding this comment

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

We could probably just use one usize for it where 0 indicates that we're inside an if_group_breaks if we change the implementation to start the level at 1 instead of zero.

However, I do like the explicit state because it documents what's going on here.

Copy link
Member

Choose a reason for hiding this comment

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

I'm fine with the explicit state, I just found the multiple usages of incrementing but only a single usage of decrementing the value a bit confusing. I had to look at it a bit closely to understand why this is the case.

Copy link
Member Author

Choose a reason for hiding this comment

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

I just found the multiple usages of incrementing but only a single usage of decrementing the value a bit confusing

I don't think that would change by switching to using an usize instead of an explicit enum (we could "hide it" by using saturating_sub).

Copy link
Member Author

Choose a reason for hiding this comment

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

There was actually a bug that we called increment twice in some cases. I refactored the code a bit

@MichaReiser MichaReiser force-pushed the micha/remove-soft-line-conditional-content branch from 1059392 to 844e0e4 Compare November 21, 2024 08:40
Copy link
Member

@dhruvmanila dhruvmanila left a comment

Choose a reason for hiding this comment

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

Thanks!

@MichaReiser MichaReiser merged commit 302fe76 into main Nov 22, 2024
20 checks passed
@MichaReiser MichaReiser deleted the micha/remove-soft-line-conditional-content branch November 22, 2024 12:01
MichaReiser added a commit that referenced this pull request Dec 6, 2024
… in expression part (#14811)

## Summary

Fixes #14778


The formatter incorrectly removed the inner implicitly concatenated
string for following single-line f-string:

```py
f"{'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' 'a' if True else ""}"

# formatted
f"{ if True else ''}"
```

This happened because I changed the `RemoveSoftlinesBuffer` in
#14489 to remove any content
wrapped in `if_group_breaks`. After all, it emulates an *all flat*
layout. This works fine when `if_group_breaks` is only used to **add**
content if the gorup breaks. It doesn't work if the same content is
rendered differently depending on if the group fits using
`if_group_breaks` and `if_groups_fits` because the enclosing `group`
might still *break* if the entire content exceeds the line-length limit.

This PR fixes this by unwrapping any `if_group_fits` content by removing
the `if_group_fits` start and end tags.


## Test Plan

added test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working formatter Related to the formatter preview Related to preview mode features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

F-string formatting adds unnecessary space after ** operator
2 participants