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

Author: pablogsal

Lib/test/test_compile.py

@@ -752,6 +752,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

@@ -3894,7 +3894,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) {