Improve implementation - perhaps with debug_traceTransaction

Given that Truffle 4 is now in beta, and comes with a snazzy debugger that we can (in theory) crib notes from, it seems like a good moment to start a discussion along these lines.

On the surface, it seems like doing no instrumentation at all and using debug_traceTransaction alongside the demonstrated methodology in the truffle debugger would save a lot of headaches that instrumentation can otherwise cause.

The obvious downside to this approach would be that we would no longer be able to trace lines of code executed with an eth_call, which would limit the maximum coverage we could display to a number below 100%. We could, however, exclude functions labelled with pure and view (formerly known as constant), though they can still obviously be called by transactions that change blockchain state, and so not showing them as covered might be confusing.

I’m considering this a blue-skies issue for now, so I’m open to suggestions, however far-fetched they might seem. I’ll kick it off:

• Create our own fork of solidity and etheruemjs-vm, and introduce another opcode for our coverage events that cost no gas.
• Integrate something like the solidity debugger with sourcemaps etc. into the ethereumjs-vm, so that it ‘knows’ what code it is executing and keeps track of it.

[onbjerg]

Yep, you can just use the step event instead. That approach is actually a bit cleaner.

You don’t need to use testrpc, you can use ganache-core directly by using it’s provider method and passing that to the truffle config instead. This method also accepts options, one of which is actually the VM, if you want to roll your own. It shouldn’t be needed though, since this hook works if you’re using ganache-core directly (which is what testrpc is using).

[onbjerg]

Great, thanks! I’ll look at it this weekend if I have time, I’m in the process of moving 🚚