Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[move-vm][closures] Type and Value representation and serialization #15670
base: main
Are you sure you want to change the base?
[move-vm][closures] Type and Value representation and serialization #15670
Changes from 5 commits
94627e3
140dce0
fad9573
10b1041
41baffe
b3eebaf
7fe820f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vgao1996 can you look at gas related aspects?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change seems unneeded? Maybe affected by rebase?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Captured layouts will not be annotated, right? Inconsistent with other printing, we might want to revisit this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest avoid formatting unless there's a certain ask?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should revisit this in practice. I don't want to omit information in the first step, its not breaking to change this later, I think we can use this only in tests? In any case, I put the generic bug here for revisiting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to return an error here instead of doing this?
get_serialization_data
is also not cheap for resolved functions with all conversions, I do not see a value of printing partial information + we should be charging gas here like we do for structs. If we want to keep it in tests, let's put it undercfg(test)
etc, and otherwise return an error, e.g.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought a bit more about this, and want to keep this.
Many typically use cases of capturing, for example
f(@0xcafe, _)
, will be printing fine. Only field names are omitted. All experience in debugging tells me we would only create frustration for users if we omitting something here.The experience to see closures printed by function name plus undecorated captured values will be also all over our ecosystem.
MoveValue
which is used outside of the VM does the same, the JSON representation is the same. It is not realistic for those parts of the code to look up the function for the full types, so I think we also need not to do this here.Regards gas, this does exactly the same as for structs. For the structs, layout is constructed in the native top-level call without gas charge, then elements are visisted and each single one is charged. For closures the lookup for layout maybe just a bit delayed, otherwise the charge is the same. Layout is the only relevant cost for
get_serialization_data
because other info is already there. No code will be loaded for unresolved closures.