Open iamrecursion opened 1 year ago
Here is a minimal reproducible based on the test in shardwallet.rs
struct ShardData {
// Changing the order of the struct also affects the triggering of the bug
uint24 shareMicros;
uint64 firstSibling;
}
contract Shardwallet {
address private _owner;
uint64 nextTokenId_;
mapping(uint64 => ShardData) private shardData_;
// It also has to be an array to trigger the bug
mapping(uint64 => uint64[]) private parents_;
function computeClaimed() public {
parents_[nextTokenId_] = new uint64[](1);
ShardData memory data = shardData_[0x0];
uint64 childIndex = 0x0 - data.firstSibling;
uint64[] memory first_access = parents_[data.firstSibling];
uint64[] memory second_access = parents_[shardData_[0x0].firstSibling];
}
}
Note that you need to run it with optimization (--optimize-runs 200000
like was used in the original contract) to trigger the bug
608060405234801561001057600080fd5b506004361061002b5760003560e01c8063be795c9514610030575b600080fd5b61003861003a565b005b604080516001808252818301909252906020808301908036833750506000805474010000000000000000000000000000000000000000900467ffffffffffffffff168152600260209081526040909120835161009b9491935091019061026c565b50600080805260016020908152604080518082019091527fa6eef7e35abe7026729641147f7915573c7e97b47efa546f5f6e3230263bcb495462ffffff811682526301000000900467ffffffffffffffff1691810182905291906100ff908261033c565b60208084015167ffffffffffffffff16600090815260028252604080822080548251818602810186019093528083529495509193909283018282801561019857602002820191906000526020600020906000905b82829054906101000a900467ffffffffffffffff1667ffffffffffffffff16815260200190600801906020826007010492830192600103820291508084116101535790505b50507fa6eef7e35abe7026729641147f7915573c7e97b47efa546f5f6e3230263bcb49546301000000900467ffffffffffffffff1660009081526002602090815260408083208054825181850281018501909352808352979850929690955091935090915083018282801561026057602002820191906000526020600020906000905b82829054906101000a900467ffffffffffffffff1667ffffffffffffffff168152602001906008019060208260070104928301926001038202915080841161021b5790505b50505050505050505050565b828054828255906000526020600020906003016004900481019282156103175791602002820160005b838211156102e157835183826101000a81548167ffffffffffffffff021916908367ffffffffffffffff1602179055509260200192600801602081600701049283019260010302610295565b80156103155782816101000a81549067ffffffffffffffff02191690556008016020816007010492830192600103026102e1565b505b50610323929150610327565b5090565b5b808211156103235760008155600101610328565b600067ffffffffffffffff83811690831681811015610384577f4e487b7100000000000000000000000000000000000000000000000000000000600052601160045260246000fd5b03939250505056fea26469706673582212204163e5ce43bf059c1cd774988fcd16b4c1972a1441182a81bbfd473c205dbbbf64736f6c63430008090033
Describe the Bug
We currently infer infinite types (which get loop-broken and written out as
AbiType::InfiniteType
) in certain cases. This is never correct in the output, and is instead a sign that we are likely not inferring things properly.Previously this has been due to loops in usages of certain values with type constructor types, and has indicated that we are not quite correct in one or more of our inference rules.
To Reproduce
Steps to reproduce the behavior:
shardwallet.rs
test.Expected Behaviour
We do not infer infinite types in the output in situations where it should be impossible to have an infinite type.