-
Notifications
You must be signed in to change notification settings - Fork 11
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
Verify numeric instructions #37
base: master
Are you sure you want to change the base?
Conversation
@zixuanzh CI is failing because you need to run |
type Pop = Vec<ValueType>; | ||
type Push = Vec<ValueType>; | ||
|
||
struct Signature { |
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.
Can you document these structs with triple-slash comments? That way rustdoc
can automatically generate a docs site for 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.
@zixuanzh @Steampunkery please document the code.
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.
push: Push | ||
} | ||
|
||
pub enum Filter { |
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.
Perhaps it would be useful to have per-instruction granularity here?
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.
Per instruction granularity would be a tricky/impossible thing to implement because you need to simulate an entire stack to know if the right data types will be on that stack at the right time. If you mean just simulating a stack and filtering out certain instructions, then yes, I could do that.
for signature_value in &signature.pop { | ||
let value = self.stack.pop(); | ||
match value { | ||
Some(stack_value) => { |
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 is a matter of preference but I find it cleaner, in the case of destructuring two-valued enums like Option
, to use the if let Some(stack_value)
pattern here.
@zixuanzh CI seems to be a version behind on edit: actually that doesn't seem to be the problem. trying to find out why fmt is still freaking out. edit 2: Are you sure you are using the correct version? |
c451588
to
ad30d14
Compare
I am running on 1.32.0-nightly, fmt fails at deployer.rs etc in CI, it passes CI when I only commit verify-instructions related files. |
@zixuanzh is this ready or WIP? Please add the respective label. Also please rebase. |
ad30d14
to
93e2c7f
Compare
@jakelang it should be ready as it is unless @Steampunkery has something to add, we don't have access to add labels. |
@@ -35,6 +40,10 @@ pub trait ModuleValidator { | |||
fn validate(&self, module: &Module) -> Result<bool, ModuleError>; | |||
} | |||
|
|||
pub trait InstructionValidator { | |||
fn validate(&mut self, module: &Module) -> Result<bool, InstructionError>; |
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 think since we have ModuleError
, it should be possible to merge the InstructionError
enum into it and thus removing the need for a new trait.
I think this looks good in general, great work @Steampunkery and @zixuanzh! |
InvalidOperation(Instruction), | ||
} | ||
|
||
impl fmt::Display for InstructionError { |
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.
If we merge ModuleError
and InstructionError
, could you create a new PR which just adds the Display
and Error
traits on ModuleError
? Then this PR can just extend that with the new enum values.
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.
Alternatively, instead of adding new variants, it may make sense to just encode these errors as a string in the Custom
variant of ModuleError
.
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.
Or make Custom(T)
type generic and throw InstructionError
in there.
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.
Text in general is fine, but for programmatic detection the enums are better.
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'd like to stick to enum variants if possible, and I can certainly look into merging InstructionError
into ModuleError
.
} | ||
|
||
#[cfg(test)] | ||
mod tests { |
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.
Needs moar unit tests
@Steampunkery @zixuanzh can we take over this PR or do you think you'll have some resources to work on this in the next while? |
@axic please proceed, we are unlikely to work on this in the immediate future. thanks |
93e2c7f
to
df99108
Compare
As per issue #18
parity-wasm checks types for const operators but not for binary as specified in the spec.
We simulated the stack to check for types and hence we added a new validator interface that takes in a mutable self reference. We also use a self defined enum instead of String for error handling and propagation as advised by the documentation.