Black produced different code on the second pass of the formatter

[mlucool]

Describe the bug A clear and concise description of what the bug is.
I received the following error: Black produced different code on the second pass of the formatter.

To Reproduce Steps to reproduce the behavior:

This has an error

if klass._type_id in (self._some._type_id,
                      self._some_very_long_type._type_id) and \
                not hasattr(value, '__iter__'):
                return 1

But this does not:

if klass._type_id in (self._some._type_id,
                      self._some_type._type_id) and \
                not hasattr(value, '__iter__'):
                return 1

Error from the first one:

$ black foo.py 
error: cannot format foo.py: 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_rf20u847.log
Oh no! 💥 💔 💥
1 file failed to reformat.


$ cat /tmp/blk_rf20u847.log
Mode(target_versions={<TargetVersion.PY27: 2>}, line_length=88, string_normalization=True, magic_trailing_comma=True, experimental_string_processing=False, is_pyi=False)
--- source
+++ first pass
@@ -1,5 +1,5 @@
-if klass._type_id in (self._some._type_id,
-                      self._some_very_long_type._type_id) and \
-                not hasattr(value, '__iter__'):
-                return 1
-
+if klass._type_id in (
+    self._some._type_id,
+    self._some_very_long_type._type_id,
+) and not hasattr(value, "__iter__"):
+    return 1
--- first pass
+++ second pass
@@ -1,5 +1,9 @@
-if klass._type_id in (
-    self._some._type_id,
-    self._some_very_long_type._type_id,
-) and not hasattr(value, "__iter__"):
+if (
+    klass._type_id
+    in (
+        self._some._type_id,
+        self._some_very_long_type._type_id,
+    )
+    and not hasattr(value, "__iter__")
+):

Expected behavior

It formats the file

Environment (please complete the following information):

• Version: master
• OS and Python version: Linux Python 3.7.4

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

[mvolfik]

Likely a duplicate of #1629 , as this file works after applying #1958

[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!