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

Disable the stability check with --line-ranges for now. #4034

Merged
merged 6 commits into from Nov 21, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
3 changes: 3 additions & 0 deletions CHANGES.md
Expand Up @@ -21,6 +21,9 @@

<!-- Changes to how Black can be configured -->

- `--line-ranges` now skips _Black_'s internal stability check in `--safe` mode. This
avoids a crash on rare inputs that have many unformatted same-content lines. (#4034)

### Packaging

- Upgrade to mypy 1.6.1 (#4049)
Expand Down
6 changes: 6 additions & 0 deletions docs/usage_and_configuration/the_basics.md
Expand Up @@ -196,6 +196,12 @@ Example: `black --line-ranges=1-10 --line-ranges=21-30 test.py` will format line

This option is mainly for editor integrations, such as "Format Selection".

```{note}
Due to [#4052](https://github.com/psf/black/issues/4052), `--line-ranges` might format
extra lines outside of the ranges when ther are unformatted lines with the exact
content. It also disables _Black_'s formatting stability check in `--safe` mode.
```

#### `--color` / `--no-color`

Show (or do not show) colored diff. Only applies when `--diff` is given.
Expand Down
9 changes: 7 additions & 2 deletions src/black/__init__.py
Expand Up @@ -1465,11 +1465,16 @@ def assert_stable(
src: str, dst: str, mode: Mode, *, lines: Collection[Tuple[int, int]] = ()
) -> None:
"""Raise AssertionError if `dst` reformats differently the second time."""
if lines:
# Formatting specified lines requires `adjusted_lines` to map original lines
# to the formatted lines before re-formatting the previously formatted result.
# Due to less-ideal diff algorithm, some edge cases produce incorrect new line
# ranges. Hence for now, we skip the stable check.
# See https://github.com/psf/black/issues/4033 for context.
return
# We shouldn't call format_str() here, because that formats the string
# twice and may hide a bug where we bounce back and forth between two
# versions.
if lines:
lines = adjusted_lines(lines, src, dst)
newdst = _format_str_once(dst, mode=mode, lines=lines)
if dst != newdst:
log = dump_to_file(
Expand Down
28 changes: 28 additions & 0 deletions tests/data/cases/line_ranges_diff_edge_case.py
@@ -0,0 +1,28 @@
# flags: --line-ranges=10-11
# NOTE: If you need to modify this file, pay special attention to the --line-ranges=
# flag above as it's formatting specifically these lines.

# Reproducible example for https://github.com/psf/black/issues/4033.
# This can be fixed in the future if we use a better diffing algorithm, or make Black
# perform formatting in a single pass.

print ( "format me" )
print ( "format me" )
print ( "format me" )
print ( "format me" )
print ( "format me" )

# output
# flags: --line-ranges=10-11
# NOTE: If you need to modify this file, pay special attention to the --line-ranges=
# flag above as it's formatting specifically these lines.

# Reproducible example for https://github.com/psf/black/issues/4033.
# This can be fixed in the future if we use a better diffing algorithm, or make Black
# perform formatting in a single pass.

print ( "format me" )
print("format me")
print("format me")
print("format me")
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why are these lines formatted? Shouldn't it only format the second and third prints?

Copy link
Contributor Author

@yilei yilei Nov 18, 2023

Choose a reason for hiding this comment

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

This is caused exactly by the diff algorithm used in adjusted_lines. In the second formatting pass, the adjusted lines becomes 12-13 but it should have stayed as 10-11.

This PR doesn't fix this underlying issue (I'll file a separate issue if this PR is merged). Until it's really fixed, I'm proposing to skip the stability check (affected by the same issue) to avoid the crash.

The edge case is very rare in real code as it requires many same unformatted lines.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see, thanks. Maybe in that case we should put a warning in the docs for now about this bug.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Agree that this doesn't feel very likely in real code, though @tartley apparently did run into this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated the doc.

@tartley can correct me, but #4033 appears to be a "toy" example for just trying out the new --line-ranges feature. #4052 can also serves the purpose of collecting real world example in case it happens.

What do you think?

Copy link

Choose a reason for hiding this comment

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

Agreed that I only encountered the problem using toy example code. By bad luck the toy example was the first thing I tried --line-ranges out on, while trying to integrate the use of it into my editor (e.g. so Vim would call Black on the selected range of lines). Although only a toy example it did genuinely confuse the heck out of me, and convinced me at the time that --line-ranges wasn't working for me at all.

print("format me")