-
Notifications
You must be signed in to change notification settings - Fork 639
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
actually call near-vm when using VMKind::NearVm #8886
Conversation
multi_memory: WASM_FEATURES.multi_memory, | ||
memory64: WASM_FEATURES.memory64, | ||
exceptions: WASM_FEATURES.exceptions, | ||
mutable_global: true, | ||
saturating_float_to_int: true, | ||
sign_extension: true, |
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 went over this before, but double-checking these ideally happens before we roll something out (you mentioned believing these should be true, I still haven't double checked it, though.)
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.
Got it! We don’t have the protocol change yet and I’ll be asking you for review on it before we roll anything out; I’ll try to remember reminding you that this needs the double-check before we land it :)
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.
(basically, my recollection of my checking that these need to be true is more along the lines of "tests wouldn’t pass without these to true" than a spec-based checking; which made sense to me as we want to keep the same behavior, but we should also spec-based check as you mention)
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 message seems to confirm that these were on-by-default in previous versions of wasmparser: bytecodealliance/wasm-tools#482
@@ -533,59 +533,144 @@ impl Wasmer2VM { | |||
} | |||
} | |||
|
|||
impl wasmer_vm::Tunables for &Wasmer2VM { | |||
impl near_vm_vm::Tunables for &NearVmVM { |
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.
Similarly for this module.
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.
So this is a separate crate, that was copy-pasted from wasmer_vm ; if we rename it it’ll collide with the main near_vm crate (that was copy-pasted from the wasmer crate).
So yes, but it’ll have to wait until we merge the near-vm crates all together, as the crate split doesn’t make much sense for us
This closes up the near-vm work. I believe #8886 (comment) is the only remaining point to be checked in former PRs, in addition to all the code added in this PR. Note that there are still things in #8323 that are not in this PR, because either I noticed they actually should not be merged (eg. the wasmparser bump would be a protocol upgrade, so will wait until we get limited replayability), or because they are actually orthogonal to this landing.
* actually call near-vm when using VMKind::NearVm * handle review comments * cargo fmt
This closes up the near-vm work. I believe #8886 (comment) is the only remaining point to be checked in former PRs, in addition to all the code added in this PR. Note that there are still things in #8323 that are not in this PR, because either I noticed they actually should not be merged (eg. the wasmparser bump would be a protocol upgrade, so will wait until we get limited replayability), or because they are actually orthogonal to this landing.
These are not currently supported and any decision to enable them should be a intentional decision, not an accidental one. Overall these changes are no-op since the deserialization will fail earlier when trying to deserialize with pwasm deserializer, but if and when we eventually get rid of it, it would be nice if these extensions didn't accidentally get enabled. This puts to rest the question raised in #8886 (comment).
This closes up the near-vm work. I believe #8886 (comment) is the only remaining point to be checked in former PRs, in addition to all the code added in this PR. Note that there are still things in #8323 that are not in this PR, because either I noticed they actually should not be merged (eg. the wasmparser bump would be a protocol upgrade, so will wait until we get limited replayability), or because they are actually orthogonal to this landing.
These are not currently supported and any decision to enable them should be a intentional decision, not an accidental one. Overall these changes are no-op since the deserialization will fail earlier when trying to deserialize with pwasm deserializer, but if and when we eventually get rid of it, it would be nice if these extensions didn't accidentally get enabled. This puts to rest the question raised in #8886 (comment).
* actually call near-vm when using VMKind::NearVm * handle review comments * cargo fmt
This closes up the near-vm work. I believe #8886 (comment) is the only remaining point to be checked in former PRs, in addition to all the code added in this PR. Note that there are still things in #8323 that are not in this PR, because either I noticed they actually should not be merged (eg. the wasmparser bump would be a protocol upgrade, so will wait until we get limited replayability), or because they are actually orthogonal to this landing.
These are not currently supported and any decision to enable them should be a intentional decision, not an accidental one. Overall these changes are no-op since the deserialization will fail earlier when trying to deserialize with pwasm deserializer, but if and when we eventually get rid of it, it would be nice if these extensions didn't accidentally get enabled. This puts to rest the question raised in #8886 (comment).
No description provided.