bpo-41531: Fix compilation of dict literals with more than 0xFFFF elements (GH-21850) (GH-22107)

(cherry picked from commit c51db0e)

Co-authored-by: Pablo Galindo <[email protected]>

Author: miss-islington

Lib/test/test_compile.py

@@ -750,6 +750,16 @@ def continue_in_while():
             self.assertEqual(None, opcodes[0].argval)
             self.assertEqual('RETURN_VALUE', opcodes[1].opname)
 
+    def test_big_dict_literal(self):
+        # The compiler has a flushing point in "compiler_dict" that calls compiles
+        # a portion of the dictionary literal when the loop that iterates over the items
+        # reaches 0xFFFF elements but the code was not including the boundary element,
+        # dropping the key at position 0xFFFF. See bpo-41531 for more information
+
+        dict_size = 0xFFFF + 1
+        the_dict = "{" + ",".join(f"{x}:{x}" for x in range(dict_size)) + "}"
+        self.assertEqual(len(eval(the_dict)), dict_size)
+
 class TestExpressionStackSize(unittest.TestCase):
     # These tests check that the computed stack size for a code object
     # stays within reasonable bounds (see issue #21523 for an example

Misc/NEWS.d/next/Core and Builtins/2020-08-12-19-32-15.bpo-41531.WgPzjT.rst

@@ -0,0 +1,2 @@
+Fix a bug that was dropping keys when compiling dict literals with more than
+0xFFFF elements. Patch by Pablo Galindo.

Python/compile.c

@@ -3890,7 +3890,7 @@ compiler_dict(struct compiler *c, expr_ty e)
         }
         else {
             if (elements == 0xFFFF) {
-                if (!compiler_subdict(c, e, i - elements, i)) {
+                if (!compiler_subdict(c, e, i - elements, i + 1)) {
                     return 0;
                 }
                 if (have_dict) {