Closed ghost closed 6 months ago
Oh, that's interesting! Thanks for the very detailed bug report, it's super-helpful. Sorry about that issue, and sorry for being so late in responding. Let me look at this the beginning of next week!
Mate
@0xRalts Can you give a full run? I have a feeling it may have also printed, after that text, something along the lines of:
No reachable assertion violations, but all branches reverted
Prefix this testname with `proveFail` if this is expected
Did it? Or did it not print anything afterwards?
BTW, based on this issue, I am updating the printing so it'll be less ambiguous :)
Ahhh I think I can reproduce this now! Sorry... working on it now!
I think something like this can happen:
Running 2 test(s) for src/contract-bail.sol:MyContract
Exploring contract
Explored contract (2 branches)
Checking for reachability of 1 potential property violation(s)
[FAIL] prove_add_value2(address,uint256)
Exploring contract
Explored contract (3 branches)
Checking for reachability of 2 potential property violation(s)
[FAIL] prove_add_value(address,uint256)
List of counterexaple(s) follow.
Counterexample:
result: Revert: 0x4e487b710000000000000000000000000000000000000000000000000000000000000001
calldata: prove_add_value2(0x0000000000000000000000000000000000001312,23158417847463239084714197001737581570653996933128112807891516801582625927989)
List of counterexaple(s) follow.
Counterexample:
result: Revert: 0x4e487b710000000000000000000000000000000000000000000000000000000000000001
calldata: prove_add_value(0x0000000000000000000000000000000000000000,23158417847463239084714197001737581570653996933128112807891516801582625927989)
Which is counterintutive. I'll fix this now.
I have really been making a lot of progress here. Thank you SO MUCH for highlighting this issue. I myself have been confused. It's gonna be a lot clearer from now on :)
Hi @msooseth , I'm using this account since I could recover it.
If it still helps:
@0xRalts Can you give a full run? I have a feeling it may have also printed, after that text, something along the lines of: No reachable assertion violations, but all branches reverted Prefix this testname with
proveFail
if this is expected Did it? Or did it not print anything afterwards?
It didn't print anything as far as I remember. But could actually happen what you stated that was counter intuitive.
Thank you for the updates. I'm looking forward to keep up with hevm development and helping if possible!
@joaovaladares Thanks for the feedback! This PR should help: https://github.com/ethereum/hevm/pull/472 Please let me know if the printed output looks more sane than before -- there is an example in the PR both of the OLD and the NEW. Let me know if you'd prefer it to be different! I am not a visual designer, but it should be at least better than what was there before :)
I'm also not a visual designer but from a user perspective this looks way nicer!
Hey @joaovaladares the related PR has now been merged, yay! Also, thanks to @zoep we got an even-nicer looking output, yay! Thanks so much for opening this issue, it really highlighted that the output was very messy indeed. Thanks again! Closing.
I'm using
forge build
to compile andhevm test --match function
to run the testsI have the following structure for my prove_ tests:
Declaring my ERC20 Token (simply OpenZeppelin implementation where I mint some tokens initially)
My ERC20 properties folder where all tests should inherit
OpenZeppelin's ERC20 test file.
When I run
hevm test --match prove_transferChangeState
it returns me the following:However if I comment out the last line of the property implementation ->
assert(IERC20(token).balanceOf(other) == oldBalanceOther);
the test gives me a PASS. What is the actual reason for this test to be failing?