[pallet-revive] do not trap the caller on instantiations with duplicate contracts

[xermicus]

This PR changes the behavior of instantiate when the resulting contract address already exists (because the caller tried to instantiate the same contract with the same salt multiple times): Instead of trapping the caller, return an error code.

Solidity allows catching this, which doesn't work if we are trapping the caller. For example, the change makes the following snippet work:

try new Foo{salt: hex"00"}() returns (Foo) {
    // Instantiation was successful (contract address was free and constructor did not revert)
} catch {
    // This branch is expected to be taken if the instantiation failed because of a duplicate salt
}

revive PR: paritytech/revive#188

[xermicus]

/cmd prdoc --audience runtime_dev --bump major

[athei]

Nice catch. Thank you. I am wondering: The catch blocks of Solidty do also apply to reverts where some data is returned. Do we need to encode some error data here, too?

[xermicus]

Good point. There should be no need for us to encode anything, because the call family opcodes return success (where as the create family returns the address). resolc directly translates (inverts) the call return value to the success variable and the error data is already correctly encoded in the return data buffer (done by the callee contract). However, there still could be mismatches where we trap instead of returning a non-zero code. When I implemented this I reckoned we don't have any mismatch, however it has been a while ago and we had some changes.

[athei]

You are right we are good here. AFAIK the EVM never encodes anything into the return buffer. That is completely controlled by the callee contract. So for every error in a subcall that is not a revert the returndatasize should be 0.

Especially ContractTrapped is interesting here as it does not exist on Ethereum. Only reverts. But this would be the same as an invalid opcode on EVM which will also yield an empty return data.