abigen: Does not include all structs in binding

[yondonfu]

System information

OS & Version: OSX
Commit hash : df89233

I installed abigen by cloning go-ethereum at the above commit hash and running make devtools.

Expected behaviour

This is the relevant contract code:

pragma solidity ^0.5.11;
pragma experimental ABIEncoderV2;


contract Foo {
  struct Apple {
    uint256 a;
    uint256 b;
  }

  struct Pear {
    uint256 c;
    uint256 d;
  }

  function test() public view returns (Apple memory apple, Pear memory pear) {
    apple.a = 5;
    apple.b = 6;
    pear.c = 7;
    pear.d = 8;
  }
}

The Go binding should contain:

• A Go struct corresponding to the Solidity Apple type
• A Go struct corresponding to the Solidity Pear type
• A Test() method that returns an anonymous struct that wraps the Go struct corresponding to the Solidity Apple type and the Go struct corresponding to the Solidity Pear type

Actual behaviour

The generated Go binding contains:

• A Go struct Struct0 corresponding to the Solidity Apple type
• A Test() method that returns an anonymous struct that includes Struct0 twice

The binding is missing a Go struct corresponding to the Solidity Pear type and the anonymous struct returned by the Test() method does not contain the correct fields.

This is what the Go binding looks like in the section of the code with struct definitions and the Test() method:

// Struct0 is an auto generated low-level Go binding around an user-defined struct.
type Struct0 struct {
	A *big.Int
	B *big.Int
}

// Test is a free data retrieval call binding the contract method 0xf8a8fd6d.
//
// Solidity: function test() constant returns(Struct0 apple, Struct0 pear)
func (_Foo *FooCaller) Test(opts *bind.CallOpts) (struct {
	Apple Struct0
	Pear  Struct0
}, error) {
	ret := new(struct {
		Apple Struct0
		Pear  Struct0
	})
	out := ret
	err := _Foo.contract.Call(opts, out, "test")
	return *ret, err
}

// Test is a free data retrieval call binding the contract method 0xf8a8fd6d.
//
// Solidity: function test() constant returns(Struct0 apple, Struct0 pear)
func (_Foo *FooSession) Test() (struct {
	Apple Struct0
	Pear  Struct0
}, error) {
	return _Foo.Contract.Test(&_Foo.CallOpts)
}

// Test is a free data retrieval call binding the contract method 0xf8a8fd6d.
//
// Solidity: function test() constant returns(Struct0 apple, Struct0 pear)
func (_Foo *FooCallerSession) Test() (struct {
	Apple Struct0
	Pear  Struct0
}, error) {
	return _Foo.Contract.Test(&_Foo.CallOpts)
}

I suspect this behavior is because abigen is not able to handle the internal types introduced into tuple types of contract ABIs as of solc 0.5.11.

Steps to reproduce the behaviour

1. Compile the contract Foo.sol using solc 0.5.11 and store the ABI in Foo.json
2. Run abigen --abi Foo.json --pkg main --type Foo --out foo.go
3. Observe that the generated binding includes Struct0 that corresponds to the Solidity type Apple, but it does not include a Go struct that corresponds to the Solidity type Pear. Also, observe that the Test() method in the binding returns an anonymous struct with Struct0 nested inside twice.

[0x234]

I observe a similar issue when attempting to create bindings for https://github.com/omisego/plasma-contracts.

Solidity version: 0.5.11

abigen doesn't have a version flag or output information and I can't remember how I installed it.

abigen --abi PlasmaFramework.json --pkg PlasmaFramework > PlasmaFramework.go

Failed to generate ABI binding: .:9:11068: expected ';', found 'IDENT' compiler (and 1758 more errors)

[jeffprestes]

@yondonfu Is the ABIEncoderV2 officially supported by Solidity devs yet?

@JBunCE I think your situation is different. Are you trying to generate go file from a ABI file, am I right? I think abigen work better when your source is a Solidity file.

[yondonfu]

@jeffprestes ABIEncoderV2 is still an experimental feature and needs to be turned on via a pragma statement, but usage is becoming increasingly common. Some examples:

• Augur: https://github.com/AugurProject/augur/blob/0ce9c261320b25f128258e2b8d60a799cda34a28/packages/augur-core/source/contracts/trading/FillOrder.sol

• 0x: https://github.com/0xProject/0x-monorepo/blob/development/contracts/exchange/contracts/src/Exchange.sol

abigen works fine for contracts that use ABIEncoderV2 and solc < 0.5.11. But, as of solc 0.5.11, internal types are added to tuple types in a contract's ABI which abigen does not know how to handle yet.

[rjl493456442]

@yondonfu Basically abigen uses all abi information to generate bindings.

This is the compiler output for abi

[{
	"constant":true,
	"inputs":[],
	"name":"test",
	"outputs":[
		{
			"components":[{"name":"a","type":"uint256"},{"name":"b","type":"uint256"}],"name":"apple","type":"tuple"
		},
		{
			"components":[{"name":"c","type":"uint256"},{"name":"d","type":"uint256"}],"name":"pear","type":"tuple"
		}
	],
	"payable":false,
	"stateMutability":"pure",
	"type":"function"
}]

You can find the description of return parameter type is "components":[{"name":"a","type":"uint256"},{"name":"b","type":"uint256"}], there is no struct TYPE name in abi. So we can't distinguish Apple and Pear because in abi level, they are just SAME.

So only Struct0 is defined in binding.

[rjl493456442]

For user experience wise, maybe it's not enough since user needs to convert Struct0 to user-defined structs Apple and Pear. But we can't do more here

[yondonfu]

When compiling using solc 0.5.11, the ABI output is:

[
	{
		"constant": true,
		"inputs": [],
		"name": "test",
		"outputs": [
			{
				"components": [
					{
						"internalType": "uint256",
						"name": "a",
						"type": "uint256"
					},
					{
						"internalType": "uint256",
						"name": "b",
						"type": "uint256"
					}
				],
				"internalType": "struct Foo.Apple",
				"name": "apple",
				"type": "tuple"
			},
			{
				"components": [
					{
						"internalType": "uint256",
						"name": "c",
						"type": "uint256"
					},
					{
						"internalType": "uint256",
						"name": "d",
						"type": "uint256"
					}
				],
				"internalType": "struct Foo.Pear",
				"name": "pear",
				"type": "tuple"
			}
		],
		"payable": false,
		"stateMutability": "view",
		"type": "function"
	}
]

Since each function output now also includes the internalType field, I think it should be possible for abigen to use the value specified for that field to generate separate Go structs for the Apple and Pear Solidity types even if Apple and Pear are composed of the same elementary uint256 types.

[rjl493456442]

@yondonfu Wow, this is wonderful. Haven't tried the new version compiler before.

With internalType information, I think it's feasible to do more things. Okay I'll check the new documentation and see how much I can do here.

Thanks for the report!

[rjl493456442]

@yondonfu Could you please try #20179?

[yondonfu]

@rjl493456442 abigen built from #20179 seems to be generating named structs using the contract ABI's internalType fields!

The binding generated for the example contract Foo mentioned in the OP contains the following Go structs that correspond to the Apple and Pear Solidity structs:

type FooApple struct {
    A *big.Int
    B *big.Int
}

type FooPear struct {
    C *big.Int
    D *big.Int
}

Having struct names derived from the contract instead of Struct0, Struct1, etc is great.

[rjl493456442]

Fixed by #20179