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

add support for send builtin #2212

Merged
merged 1 commit into from
Mar 22, 2024
Merged

add support for send builtin #2212

merged 1 commit into from
Mar 22, 2024

Conversation

0xalpharush
Copy link
Member

@0xalpharush 0xalpharush commented Nov 1, 2023

closes #2190

@0xalpharush 0xalpharush marked this pull request as ready for review November 6, 2023 02:36
@montyly
Copy link
Member

montyly commented Nov 7, 2023

I think we should convert send to our IR (LowLevel call?) instead of having a specific function

@0xalpharush
Copy link
Member Author

0xalpharush commented Nov 7, 2023

This is converting to the same operation that solidity is:

contract C {
    function f() public {
        payable(msg.sender).send(address(this).balance);
    }
}
        Function C.f() (*)
                Expression: address(msg.sender).send(address(this).balance)
                IRs:
                        TMP_0 = CONVERT msg.sender to address
                        TMP_1 = CONVERT this to address
                        TMP_2(uint256) = SOLIDITY_CALL balance(address)(TMP_1)
                        TMP_3 = SEND dest:TMP_0 value:TMP_2

Did you mean to change this for both Solidity and Vyper?

@@ -114,6 +114,7 @@
"_abi_encode()": [],
"slice()": [],
"uint2str()": ["string"],
"send()": [],
Copy link
Member

Choose a reason for hiding this comment

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

This part is telling me that we are doing something off:

  • On the solidity side, we parse the send as a high level call (
    def convert_to_low_level(
    )
  • but on vyper we use a solidity variable as a placeholder to parse them

It sounds to me that we are creating a disparity in the way we handle these type of operations between solidity and vyper, which will likely create issues in the long term

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

I explained that in the comment. There may be another way, but raw_call and send are use this same codepath since we create a MemberAccess which is then converted to a HighLevelCall in extract_tmp_call

msgcall = HighLevelCall(

Copy link
Member Author

Choose a reason for hiding this comment

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

In vyper the builtin are Call unliked Solidity where they are FunctionCall(MemberAccess...) The use of SolidityFunction allows us to know we are dealing with builtins to special case here. I guess we could add a LowLevelCallExpression that is only used by Vyper and add new code to support it in the IR conversion step

if isinstance(called, Identifier) and isinstance(called.value, SolidityFunction):

@0xalpharush 0xalpharush merged commit b5993c3 into dev Mar 22, 2024
83 checks passed
@0xalpharush 0xalpharush deleted the fix-vyper-send branch March 22, 2024 20:15
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.

None yet

2 participants