feat(cheatcodes): mark unmatched expectedEmits as unemitted

[topocount]

Motivation

It can be very difficult to find a failing expectEmit when looking
as traces involving deep traces with a lot of events.

fixes #8506

Solution

If an emitted event is marked as unmatched, it can then be hilighted
as an error in red.

This is accomplished by passing the sequence index of the first event
that was expected but not emitted as a revert error, and then
finding that event during tracing and marking it as unmatched.

please see paradigmxyz/revm-inspectors#181 for
the dependent changes that allow for the actual highlighting

[klkvr]

Really like the idea! Wondering if we can also resolve #592 here by highlighting mismatched topics?

Left comments re errors enum, and I think we'd want to change event indexes tracking logic

[klkvr]

There's no need in introducing this, sol! macro in vm.rs will produce errors enum with abi_decode methods

[klkvr]

This can be just VmErrors::abi_decode(&node.trace.output, false)

[klkvr]

I think this is incorrect as sequence only knows about events which came after expectEmit which might not always be the only events emitted during execution

I think we'd want to directly use tracing inspector indexes here, which should be possible after #8696

[klkvr]

hey @topocount #8696 just got merged and CheatcodesExecutor was extended with tracing_inspector fn which provides a reference to a tracing inspector from which you can check the log indicies directly

that way sequence value can be just set to something like tracer.traces().nodes().last().expect("no trace nodes").logs.len()

[topocount]

I should have time to work on this this week

[topocount]

@klkvr I've added tracer.traces().nodes().last().expect("no trace nodes").logs.len() to expect_emit but still need the offset to cover an edge case where a prior call completes successfully, otherwise that prior call is erroneously highlighted red instead.

not_found.sequence holds the tracer length call from from when the expected emit payload is initially pushed onto the stack.

[topocount]

This comment is incorrect after my debugging outline below
hmm there are still edge cases that aren't satisfied by this, namely if multiple expectedEmits are added for a given call, the incorrect one (the one that is matched) is highlighted. I need to dig into this more.

[topocount]

it doesn't look like this is incrementing. Is this array lazily constructed then?

that way sequence value can be just set to something like tracer.traces().nodes().last().expect("no trace nodes").logs.len()

[topocount]

Here's a debug trace where we're expecting the same event twice:

Click here

[crates/cheatcodes/src/inspector.rs:1366:17] &self.expected_emits = [
    ExpectedEmit {
        depth: 1,
        log: Some(
            LogData {
                topics: [
                    0xf6ef72180c46cadbda80997bfa03fc39b76911c9bc988da15e4a47d55d687a31,
                ],
                data: 0x00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000005,
            },
        ),
        checks: [
            true,
            false,
            false,
            false,
            true,
        ],
        address: Some(
            0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f,
        ),
        anonymous: false,
        found: false,
        sequence: 0,
    },
    ExpectedEmit {
        depth: 1,
        log: Some(
            LogData {
                topics: [
                    0xf6ef72180c46cadbda80997bfa03fc39b76911c9bc988da15e4a47d55d687a31,
                ],
                data: 0x00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000005,
            },
        ),
        checks: [
            true,
            false,
            false,
            false,
            true,
        ],
        address: Some(
            0x5615deb798bb3e4dfa0139dfa1b3d433cc23b72f,
        ),
        anonymous: false,
        found: true,
        sequence: 0,
    },
]

[topocount]

I could actually add the unmatched event name to the revert error here, if that's desirable.

[zerosnacks]

Hi @topocount, would be great to get this in - let me know if you are running into any blockers / have any questions

[topocount]

@zerosnacks I've been blocked here: #8686 (comment)

I could possibly sort this out by reading through the impl that isn't behaving as expected, I just haven't had time. Can probably look back into this next week