feat(cheatcodes): Make expectEmit only work for the next call

[Evalir]

This is a big breaking change.

Partially closes #1745. expectCall is left and needs #4912 to be merged before it can be reworked to support this.

Makes expectEmit only work for the immediate next call after the cheatcode has been called.

Behavior

expectEmit remains additive. Calling expectEmit N times will set a lower bound of N events that must be seen for the cheatcode to pass successfully.

The current behavior of expectEmit allows to:

• declare the cheatcode before all events are emitted.
• "fill" the expected emits before the test ends.
• match events after the tests ends.

The intended behavior is that it only works for the next immediate call. This new behavior only allows to:

• Call the cheatcode AND fill the expected emit right after calling the cheatcode. Declaring the cheatcode N times and then filling N events will fail.
• match events after the next CALL is triggered. Events not triggered by a call will be ignored. Events nested in the triggered CALL subtree will be matched. If the events defined are not matched, the execution will revert.

It's important to note the restriction imposed by this, namely that after the cheatcode is declared, no CALLs other than the one the cheatcode is intended to "match" must happen. This means that #1214 is now illegal behavior. Specifically, this means that this is now illegal:

function testEmitMyEvent_v2() external {
    cheatcodes.expectEmit(true, true, true, true);
    // myContract.myVar() is a call made after the cheatcode was called. This is illegal.
    // To fix this, move the call to before the cheatcode and use a variable.
    emit MyEvent(myContract.myVar(), address(this), address(this), block.timestamp);
    myContract.emitMyEvent();
}

Why are now expect emits being pushed without subtracting 1 from the depth?

#1215 is a great read to reason about depth. After this, the reason is that currently, depth - 1 is being used is so that expectEmit checks the events after the call that invoked the cheatcode ends. However, we now wanna check the events after the next CALL (which will have more depth) ends, which means that we need to check for depth, not depth - 1.

When we're happy with this and merge it we should definitely prepare a telegram message & a tweetstorm for this change, as this might confuse people.

[mattsse]

Code-wise this looks good, but defer to @mds1 if this is the intended behavior now

[mds1]

This means that #1214 is now illegal behavior. Specifically, this means that this is now illegal:

function testEmitMyEvent_v2() external {
    cheatcodes.expectEmit(true, true, true, true);
    // myContract.myVar() is a call made after the cheatcode was called. This is illegal.
    // To fix this, move the call to before the cheatcode and use a variable.
    emit MyEvent(myContract.myVar(), address(this), address(this), block.timestamp);
    myContract.emitMyEvent();
}

Is this change required if myContract.myVar() is a staticcall? You cannot emit events in staticcalls / view methods, so perhaps they should be ignored automatically? Similar to how staticcalls are ignored when you're in a startBroadcast context

Aside from that this seems great and I agree with this behavior. This is a decent sizes breaking change though, and since we may have some other breaking changes, perhaps we should start feature flagging them? We could just check the value of CARGO_PKG_VERSION_MAJOR to disable certain features if that value is < 1, then delete the old code after v1 is released?

Will defer to you all on if we should do that or not. Either way we should maintain somewhere a list of the recent breaking changes we can continually point people to. Could be a changelog file, discussion in the repo, or a meta-issue

[Evalir]

Is this change required if myContract.myVar() is a staticcall? You cannot emit events in staticcalls / view methods, so perhaps they should be ignored automatically? Similar to how staticcalls are ignored when you're in a startBroadcast` context

Great point—I'll push a modification so we ignore STATICCALLs, it's an easy one.

On the feature flagging, that's a great idea, and i'm not too opposed to it (my only grip is obviously just the need to keep extra code for some more time/having to modify stuff to keep the old behavior working). Very curious on what @gakonst / @mattsse think about this

[Evalir]

Also, I believe this behavior will also break some forge-std tests (some seem to be failing), so we might need to follow up there

[Evalir]

@mds1 great catch on forge-std—i had missed this. With 420d814 we now have this behavior (will also update the main description):

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

expectEmit will be able to match ranges with and without skipping events in between:

• [A, B, C] is valid.
• [B, D, F] is valid.
• [G] or any other single event combination is valid.
• [B, A] or similar out-of-order combinations are invalid (events must be in order).
• [C, F, F] is valid.
• [F, F, C] is invalid (out of order).

Which means we should be able to test forge-std with this change and not need to change it

[mattsse]

smol nit, otherwise this looks sounds.

tests look good.

[mattsse]

this is the same as if state.expected_emits.iter().all(|expected| expected.found), right?

[Evalir]

yep indeed

[Evalir]

done in d72a935 , waiting for ci

[bowd]

Unless I'm missing something, there's one case that's impossible to fully cover with the given syntax:
Say we have a function on ContractA that calls ContractB which emits EventB and then ContractA emits EventA.
We can't ensure that events originate from the contract we intend. I can do:

vm.expectEmit(true, true, true, true);
emit EventB(...);
emit EventA(...);
contractA.example();

But this would match irrespective of which contract emitted the events. This isn't allowed:

vm.expectEmit(true, true, true, true, address(contractB));
emit EventB(...);
vm.expectEmit(true, true, true, true, address(contractA));
emit EventA(...);

So essentially if I understand correctly, you can only match the contract address if you don't intend to match any other events emitted by other contracts. Also, you can't mix and match matcher configs. For example, if you want to match data on one event but not match it on another you can't do that. This also can introduce some weird situations where if you want to match data on one event you have to compute/simulate all data values for other events.

[mds1]

@bowd can you open a separate issue so we can track this more easily? Your example seems like it should work to me so if it's currently not supported we can discuss in that issue with @Evalir