Abicoder reports invalid type when library ABI contains enums

[cameel]

What was wrong?

Abicoder fails to properly parse/use the ABI generated by solc for a library. One example of this is that for contracts the type of an enum is reported as an integer type (uint8 if enum has 256 of less entries) while for libraries it's enum L.E (where L is a library name and E is some enum).

An attempt to use such an enum results in an error:

UnhandledPromiseRejectionWarning: Error: invalid type (argument="type", value="L.E", code=INVALID_ARGUMENT, version=abi/5.0.7)

Code that produced the error

This assumes that you have solc, npm and node in your PATH.
Just run these commands in a shell in an empty directory:

cat << EOF > L.sol
library L {
    enum BOOL {NO, YES}

    function f(BOOL b) public pure returns (BOOL) {
        return b;
    }
}
EOF

solc --abi L.sol | tail --lines 1 > L-abi.json

npm install ethers

node << EOF
const ethers     = require('ethers');
const fs         = require('fs')
const address    = '0x74a9a20f67d5499b62255bfa1dca195d06aa4617';
const privateKey = '0x3ab6468f2465130c51946a5456b8e2d309be7af2f8afcd6823996d281c0990d0';
const wallet     = new ethers.Wallet(privateKey);
const abi        = JSON.parse(fs.readFileSync('L-abi.json'))
const contract   = new ethers.Contract(address, abi, wallet)

contract.f(1)
EOF

Full error output

(node:303402) UnhandledPromiseRejectionWarning: Error: invalid type (argument="type", value="L.BOOL", code=INVALID_ARGUMENT, version=abi/5.0.7)
    at Logger.makeError (/tmp/node_modules/@ethersproject/logger/lib/index.js:179:21)
    at Logger.throwError (/tmp/node_modules/@ethersproject/logger/lib/index.js:188:20)
    at Logger.throwArgumentError (/tmp/node_modules/@ethersproject/logger/lib/index.js:191:21)
    at AbiCoder._getCoder (/tmp/node_modules/@ethersproject/abi/lib/abi-coder.js:66:23)
    at /tmp/node_modules/@ethersproject/abi/lib/abi-coder.js:83:63
    at Array.map (<anonymous>)
    at AbiCoder.encode (/tmp/node_modules/@ethersproject/abi/lib/abi-coder.js:83:28)
    at Interface._encodeParams (/tmp/node_modules/@ethersproject/abi/lib/interface.js:238:31)
    at Interface.encodeFunctionData (/tmp/node_modules/@ethersproject/abi/lib/interface.js:261:18)
    at /tmp/node_modules/@ethersproject/contracts/lib/index.js:186:47
(node:303402) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:303402) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.```

Environment

• ethers@5.0.19
• npm 6.14.7
• node.js v10.22.1
• solc 0.7.4
• OS: linux

How can it be fixed?

The inconsistent ABI for libraries is actually a problem in the compiler and is likely to be fixed in the near future (feedback welcome in ethereum/solidity#9278). It affects other tools too: dethcrypto/TypeChain#216, ethereum/eth-abi#146.

In the meantime (and for older versions when it's fixed), tools need to handle it differently than in contracts.

[ricmoo]

I don’t know it’s even possible to extract this from an ABI fragment. Can you include the generated ABI in this issue?

[cameel]

Sure. Here's what I get from solc 0.7.4 (passed through jq for readability):

[
    {
        "inputs": [
            {
                "internalType": "enum L.BOOL",
                "name": "b",
                "type": "L.BOOL"
            }
        ],
        "name": "f",
        "outputs": [
            {
                "internalType": "enum L.BOOL",
                "name": "",
                "type": "L.BOOL"
            }
        ],
        "stateMutability": "pure",
        "type": "function"
    }
]

[ricmoo]

Yeah. That is literally not enough data to process. :)

[cameel]

Yeah. This will probably have to be fixed in the compiler. Still I wanted to make you aware of this issue since it won't disappear in older compiler versions and knowing about it might save you some needless debugging down the line. And it likely affects more than just enums. You might also want to detect it and at least handle the error gracefully.