-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Conversation
2bd63c3
to
719e57b
Compare
|
crates/ruff_formatter/src/buffer.rs
Outdated
FormatElement::Tag(Tag::StartConditionalContent(condition)) | ||
if condition.mode.is_expanded() => | ||
{ | ||
self.state.increment_conditional_content(); | ||
return; | ||
} | ||
|
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
).
There was a problem hiding this comment.
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
1059392
to
844e0e4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
… 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
Summary
Fixes #14487
The
RemoveSoftLineBuffer
should remove any content "expanded"-only content. For example, it removes all soft line breaks and replacessoft_line_break_or_space
with aspace
.However, it didn't remove any
if_group_breaks
usages.This PR extends the
RemoveSoftLineBuffer
to also remove any content insideif_group_breaks
. This is slightly more complicated because it requires removing multiple elements andif_group_breaks
call can be nested.Test Plan
Added test