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

Better error message for unsupported kwargs in function calls #2798

Merged
merged 8 commits into from
Apr 20, 2022

Conversation

tserg
Copy link
Collaborator

@tserg tserg commented Apr 16, 2022

What I did

Fix for #2525

How I did it

Throw an ArgumentException error during validation of kwargs other than gas, value and skip_contract_check.

How to verify it

See tests.

Commit message

Better error message for unsupported kwargs in function calls.

Description for the changelog

Better error message for unsupported kwargs in function calls.

Cute Animal Picture

Put a link to a cute animal picture inside the parenthesis-->

@codecov-commenter
Copy link

codecov-commenter commented Apr 16, 2022

Codecov Report

Merging #2798 (433068d) into master (47cbc8e) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #2798      +/-   ##
==========================================
+ Coverage   87.46%   87.51%   +0.04%     
==========================================
  Files          93       94       +1     
  Lines        9960    10007      +47     
  Branches     2471     2480       +9     
==========================================
+ Hits         8712     8758      +46     
- Misses        782      783       +1     
  Partials      466      466              
Impacted Files Coverage Δ
vyper/semantics/types/function.py 87.10% <100.00%> (+0.99%) ⬆️
vyper/__init__.py 76.47% <0.00%> (-5.35%) ⬇️
vyper/semantics/validation/module.py 86.59% <0.00%> (-0.39%) ⬇️
vyper/cli/vyper_serve.py 0.00% <0.00%> (ø)
vyper/semantics/validation/levenshtein_utils.py 92.00% <0.00%> (ø)
vyper/semantics/validation/utils.py 91.30% <0.00%> (+0.07%) ⬆️
vyper/semantics/namespace.py 96.96% <0.00%> (+0.09%) ⬆️
vyper/semantics/types/bases.py 84.02% <0.00%> (+0.16%) ⬆️
vyper/semantics/types/utils.py 88.33% <0.00%> (+0.19%) ⬆️
... and 2 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 47cbc8e...433068d. Read the comment docs.

@tserg tserg marked this pull request as ready for review April 16, 2022 16:05
validate_expected_type(kwarg.arg, kwarg.value)
raise ArgumentException(
(
"Usage of kwarg in Vyper is restricted to gas=, "
Copy link
Member

@charles-cooper charles-cooper Apr 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this error message is a big improvement. without complicating the code too much, can we make it even better with a suggestion? would be good to see something like

vyper.exceptions.ArgumentException: Usage of kwarg in Vyper is restricted to gas=, value= and skip_contract_check=.
(hint: Try removing the kwarg: `Foo(msg.sender).foo(1, 2)`)
  contract "tmp/foo.vy", function "foo", line 9:28 
       8 def foo():
  ---> 9     Foo(msg.sender).foo(1, y=2)
  -----------------------------------^
      10

@tserg
Copy link
Collaborator Author

tserg commented Apr 18, 2022

Using regex to generate the suggestion is not perfect in this case:

@internal
def _foo(x: uint256, y: decimal=1.0) -> uint256:
    return x

@external
def foo(x: uint256, y: uint256):
    y = self._foo(x, y = self._foo(y, x))
ArgumentException: Usage of kwarg in Vyper is restricted to gas=, value= and skip_contract_check=. 
(hint: Try removing the kwarg: `self._foo(x, self._foo(y, x))`)
  contract "contracts/kwarg.vy", function "foo", line 12:21 
       11 def foo(x: uint256, y: uint256):
  ---> 12     y = self._foo(x, y = self._foo(y, x))
  -----------------------------^
       1

The suggestion should be y = self._foo(x, self._foo(y, x)), but I think it still offers some guidance?

@@ -469,7 +470,23 @@ def fetch_call_return(self, node: vy_ast.Call) -> Optional[BaseTypeDefinition]:
if not isinstance(kwarg.value, vy_ast.NameConstant):
raise InvalidType("skip_contract_check must be literal bool", kwarg.value)
else:
validate_expected_type(kwarg.arg, kwarg.value)
kwarg_pattern = fr"{kwarg.arg}\s*=\s*{re.escape(kwarg.value.node_source_code)}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add a comment explaining what we are trying to do here

@@ -469,7 +470,23 @@ def fetch_call_return(self, node: vy_ast.Call) -> Optional[BaseTypeDefinition]:
if not isinstance(kwarg.value, vy_ast.NameConstant):
raise InvalidType("skip_contract_check must be literal bool", kwarg.value)
else:
validate_expected_type(kwarg.arg, kwarg.value)
kwarg_pattern = fr"{kwarg.arg}\s*=\s*{re.escape(kwarg.value.node_source_code)}"
modified_line = re.sub(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't generally like regexes for this kind of thing, they are like hand grenades in that their behavior is hard to predict. but as this seems to work even in edge cases - i'll allow it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. I think an alternative is to create a copy of the AST node, modify it (moving the kwarg node from keywords to args), and then generate the source code from the modified AST node. However, this would require some sort of pretty print function for each node type.

Copy link
Member

@charles-cooper charles-cooper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, please add the requested comment and then can merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants