fix(StdAssertions): Expect all events to be emitted, without omitting the first one

[Evalir]

This change stems from foundry-rs/foundry#4920 — It will fail if we ignore the first emit of these assertions, as it expects to strictly match all events performed in the next call and its subtree.

[mds1]

Sorry not sure I totally follow this change—it sounds like we'll need to expectEmit for all events emitted in a call and it's subcalls now, and you can't only expect e.g. the third event?

[Evalir]

That is correct! That's the behavior foundry-rs/foundry#4920 will create. We could make it so that we match the "specified sequence of events" in between all events emitted in a call, but this felt like it could make for confusing behavior.

Further clarifying what i mean with "specified sequence of events":

A function emits events A, B, C, D, E, F, G.

With the PR, the cheatcode will be able to match, let's say, from A to D. It cannot start from B. If we wanted to match [D,E,F,G] this would be impossible, but we can make it so it's possible to ignore the events preceding that range.

[mds1]

Hmm IIUC isn't this a big devex burden then? For example, let's say I have a fork test where the contract I'm developing locally, MyContract will execute a trade on uniswap and will emit MyContractSwapWorked() on a successful swap. In my tests, I can no longer just vm.expectEmit() for emit MyContractSwapWorked() and instead need to also expect all token transfer events, etc?

[Evalir]

Yeah you're right. I think that then we should make it so that what you're saying is possible—shouldn't be a big change nevertheless.

[mds1]

Awesome, yea that would be much better IMO. Thanks!

[Evalir]

Closing—not needed anymore