Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uniswap V1 ABI "duplicate output parameter "out" in function removeLiquidity" error thrown #816

Closed
kamescg opened this issue May 3, 2020 · 7 comments
Labels
enhancement New feature or improvement.

Comments

@kamescg
Copy link

kamescg commented May 3, 2020

When using ethers@v5 and loading the Uniswap V1 ABI I get "duplicate output parameter "out" in function removeLiquidity" error thrown.

ABI Culprit

{
    "name": "removeLiquidity",
    "outputs": [
      { "type": "uint256", "name": "out" },
      { "type": "uint256", "name": "out" }
    ],
    "inputs": [
      { "type": "uint256", "name": "amount" },
      { "type": "uint256", "name": "min_eth" },
      { "type": "uint256", "name": "min_tokens" },
      { "type": "uint256", "name": "deadline" }
    ],
    "constant": false,
    "payable": false,
    "type": "function",
    "gas": 116814
  },

Not sure if I should report this error here, because it seems like a Uniswap problem when Vyper compiles the ABI, but seeing as it's unlikely to change, I thought it would be worth reporting because Uniswap is obviously super popular and people are going to use the generated ABI when V5 gets released.

Reference to the Vyper Smart Contract

https://github.com/Uniswap/uniswap-v1/blob/master/contracts/uniswap_exchange.vy#L83

@ricmoo
Copy link
Member

ricmoo commented May 3, 2020

Yeah, that is definitely an ABI error. Otherwise, what should result.out refer to. :)

It's a good question what to do. It should certainly be a bug logged against Uniswap and possibly Vyper? Do you know if that is what Vyper injected, or whether Uniswap edited the ABI after it was dumped?

Someone posted an ABI cleaner script yesterday, perhaps I should post something similar and include cleaning output parameter names in the cookbook?

@ricmoo ricmoo added the discussion Questions, feedback and general information. label May 3, 2020
@kamescg
Copy link
Author

kamescg commented May 4, 2020

Just ran the compiler on the contracts. Same output.

Could do out1 and out2 or spice it up with outBetter and outBetterer 😂

I guess I'll just report on the Uniswap contracts? Don't know any Vyper, so not sure how to rename the outputs on the following function?

def removeLiquidity(amount: uint256, min_eth: uint256(wei), min_tokens: uint256, deadline: timestamp) -> (uint256(wei), uint256):

@ricmoo
Copy link
Member

ricmoo commented May 4, 2020

Yeah, I was chatting with the Vyper peeps. Sounds like they are willing to make output names unique. But obviously that doesn’t help existing ABI.

But I will probably make it so if output names collide, they are available positionally only, and not by name. If they are unique, of course everything will work fine, positionally and named. :)

I’ll get to this tomorrow. :)

@ricmoo ricmoo added enhancement New feature or improvement. next version (v5) on-deck This Enhancement or Bug is currently being worked on. and removed discussion Questions, feedback and general information. labels May 4, 2020
@ricmoo
Copy link
Member

ricmoo commented May 13, 2020

I was told that the dev version of Vyper no longer outputs names for outputs now.

Also, the fix I've put in place is a bit more forgiving. It simply drops names (internally; they are still available on the Fragment for inspection). So, if encoding, it will not allow named values if the name is ambiguous and for decoding it will not expose it by name if the name is ambiguous.

So, something like this (uint256 foo, uint256 foo, uint256 bar) with the values 1, 2, 3 would be the Result object [ 1, 2, 3, bar: 3 ]. Since foo is ambiguous, no foo is exported, but bar is safe so it is available positionally (i.e. result[2]) and by name (i.e. result.bar), while the two foo's are only available positionally (i.e. result[0], result[1]).

I think that should make everyone happy? Or as happy as is safe to make everyone?

@ricmoo
Copy link
Member

ricmoo commented May 13, 2020

This has been added to 5.0.0-beta.187. Try it out and let me know if you still have any problems. :)

@ricmoo ricmoo removed the on-deck This Enhancement or Bug is currently being worked on. label May 13, 2020
@kamescg
Copy link
Author

kamescg commented May 13, 2020

Awesome! Will test it this week when I get chance to circle back around to repo.

@ricmoo
Copy link
Member

ricmoo commented May 14, 2020

Coolio. I'll close this now then, but if you still have any problem, please re-open.

Thanks! :)

@ricmoo ricmoo closed this as completed May 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improvement.
Projects
None yet
Development

No branches or pull requests

2 participants