bpo-41531: Fix compilation of dict literals with more than 0xFFFF elements (GH-21850)
This commit is contained in:
parent
8ecc0c4d39
commit
c51db0ea40
|
@ -752,6 +752,16 @@ if 1:
|
|||
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
|
||||
|
|
|
@ -0,0 +1,2 @@
|
|||
Fix a bug that was dropping keys when compiling dict literals with more than
|
||||
0xFFFF elements. Patch by Pablo Galindo.
|
|
@ -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) {
|
||||
|
|
Loading…
Reference in New Issue