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
[language] Binary format changes #2718
Conversation
69ef2bf
to
59999b1
Compare
added some renaming of binary format structures: |
Hello you! It looks like MIRAI found some warnings:
|
☔ The latest upstream changes (presumably 5ada39a) made this pull request unmergeable. Please resolve the merge conflicts. |
56a1749
to
e8cea7a
Compare
preparing for |
☔ The latest upstream changes (presumably 02a898d) made this pull request unmergeable. Please resolve the merge conflicts. |
e8cea7a
to
aeeaf22
Compare
|
39daa3d
to
1faeb7b
Compare
33fc91d
to
f986259
Compare
☔ The latest upstream changes (presumably cea66f4) made this pull request unmergeable. Please resolve the merge conflicts. |
facd109
to
8a13107
Compare
8a13107
to
386587d
Compare
386587d
to
6659708
Compare
rebased on latest - after "generic script" |
6659708
to
69a14bb
Compare
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.
Haven't looked into prop tests & move prover but everything else looks good to me.
.into_iter() | ||
.flatten() | ||
.collect() | ||
fn check_module_handle(&self, module_handle: &ModuleHandle, errors: &mut Vec<VMStatus>) { |
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.
Great we're taking &mut Vec<VMStatus>
instead of returning Vec<Status>
, but I wonder if makes more sense to make the Vec<VMStatus>
a field of the BoundsChecker
?
(This is minor, we can deal with it later.)
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.
it's possible and it's something to look into.
Those mutable vectors passed all around don't really help with understanding of the code and I think you are right that there may be better ways to organize this code
#[cfg_attr(any(test, feature = "fuzzing"), proptest(no_params))] | ||
pub struct StructDefInstantiation { | ||
pub def: StructDefinitionIndex, | ||
pub type_parameters: SignatureIndex, |
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'll trust your judgement then. Could you add a few comments here just to make sure we don't forget? Thanks!
// if there are locals check that the type parameters in local signature are in bounds. | ||
let locals = match &self.module.signatures.get(code_unit.locals.into_index()) { | ||
Some(locals) => &locals.0, | ||
None => return, // stop now |
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 is unreachable since we already checked that code_unit.locals
was in bound.
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.
right and we don't want to crash because it's on entry and I changed and, in fact, crashed the test :)
There is a conversation to have about what guarantees you can rely on but it may have a lot of implications...
I hope we can talk about what guarantees should the code have and when at some point soon, but most likely not too soon
for module_handle in &self.module.module_handles { | ||
self.check_module_handle(module_handle, &mut errors); | ||
} | ||
for struct_handle in &self.module.struct_handles { | ||
self.check_struct_handle(struct_handle, &mut errors); | ||
} | ||
for function_handle in &self.module.function_handles { | ||
self.check_function_handle(function_handle, &mut errors); | ||
} | ||
for field_handle in &self.module.field_handles { | ||
self.check_field_handle(field_handle, &mut errors); | ||
} | ||
for struct_instantiation in &self.module.struct_def_instantiations { | ||
self.check_struct_instantiation(struct_instantiation, &mut errors); | ||
} | ||
for function_instantiation in &self.module.function_instantiations { | ||
self.check_function_instantiation(function_instantiation, &mut errors); | ||
} | ||
for field_instantiation in &self.module.field_instantiations { | ||
self.check_field_instantiation(field_instantiation, &mut errors); | ||
} | ||
for struct_def in &self.module.struct_defs { | ||
self.check_struct_def(struct_def, &mut errors); | ||
} | ||
for function_def in &self.module.function_defs { | ||
self.check_function_def(function_def, &mut errors); | ||
} | ||
errors |
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 like this approach! Struct indices and type parameters are checked in separate phases, which simplifies a lot of things.
It would be better if you could document what properties are checked at what time here. It was unclear to me whether everything had been covered initially.
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.
yes I will do it and we both should do it for different parts as we "finish" them.
I'm glad that you see the simplification too, I think we could do better and plan to work on this and much more as soon as this PR lands.
At that point I plan to add a bit of documentation which is critical in terms of "specification" and testing
@@ -22,6 +25,17 @@ pub struct TypedAbstractValue { | |||
pub value: AbstractValue, | |||
} | |||
|
|||
impl TypedAbstractValue { | |||
pub fn reference_to(&self, type_sig: &SignatureToken) -> bool { |
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.
Nit: reference_to
=> is_reference_to
to make it consistent with other helper functions?
@wrwg @junkil-park could you please help look at the Move Prover failure? It doesn't look like an actual error to me. Wondering if updating the baseline will fix it. |
69a14bb
to
45fe473
Compare
yeah I am in contact with the Move Prover side and things are all good and something they know about, thanks for pinging people though |
☔ The latest upstream changes (presumably c2f473e) made this pull request unmergeable. Please resolve the merge conflicts. |
Great. I assume that implies landing won't be blocked by the move prover test failure. |
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.
Overall this looks good to me. Let's check this in and move forward. We'll see if there are other minor changes to make as we revisit each of the components.
Here are the changes to the binary format. We have few things missing around Scripts vs Modules and around functions (native function flags and function signatures). However this works and it's the bulk of the binary changes. There is more to clean up and correct but this needs to go in asap and we can all iterate over
45fe473
to
1104adf
Compare
@bors-libra r=vgao1996 |
📌 Commit 1104adf has been approved by |
Cluster Test Result
Repro cmd:
|
☀️ Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow |
Here are the changes to the binary format. We have few things missing around Scripts vs Modules and around functions (native function flags and function signatures).
However this works and it's the bulk of the changes.
There is more to clean up and correct but this needs to go in asap and we can all iterate over