Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add global failure #30

Merged
merged 4 commits into from
Apr 6, 2022
Merged

Conversation

brockelmore
Copy link
Contributor

@brockelmore brockelmore commented Apr 1, 2022

Open to feedback on this, but it adds a global failure check if the cheatcode address has any code in it (dapptools and forge both do). This works by storeing a bool in slot 0 of the HEVM_ADDRESS & changing the failed to a private var with a custom view function that checks the slot. I was going to have it be a custom address, but forge uses a state changeset that only produces state changes if a contract has bytecode & without forge's etch cheatcode we can't do that here. I doubt anyone uses the HEVM address for storage like this anyway so I dont think it should be a problem. I could change the slot to bytes32("failed") if that would be better.

Some notes on implementation:

  1. Have to hardcode HEVM_ADDRESS as an actual address in extcodesize call to satisfy 0.4.23 solidity semantics (constants not allowed in assembly blocks in that old version, but lifted in later versions)
  2. I introduced a limited interface to the cheatcodes, primarily so users don't get confused between cheatcodes afforded by hevm and forge. I am willing to switch this to a low level call if the current implementation is annoying

Would allow for easy fix for dapphub/dapptools#768

@d-xo
Copy link
Contributor

d-xo commented Apr 1, 2022

generally supportive, this seems like a nice fix to some legit issues.

I would slightly prefer the bytes32("failed") slot, and the low level call just to avoid cluttering up the namespace.

cc @MrChico and @rainbreak, any thoughts and opinions?

@gakonst
Copy link

gakonst commented Apr 3, 2022

ACK on the fix - indifferent on the low level calls / storage slot name. Whatever @d-xo @MrChico @rainbreak prefer

@d-xo
Copy link
Contributor

d-xo commented Apr 6, 2022

got an out of band lgtm from @MrChico.

@brockelmore if you :

  1. change the slot to bytes32("failed") (because we may want to store other stuff in HEVM_ADDRESS one day)
  2. switch to a low level call

then I will merge 👍

@brockelmore
Copy link
Contributor Author

brockelmore commented Apr 6, 2022

Update for @MrChico:
Solidity 0.4.x doesn't support getting data from low-level calls. So we were left with either version bump or minimal interface. Speaking with @d-xo, it was decided a minimum version bump (to 0.5.0) was the better option (i agree fwiw). Should be good to go now imo. lmk if you guys want any styling changes

tested on all major versions (0.5.0, 0.6.0, 0.7.0, 0.8.0)

@d-xo d-xo merged commit 57c31d6 into dapphub:master Apr 6, 2022
@d-xo
Copy link
Contributor

d-xo commented Apr 6, 2022

Thanks!

d-xo added a commit to dapphub/dapptools that referenced this pull request Jun 29, 2022
Since dapphub/ds-test#30 calls to `failed()` can
contain reverting branches due to the call into abi.decode().

This meant that using prove tests with the latest ds-test version would
always fail with a hard error.

This change updates the symbolic test stepper to correctly report
`bailed` as true for branches that reverted during the call to
`failed()`.
d-xo added a commit to dapphub/dapptools that referenced this pull request Jun 29, 2022
Since dapphub/ds-test#30 calls to `failed()` can
contain reverting branches due to the call into abi.decode().

This meant that using prove tests with the latest ds-test version would
always fail with a hard error.

This change updates the symbolic test stepper to correctly report
`bailed` as true for branches that reverted during the call to
`failed()`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants