feat: add `vm.clearTransient`

Component

Forge

Describe the feature you would like

In solc version 0.8.24, transactions compose differently than message calls. While adding support for solc 0.8.24 (issue #6903) I think that it will be useful with a cheat code to clear the transient storage, so that we can model transactions with message calls.

For example a cheat code function clearTransientStorage(address) to zero the transient storage. This cheat code can be used to model a transaction a.f(x) with

vm.clearTransientStorage(address(a));
a.f(x);
vm.clearTransientStorage(address(a));

and transaction composition of a.f(x) and a.g(y) can be modeled with

vm.clearTransientStorage(address(a));
a.f(x);
vm.clearTransientStorage(address(a));
a.g(y);
vm.clearTransientStorage(address(a));

Additional context

No response

I think the transient storage context should be split by default for each top-level call in the Foundry test runner.

Also, I would like transient storage to be cleared when explicitly switching the runtime context using prank etc.

Hello, was this implemented?

Through this comment, I learned that running tests with the --isolate option allows the top-level call to be executed as a context-independent tx.

@andreas-blockswap does running in --isolate mode meet your requirement?

I think this is still useful, otherwise you are forced to use the whole test suite in isolated to get it to pass in CI? or have some hacks where transient tests get filtered with --mt --mc and both of them be separately ran instead of just a single forge test command in the CI. Is there anyway to clear transient storage atm without this new cheatcode?

What about using inline config to specify specific tests that run in isolate mode, this way a single forge test invocation can be used? I am unsure if this is currently supported, but @0xdapper I think this would address your feedback without needing to add a new cheatcode, and should be safer since you don't have to remember to add calls to a cheat

Nice, yeah, I am in favour of this approach too, inline is not supported atm but can be easily added

Yes, the inline config would address it. But I still think vm.clearTransient, vm.tstore, vm.tload are all useful cheats. Inline would still be more restrictive in the sense that it is all or nothing, and you would need additional hacks like making external self calls(this.performSomethingWithoutContextChange) while with vm.clearTransient you would control when you want to clear. Maybe it is not a useful general pattern but that could potentially be highlighted in the docs that --isolate might normally the preferred way to test things if you are looking to test some transient state functions?

ref https://github.com/foundry-rs/foundry/issues/5371