|
112 | 112 | # The result is in conflict with the yellow-paper:
|
113 | 113 | # * https://github.com/ethereum/py-evm/pull/1224#issuecomment-418800369
|
114 | 114 | ('GeneralStateTests/stRevertTest/RevertInCreateInInit_d0g0v0.json', 'RevertInCreateInInit_d0g0v0_Byzantium'), # noqa: E501
|
| 115 | + ('GeneralStateTests/stRevertTest/RevertInCreateInInit_d0g0v0.json', 'RevertInCreateInInit_d0g0v0_Constantinople'), # noqa: E501 |
| 116 | + |
| 117 | + # The CREATE2 variant seems to have been derived from the one above - it, too, |
| 118 | + # has a "synthetic" state, on which py-evm flips. |
| 119 | + # * https://github.com/ethereum/py-evm/pull/1181#issuecomment-446330609 |
| 120 | + ('GeneralStateTests/stCreate2/RevertInCreateInInitCreate2_d0g0v0.json', 'RevertInCreateInInitCreate2_d0g0v0_Constantinople'), # noqa: E501 |
| 121 | + |
| 122 | + # Four variants have been specifically added to test a collision type |
| 123 | + # like the above; therefore, they fail in the same manner. |
| 124 | + # * https://github.com/ethereum/py-evm/pull/1579#issuecomment-446591118 |
| 125 | + # Interestingly, for py-evm - but not trinity! - |
| 126 | + # d2 passes in Constantinople after a refactor of storage handling. |
| 127 | + # The same test was already passing in ConstantinopleFix. |
| 128 | + # Since the situation is synthetic, not much research went into why, yet. |
| 129 | + ('GeneralStateTests/stSStoreTest/InitCollision_d0g0v0.json', 'InitCollision_d0g0v0_Constantinople'), # noqa: E501 |
| 130 | + ('GeneralStateTests/stSStoreTest/InitCollision_d1g0v0.json', 'InitCollision_d1g0v0_Constantinople'), # noqa: E501 |
| 131 | + ('GeneralStateTests/stSStoreTest/InitCollision_d2g0v0.json', 'InitCollision_d2g0v0_Constantinople'), # noqa: E501 |
| 132 | + ('GeneralStateTests/stSStoreTest/InitCollision_d3g0v0.json', 'InitCollision_d3g0v0_Constantinople'), # noqa: E501 |
115 | 133 | }
|
116 | 134 |
|
117 | 135 | RPC_STATE_NORMALIZERS = {
|
|
0 commit comments