feat(coverage): library support

[onbjerg]

Motivation

Adds coverage support for libraries, of which there are two types:

• Libraries with external functions boil down to delegatecall operations from the user of the library
• Libraries with internal functions have their functions inlined/are called via a jump instruction

Of course some libraries may be a mix.

For the first type of libraries, we were already kind of supporting it except we needed to replace all library address placeholders with a dummy address in order to produce a valid bytecode we can analyze. This was added previously but a minor error in the implementation made it non functional.

For internal libraries we need to walk through the AST of contracts that use them and find calls to the library. This is not super trivial to do since there are many ways to use libraries - calling them directly, importing them using an alias, using using for etc.

At first I wanted to finish the strongly typed AST in ethers-rs, but I've become somewhat uncertain that it's a good idea for now since breaking changes in unrelated parts of the AST might render coverage completely unusable for new versions of Solidity, and I haven't found a good way around that yet.

Solution

• Fix the dummy link step to add coverage to libraries with external functions
• Walk through the AST to find calls to library functions for internal libraries and note down the AST node ID of the called library. Currently all of these are assumed to be in FunctionCall nodes where the expression attribute of those nodes are a MemberAccess node.

This does not currently handle cases where using for is used for internal libraries since it seems like we lose information on what libraries were bound to what types..

Ref #2567

This PR can be validated with the updated tests I've added to https://github.com/onbjerg/forge-coverage-test (or the report can be viewed here https://f3128.tiiny.site/), note that the using for test case shows up as uncovered (InternalLibrary.subPlusOne) even though it is covered (called from the contract in Contract2.sol).

[mattsse]

lgtm!

[gakonst]

@transmissions11 wanna give this a spin?

[ZeroEkkusu]

Some feedback

I wanted to make a simple contract that exposes library functions for coverage to pick up.

The following approaches do not work. The reported coverage for the library is 0%:

contract LibHelper {
    function increment(uint256 a) external returns (uint256) {
        return Lib.increment(a);
    }
}

contract LibHelper {
    function increment(uint256 a) external returns (uint256 r) {
        r = Lib.increment(a);
    }
}

This approach works:

contract LibHelper {
    function increment(uint256 a) external returns (uint256) {
        uint256 r = Lib.increment(a);
        return r;
    }
}

This also works, but is not useful in testing:

contract LibHelper {
    function increment(uint256 a) external {
        Lib.increment(a);
    }
}

[gakonst]

@onbjerg suspect we're not catching the typedef in the function sig?

[onbjerg]

I think we're just not walking the expression on the right side of an assignment

[gakonst]

Should we track this in a separate ticket for followup?

[PaulRBerg]

Should we track this in a separate ticket for followup?

Definitely. Opened an issue here:

#4305