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

Functions, Exception: ("Can't return type %s as part of tuple", <class 'vyper.types.types.ListType'>) #955

Closed
ehanoc opened this issue Jul 16, 2018 · 5 comments · Fixed by #1838
Labels
bug Bug that shouldn't change language semantics when fixed. enhancement

Comments

@ehanoc
Copy link
Contributor

ehanoc commented Jul 16, 2018

I'm working on a sample game to demonstrate some proof of concepts. Including, showing both versions of the contract (Solidity & Vyper) so i can show a comparison of building and usage.

What's your issue about?

I'm trying to convert a solidity contract into Vyper.

Can't seem to return the same bag of values.

For the following vyper function :

@public
@constant
def getStoryNode(id: uint256) -> (uint256, bytes[256], bytes[256], address, uint256[256]):
    return (self.stories_nodes[id].id, self.stories_nodes[id].title, self.stories_nodes[id].body, self.stories_nodes[id].owner, self.stories_nodes[id].childNodesIds)

I get the following error when compiling the contract:
Exception: ("Can't return type %s as part of tuple", <class 'vyper.types.types.ListType'>)

Solidity Version :

  /**
  * Returns node's id, title, body, owner's address
  */
  function getStoryNode(uint id) public view returns(uint, string, string, address, uint[]) {
      StoryNode storage node = storiesNodes[id];
      return (node.id, node.title, node.body, node.owner, node.childNodesIds);
  }

How can it be fixed?

Can stmt.py::parse_return be improved to handle this? Maybe i can do do this myself and submit PR.

Extra related questions:

Unless i missed something in the docs... strings & dynamically sized mappings aren't a thing, right?

Cute Animal Picture

lmgsz8bj28a11

@jacqueswww
Copy link
Contributor

jacqueswww commented Jul 16, 2018

As long as it's a fixed size list this should be do-able yes. 👍 Tagging as a bug.

@jacqueswww jacqueswww added the bug Bug that shouldn't change language semantics when fixed. label Jul 16, 2018
@jacqueswww
Copy link
Contributor

@ehanoc could you please test this again, I believe this has been fixed with additional tuple work.

@ehanoc
Copy link
Contributor Author

ehanoc commented Feb 18, 2019

@jacqueswww I wrote a couple small tests to check.

The string vs bytes[] fixes the issues with string types.

Although there could be an issue with int [] as part of the tuple.

@public
def foo() -> (uint256, uint256[2]):
    return (0, [0, 1])

Output:

            else:
                # Maybe this should panic because the type error should be
                # caught at an earlier type-checking stage.
>               raise TypeMismatchException("Can't return type %s as part of tuple" % arg.typ, stmt)
E               vyper.exceptions.TypeMismatchException: line 15: Can't return type int128[2] as part of tuple
E                   return (0, [0, 1])
E               ----^

vyper/parser/parser_utils.py:681: TypeMismatchException

Is this an issue? I might be missing something

@jacqueswww
Copy link
Contributor

Thanks for testing, will have a look ;)

@jacqueswww
Copy link
Contributor

Related to #1019.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug that shouldn't change language semantics when fixed. enhancement
Projects
None yet
2 participants