Truffle does not support function overloading

[facuspagnuolo]

• I've asked for help in the Truffle Gitter before filing this issue.

---

Issue

Truffle fails with a Error: Invalid number of arguments to Solidity function error when testing an overloaded function.

Steps to Reproduce

1. Checkout this branch
2. Enable transfer and call test cases
3. Run npm test

Expected Behavior

Tests should pass.
You can see that those tests work fine by changing the name of the overloaded function and using that name in the mentioned test cases.

Actual Results

Tests fail with a Error: Invalid number of arguments to Solidity function error

Environment

• Operating System: Mac OS Sierra
• Truffle version: 4.0.1
• Ethereum client: testrpc
• node version: 8.4.0
• npm version: 5.5.1

[nachomazzara]

I'm getting the same issue +1

[etherwaifu]

I got hit by the same bug as shown above. Workaround that works in Truffle 4.1.5:

await instance.contract.functionName['argType1', 'argType2'](arg1, arg2);

For instance, because await contract.tokenMetadata(i) fails, I can instead use await contract.contract.tokenMetadata['uint256'](i)

[kunalb16]

Facing the same issue, When would this be fixed? Any timeline?

[vrogojin]

@etherwaifu Your solution does not work for me. It says TypeError: contract.function[(("address" , "address") , "uint256")] is not a function. No idea why it has grouped ("address" , "address") together, even though I defined it as ['address','address','uint256']. Looks like, the only solution here, I need to have different names for the functions :(

[ghost]

Yeah, calling overloaded functions in truffle seems to be borked...

I changed from async/await:

let tx = await instance.announceDividend(_nShares,_timestampWithdrawOpened,{from: accounts[0], value: _dividendAmount})

        // then
        truffleAssert.eventEmitted(tx, 'LogAnnounce', (ev) => {
          //console.log(ev)
          ...

back to:

instance.announceDividend(_nShares,_timestampWithdrawOpened,{from: accounts[0], value: _dividendAmount})
        .then(function(a,b){
          console.log(a)
          console.log(b)
        })

and it was OK...

Apparently the truffle fork (Neufund/truffle-contract@ecae099) works? (haven't tried)

I even tried:

npm install --save trufflesuite/truffle#develop (didn't work...)

So, my solution is to use plain old JavaScript and abandon async/await syntax for now.

[cgewecke]

@hynese This should be fixed on truffle's nightly for the next major version (darq-truffle on npm) which you can get by running:

npm install -g darq-truffle@next
darq-truffle migrate --network ropsten # Example command

It uses web3 1.0 under the hood so there are some breaking changes. Usage notes here.

(If you try this feel free to ping with any problems, would love some early feedback on whether things are working in a production context).

[q3yi]

@vrogojin The workaround given by @etherwaifu for multiple arguments is incorrect and is not work for either. After debugging the code, I found that instance.contract.functionName is an object, the key of the object is the string of arguments type concatenate by the comma, so the right solution would be await instance.contract.functionName['argType1,argType2'](arg1, arg2);.

[rotcivegaf]

In the meantime you can use web3.eth.sendTransaction and web3.eth.call to send your transactions
In example, you have this functions in a contract:
function foo (uint256 x) external view returns (uint256) { return x; }
function foo2 (uint256 x, uint256 y) external view returns (uint256) { return x + y; }
get foo its easy... but for get foo2 you can calculate the signature, in this case:
const fooSignature = web3.utils.soliditySha3( { t: 'string', v: 'foo(uint256,uint256)' })
and finally call the function

const xPlusY = await web3.eth.call({
    to: myContract,
    data: fooSignature.slice(0, 10) + Web3.padLeft(x, 64).slice(2) + Web3.padLeft(y, 64).slice(2),
});

[gnidan]

This is resolved via the myContract.methods mechanism in Truffle v5! Thank you!

[tjanson]

I think it could still fail better: If I understand correctly, the first declared overload is used when you invoke myContract.someMethod, while the other overloads are only accessible in other ways.

Then there’s some code that (heuristically?) determines wether some of the arguments are DefaultBlockParameters (I’m sorry I don’t remember the name), and pops them from the args array.
As a result, the error may say something like "passed 3 arguments, expected 2", when in fact you passed 4.

Yes, if you’re already aware of how accessing the overloaded methods work, such errors are easy to understand. But if you assume that overloaded functions just work, you’re going to have to fire up a debugger. I’m not saying this is a bug, just a usability issue that I imagine many people will run into.

Maybe just add a hint about overloaded functions in the error message text?

[k06a]

@gnidan we need more details

[tjanson]

@k06a see “Overloaded Solidity functions” in the 5.0 release notes

[gnidan]

@k06a do those docs help you?

I'm having trouble making sense of what might be actionable here. Could someone write up some proposals for better error handling/reporting?

Thanks!

[k06a]

@gnidan yep, doc was helpful enough

[stevenlcf]

Just for your information, there are also some function overloading bugs in solidity compiler, which is about payable and non-payable functions with same names. You can find more details here: ethereum/solidity#526

I thought it was a truffle bug at first and followed this issue. But after wandering around for a while, I finally found out that it was a bug of solidity compiler. So I post it here and hope it can help others who may have the same issues of me.

[mktcode]

I didn't read the whole thread here but for me this is still not really fixed.

We passed an object as the third parameter to sendCoin. Note that the sendCoin function in our Solidity contract doesn't have a third parameter.

How is this supposed to work with function overloading? I have a method in two versions, with 2 parameters and with 3 parameters. If I use the version with 2 parameters in truffle console, then it actually tries to execute the version with 3 parameters.
Can't you simply check if the last parameter really IS an object holding the eth transaction parameters... value, from, etc?

[elenadimitrova]

Not fixed for us too, trying to call a function with 1 parameter of type address calls an overload of the function with parameter address[].

[elenadimitrova]

Can this be reopened please, this is not fixed. A fresh example is a failing build here erroring on register(string,address,bytes) being called but register(string,address) being recognised. Overloaded function signatures below:

function register(string calldata _label, address _owner, bytes calldata _managerSignature)
function register(string calldata _label, address _owner)

On top of that the error message is bad as it seems to be counting as parameter the ,{from: x, gas: y} parameters passed into the function.
Error: Invalid number of parameters for "register". Got 4 expected 2! <= there are 2 overloads with 2 and 3 parameters and none with 4

And more specifically, using the syntax contract.methods["register(string,address,bytes)"](label, owner, managerSig,{ from: accounts[7] }) still produces Error: Invalid number of parameters for "register". Got 4 expected 3!

UPDATE: This is what works but feels too clumsy to be a proper solution

const data = await ensManager.contract.methods["register(string,address,bytes)"](label, owner, "0x").encodeABI();
await ensManager.sendTransaction({ data, from: accounts[7] });

[eggplantzzz]

Just a note: we are currently working on a rewrite of Truffle contract that should fix this.

[caffeinum]

I think it's fixed in Truffle v5:

Closing this, as Truffle v4 basically had no support for overloaded functions. This is now resolved in Truffle v5. Please see the v5 release notes about overloaded functions. Thanks!

Originally posted by @gnidan in #569 (comment)

[eggplantzzz]

Ah so it looks like this is fixed, can we close this issue?

[haltman-at]

So, the original issue of not having any overloading support has been fixed, but our overloading support still has significant limitations, leading to many of the comments above. That's why this issue has been left open; but perhaps instead we should close it and open a new one?

[eggplantzzz]

I vote we close and open a new one (or several).

[haltman-at]

OK, closing this in favor of #5061.