[LuisFigueroaG]

Description

Two statements in a row that each have # fmt: skip inside a bracket crash Black:

foo(a  # fmt: skip
)
bar(b  # fmt: skip
)

fails with "INTERNAL ERROR: Black produced invalid code: cannot parse: 2:1" because the output is )bar(b # fmt: skip. The same happens when the second statement is a with, if, for, class, decorator or return whose first line is hidden, e.g. x = ( # fmt: skip ... ) followed by with ( # fmt: skip ... ):. This is a regression from #5610 and isn't in a release yet: 26.10.1 formats these fine.

#5610 keeps hidden code on the line where the previous hidden code ends when there is no newline in its prefix, for two # fmt: skip brackets in one statement. But the newline between two statements isn't in the prefix of the second one, it's in the NEWLINE token of the first. When # fmt: skip hides a whole statement, that token is hidden with it too, so nothing separates the two hidden parts anymore. And when the second statement is a compound statement, its keyword is hidden, so visit_stmt doesn't start a new line before it.

_continues_fmt_skip_line now also checks that the hidden code doesn't start a statement. Hidden code that continues the previous one's line always comes after something in the same statement, like the if of a conditional expression, or the ; it hides along with the next statement.

I checked ~18k generated combinations of two or three statements (with brackets hidden in different ways, one-liners, ;, # fmt: off, comments and blank lines, at module level and in a function) in stable, preview and unstable. Wherever main doesn't crash, the output is the same with this branch, and none of them crash now.

Checklist - did you ...

• Implement any code style changes under the --preview style, following the stability policy?
• Add an entry in CHANGES.md if necessary?
• Add / update tests if necessary?
• Add new / update outdated documentation?

[cobaltt7]

This change is not as accurately described by this changelog entry as the others. You can check if there's a different changelog entry that fits well or make a new one (just please try to keep it concise and avoid internal details)

[LuisFigueroaG]

Thanks, I gave it its own entry under Stable style instead.

[github-actions]

diff-shades results comparing this PR (cbe4c96) to main (f74dfd7):

--preview style: no changes

--stable style: no changes

---

What is this? | Workflow run | diff-shades documentation