Black produced different code on the second pass of the formatter.

[jdherg-brilliant]

Describe the bug
Running Black on the given snippet produces the second-pass error.

To Reproduce Steps to reproduce the behavior:

Open this Black playground link.

Alternatively, paste this code into the Black playground:

foo = bar(
    "x123456789x123456789x123456",
    x123456789x123456789x12("x123456789x12345678",
                            "true")) in (baz,)

Expected behavior A clear and concise description of what you expected to happen:
Successful formatting by Black.

Actual behavior Second-pass error fires:

INTERNAL ERROR: Black produced different code on the second pass of the formatter.  Please report a bug on https://github.com/psf/black/issues.  This diff might be helpful: /tmp/blk_jl_w30jh.log

Mode(target_versions=set(), line_length=88, string_normalization=True, magic_trailing_comma=True, experimental_string_processing=False, is_pyi=False)
--- source
+++ first pass
@@ -1,4 +1,4 @@
 foo = bar(
     "x123456789x123456789x123456",
-    x123456789x123456789x12("x123456789x12345678",
-                            "true")) in (baz,)
+    x123456789x123456789x12("x123456789x12345678", "true"),
+) in (baz,)
--- first pass
+++ second pass
@@ -1,4 +1,7 @@
-foo = bar(
-    "x123456789x123456789x123456",
-    x123456789x123456789x12("x123456789x12345678", "true"),
-) in (baz,)
+foo = (
+    bar(
+        "x123456789x123456789x123456",
+        x123456789x123456789x12("x123456789x12345678", "true"),
+    )
+    in (baz,)
+)

Environment (please complete the following information):

Black playground.

Does this bug also happen on master? To answer this, you have two options:
Yes

Additional Context

I've tried to make this a fairly minimal case: the bug doesn't repro if any of the xNNNN tokens are shortened or any of the tokens are removed.

Thanks for reviewing! :)

[jdherg-brilliant]

Starting from a different part of our codebase that was triggering an error, this feels similar enough that I'm going to add it here rather than make a new issue:

Playground

foo = x123456789 in ("x123456789", "x123456789", "x123456789") and x123456789x123456789 in ("x",)

leads to

INTERNAL ERROR: Black produced different code on the second pass of the formatter.  Please report a bug on https://github.com/psf/black/issues.  This diff might be helpful: /tmp/blk_qo44gbdk.log

Mode(target_versions=set(), line_length=88, string_normalization=True, experimental_string_processing=False, is_pyi=False)
--- source
+++ first pass
@@ -1 +1,5 @@
-foo = x123456789 in ("x123456789", "x123456789", "x123456789") and x123456789x123456789 in ("x",)
+foo = x123456789 in (
+    "x123456789",
+    "x123456789",
+    "x123456789",
+) and x123456789x123456789 in ("x",)
--- first pass
+++ second pass
@@ -1,5 +1,9 @@
-foo = x123456789 in (
-    "x123456789",
-    "x123456789",
-    "x123456789",
-) and x123456789x123456789 in ("x",)
+foo = (
+    x123456789
+    in (
+        "x123456789",
+        "x123456789",
+        "x123456789",
+    )
+    and x123456789x123456789 in ("x",)
+)

[jdherg-brilliant]

Oh jeez I somehow missed the pinned issue -- it looks like this is perhaps that class of error (or at least trailing commas are being added on the first pass). Should I just add these examples there and close this out?

[ichard26]

Hello!

All reproduction cases in this issue format without error on master. The fixing commit was 8672af3 from PR GH-2126. I'll be marking this issue as a duplicate of GH-1629 since that's what GH-2126 aimed to fix and it's highly likely this issue falls under GH-1629.

Since we use the issue tracker as a reflection of what's on master, I'll be closing this issue. If you have any issues, especially with the new (but stable) output, please open a new issue. Oh and the fix should be available in a published release soon, see GH-2125 for more info.

Thank you for reporting!