meta: new cheatcodes and cheatcode enhancements

[mds1]

Component

Forge

Describe the feature you would like

Aggregating a list of new cheatcodes and improvements to existing cheatcodes that have been requested in other issues:

• 1. vm.not cheat code. When called immediately before (or after?) expectEmit or expectCall it modifies that cheat code so the event/call is expected not to be present. Alternatively, expectNoEmit or expectNoCall would work. feat(cheatcodes): add negative assertions for expectEmit and expectRevert using count syntax #509
• 2. Allow expectEmit to be declared after the call emitting the event, instead of the current workflow which requires it to be declared before. If we have to choose only allowing it to be declared before or after, my preference would be after, because it allows you to read updated state from the call and use those values as the event args, as explained in inline / asymmetric matchers #512 (comment)
• 3. Update mockCall, expectCall, and expectRevert (and expectEmit?) to work for JUMPs (currently they only work for calls). This has been discussed in bug: mockCall not working as expected #432 and expectRevert cheat code doesn't work for internal calls #864
• 4. When an expectEmit matcher fails, specify which topics or data did not match: feat(cheatcodes): specify mis-matched fields on expectEmit failure #592
• 5. Some expectEmit issues described in Issues with expectEmit with mismatched topics and low level call #760
• 6. Still needs more discussion to determine if cheatcodes is the optimal approach, but I think cheatcodes for setting fuzzer params on a per-contract or per-test basis would be very useful: Configuring fuzzer parameters per test and per contract #744
• 7. Nonce cheatcodes: feat: getNonce and setNonce cheatcodes #554
• 8. captureLogs and getLogs cheatcodes (similar to records and accesses) to support getting values of emitted events #543
• 9. vm.roll should update how RPC queries behave when forking: When testing against a fork, vm.roll does not change RPC query block #939
• 10. expectEmit error message: misleading error message on failed expectEmit cheat code #908
• 11. expectRevert with no bytes to assert that any revert should happen: vm.expectRevert should support an empty signature to catch reverts with no message #885
• 12. Needs discussion/decision, but requiring expectEmit/expectCall to only check the next call, and not all subsequent calls: bug: expectEmit and expectCall don't only check the next call #1745
• 13. Some expect* edge cases / bugs? Forge doesn't work with multiple "vm.expectRevert" when testing free functions #3723 (comment)

Additional context

No response

[onbjerg]

Another issue we should investigate (not sure if it makes sense): #824

Quality of life issues:

• expectEmit error message: misleading error message on failed expectEmit cheat code #908
• expectRevert with no bytes to assert that any revert should happen: vm.expectRevert should support an empty signature to catch reverts with no message #885

[brockelmore]

9. we should just overload roll to add a bool whether to update fork block number

[mds1]

we should just overload roll to add a bool whether to update fork block number

Ah yea I like that, more flexibility than a flag that applies to the full test suite 👌

[onbjerg]

• vm.skip Function Modifier or an Opcode to mark a test as skipped conditionally #1123 (although might not be needed with test matchers in config)

[0xmikko]

Please, add expectNoCall and expectNoEmit to check that no calls or events were done.
No we have to develop bicyclesto cover such problems

[Van0k]

expectNoCall and expectNoEmit are sorely needed.
Also, while this is not strictly about cheatCodes, parametrizable setUp() for fuzzed deployment would be really useful.

[onbjerg]

Please open up issues regarding all of the features listed above so we can track them separetely

[adhusson]

Another nice addition would be expectRevert(bytes,string) where the string is an error message displayed if the next call does not revert.

[mds1]

Closing this tracking issue in favor of #4439