-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Ruff has unstable results with target-version (normally hidden by caching) #10267
Comments
aneeshusa
changed the title
Ruff cache causes unstable results
Ruff has unstable results with target-version (normally hidden by caching)
Mar 7, 2024
To summarize the report: The problem @aneeshusa is facing is a formatter stability issue when formatting # Input
with (
open(
"/etc/hosts" # This is an incredibly long comment that has been replaced for sanitization
)
):
pass
# Formatted once
with open(
"/etc/hosts" # This is an incredibly long comment that has been replaced for sanitization
):
pass
# Formatted twice
with (
open(
"/etc/hosts" # This is an incredibly long comment that has been replaced for sanitization
)
):
pass |
charliermarsh
pushed a commit
that referenced
this issue
Mar 8, 2024
## Summary Fixes #10267 The issue with the current formatting is that the formatter flips between the `SingleParenthesizedContextManager` and `ParenthesizeIfExpands` or `SingleWithTarget` because the layouts use incompatible formatting ( `SingleParenthesizedContextManager`: `maybe_parenthesize_expression(context)` vs `ParenthesizeIfExpands`: `parenthesize_if_expands(item)`, `SingleWithTarget`: `optional_parentheses(item)`. The fix is to ensure that the layouts between which the formatter flips when adding or removing parentheses are the same. I do this by introducing a new `SingleWithoutTarget` layout that uses the same formatting as `SingleParenthesizedContextManager` if it has no target and prefer `SingleWithoutTarget` over using `ParenthesizeIfExpands` or `SingleWithTarget`. ## Formatting change The downside is that we now use `maybe_parenthesize_expression` over `parenthesize_if_expands` for expressions where `can_omit_optional_parentheses` returns `false`. This can lead to stable formatting changes. I only found one formatting change in our ecosystem check and, unfortunately, this is necessary to fix the instability (and instability fixes are okay to have as part of minor changes according to our versioning policy) The benefit of the change is that `with` items with a single context manager and without a target are now formatted identically to how the same expression would be formatted in other clause headers. ## Test Plan I ran the ecosystem check locally
nkxxll
pushed a commit
to nkxxll/ruff
that referenced
this issue
Mar 10, 2024
## Summary Fixes astral-sh#10267 The issue with the current formatting is that the formatter flips between the `SingleParenthesizedContextManager` and `ParenthesizeIfExpands` or `SingleWithTarget` because the layouts use incompatible formatting ( `SingleParenthesizedContextManager`: `maybe_parenthesize_expression(context)` vs `ParenthesizeIfExpands`: `parenthesize_if_expands(item)`, `SingleWithTarget`: `optional_parentheses(item)`. The fix is to ensure that the layouts between which the formatter flips when adding or removing parentheses are the same. I do this by introducing a new `SingleWithoutTarget` layout that uses the same formatting as `SingleParenthesizedContextManager` if it has no target and prefer `SingleWithoutTarget` over using `ParenthesizeIfExpands` or `SingleWithTarget`. ## Formatting change The downside is that we now use `maybe_parenthesize_expression` over `parenthesize_if_expands` for expressions where `can_omit_optional_parentheses` returns `false`. This can lead to stable formatting changes. I only found one formatting change in our ecosystem check and, unfortunately, this is necessary to fix the instability (and instability fixes are okay to have as part of minor changes according to our versioning policy) The benefit of the change is that `with` items with a single context manager and without a target are now formatted identically to how the same expression would be formatted in other clause headers. ## Test Plan I ran the ecosystem check locally
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am switching from shed to ruff at $WORK and found what looks like a bug in Ruff's formatter (unstable output);
normally this appears to be hidden by caching, implying a second bug in the caching logic.
Here's a minimized repro with
target-version
and a particular code pattern(further minimization ideas I tried broke the repro but some likely exist):
N.B. I have no ruff config settings, and didn't see related issues/PRs but let me know if I missed one!
Script that produced this output
The text was updated successfully, but these errors were encountered: