feat(cheatcodes): random* cheatcodes to aid in symbolic testing #8882
Conversation
grandizzy
changed the title
grandizzy
force-pushed
the
issue-4072-cont
branch
from
11a628a
to
c33ae3f
Compare
grandizzy
force-pushed
the
issue-4072-cont
branch
from
0cb30eb
to
f62e7e7
Compare
grandizzy
requested review from
DaniPopes,
klkvr and
mattsse
as code owners
crates/cheatcodes/spec/src/vm.rs
Outdated
| function randomUint(uint256 min, uint256 max) external returns (uint256); | ||
|
|
||
| /// Returns a random `address`. | ||
| #[cheatcode(group = Utilities)] | ||
| /// `randomAddress` is being deprecated in favor of `arbitraryAddress`. It will be removed in future versions | ||
| #[cheatcode(group = Utilities, status = Deprecated(Some("replaced by `arbitraryAddress`")))] | ||
| function randomAddress() external returns (address); |
There was a problem hiding this comment.
Do we need to deprecate these? I like random more
There was a problem hiding this comment.
Yeah, there were some discussions re how to name these, per @ehildenb
random would be a bit weird to use for symbolic execution, fresh or abitrary would be better
and we already added setArbitraryStorage instead setRandomStorage (see #8807 (comment))
There was a problem hiding this comment.
These are not specific to symbolic execution
There was a problem hiding this comment.
Agree, @ehildenb is ok to stick with random per Dani point?
There was a problem hiding this comment.
renamed from arbitrary to random in 6820df6, we can discuss further namings but should be OK to stick with random for now
There was a problem hiding this comment.
Sorry for the delayed reply. I still would prefer fresh or arbitrary. The point of this change is to allow Foundry property tests to either be interpreted existentially (with random sampling), or universally (with symbolic execution). So I guess to me, the point is that fresh and arbitrary are neither specific to fuzzing nor symbolic execution (and work for both), and that's a bonus because it means the same test can be interpreted in both ways.
But we'll be fine with random, it just means the tests will read a bit funny for symbolic execution, where we'll have to tell users "random is interpreted differently here, as a fresh logical variable".
- add fn rng back - make sure cheats for uint/int/bytes doesn't panic + added tests
Co-authored-by: DaniPopes <[email protected]>
grandizzy
changed the title
the initial intent was to move bound logic in strategy and reuse uint / int strategies (hence having same logic for edge values and potentially fuzz from state as well) but probably better to reduce scope of this PR (and use plain rng) and follow up with another one, would this work? |
|
If we have custom strategies sure, but as of right now these just wrap rand rng with a lot of extra steps for nothing |
kk, will bring them in when needed |
@DaniPopes Can you suggest a nice way to generate random Uint/Int with given number of bits without using strategies baked in logic? |
|
We can reuse those, that's fine; I mean stuff like bytes and bool are simply functions on rng so we should just use those |
grandizzy
force-pushed
the
issue-4072-cont
branch
from
e5ece74
to
0a56dfc
Compare
Motivation
Re #4072 : add
random*cheatcodesSolution
randomUint(bits),randomInt()andrandomInt(bits),randomBool()andrandomBytes(len)cheatcodesrandomBytes(len)ensures returned byte array is of given length