Closed 77abe77 closed 11 months ago
unable to reproduce:
Running 1 test for test/Timestamp.t.sol:ForgeBug
[PASS] test_timebug() (gas: 13628)
Logs:
start: 1
skip 15 sec: 16
skip 15 sec: 31
skip 15 sec: 46
skip 15 sec: 61
start: 1
end: 61
duration: 60
@mattsse what forge version are you running?
@77abe77 are you compiling with via-ir? If so see the convo and links in https://github.com/foundry-rs/foundry/issues/4934#issuecomment-1546667682
@mds1 good catch, yes I am! will take a look
@mds1 - maybe we should add vm.blockTimestamp()
and vm.blockHeight()
cheatcodes (as non-pure fns)
Effectively this prevents the optimizer from doing this. Alternatively we could add a vm.blackbox(...)
that just echos the input data but overloading it would be a pain. So forge specific timestamps/block heights may make sense? Ergonomics of this aren't great, but at least we can point people to it 🤷
vm.blockTimestamp()
and vm.blockNumber()
are nice workarounds, I like that idea. Agreed it’s a bit clunky, but the native cheat is still simpler than users having to implement a workaround themselves, so supportive 👍
Component
Forge
Have you ensured that all of these are up to date?
What version of Foundry are you on?
forge 0.2.0 (619f3c5 2023-10-22T00:19:08.867786000Z)
What command(s) is the bug in?
forge test -vvvv --mc "ForgeBug"
Operating System
None
Describe the bug
Two bugs, easy to reproduce:
Consists of 2 contracts
ForgeBug
andForgeBug1
Common bug in both contracts:
Actual Behavior:
duration (
end - start
) is always0
. Implying thatstart
is getting erroneously mutated along the way.Expected Behavior:
duration (
end - start
) should be non zero and thatstart
should be caching the first value ofblock.timestamp
ForgeBug Contract Additional Bug
Actual Behavior:
Expected Behavior:
ForgeTest1 has an unrolled for loop version of the test included and causes correct behavior (minus duration bug)
Logs: