-
Notifications
You must be signed in to change notification settings - Fork 1
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
help: foundry assertions #38
Conversation
* chore: add crytic/properties dependency * test: extend protocol properties so it also covers ToB erc20 properties * chore: small linter fixes * docs: update property list * test: handlers for remaining superc20 state transitions * fix: disable ToB properties we are not using and guide the fuzzer a bit more * fix: disable another ToB property not implemented by solady
doable since it also handles SIGINTs gracefully
I'm getting an 'unknown opcode 0x4e' in ProtocolAtomic constructor when calling the MockL2ToL2CrossDomainMessenger for the first time
this is so foundry's invariant contract can check that an assertion returned false in the handler, while still allowing `fail_on_revert = false` so we can still take full advantage of medusa's fuzzer & coverage reports
Replicating, quite wtf... |
real issue is the revert on create2 conflict happening in fuzz_DeployNewSupertoken. It seems like foundry considers the assertEq as a failing property erroneously (funny enough, the trace is correct, while the assert "summary" ( Fixed it by wrapping the create2 deployment in a try/catch (invariant then holds/test passes) - this looks like a bug tho function fuzz_DeployNewSupertoken(
TokenDeployParams memory params,
uint256 chainId
)
external
validateTokenDeployParams(params)
{
chainId = bound(chainId, 0, MAX_CHAINS - 1);
OptimismSuperchainERC20 supertoken;
try this.deploy(params, chainId) returns(OptimismSuperchainERC20 _supertoken) {
supertoken = _supertoken;
} catch {
}
// 14
compatibleAssert(supertoken.totalSupply() == 0);
}
function deploy(
TokenDeployParams memory params,
uint256 chainId
)
public
returns(OptimismSuperchainERC20)
{
return _deploySupertoken(
remoteTokens[params.remoteTokenIndex],
WORDS[params.nameIndex],
WORDS[params.symbolIndex],
DECIMALS[params.decimalsIndex],
chainId
);
} |
1760e4a
to
c40737d
Compare
thanks for your help dr! moved forward with #40 |
I'm currently having the following issue, which I cannot explain, and would like to see if you have any input or could replicate it:
context
I'm trying to make medusa tests also runnable in foundry. Due to the limitations already discussed off-repo, I can only meaningfully test as pure properties two of the 15 already tested ones
foundry test --mc MedusaAdaptoor --mt invariant_handlerAssertions
, with any combination of runs+depththis looks like a typical case of not exposing the same data internally vs externally, but the logs + traces seem to confirm that the assertion should indeed pass, but it doesn't
things I tried
assert(trackedSupply == fundsInTransit + totalSupply)
instead of DSTest'sassertEq
notes
I had to lower the depth and increase the runs number because foundry doesn't seem to be shrinking the call sequence effectively (doesn't even remove reverted calls)
running foundry
forge 0.2.0 (d28a337 2024-08-27T00:20:10.476146991Z)