-
Notifications
You must be signed in to change notification settings - Fork 451
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
Support for trapping #41
Comments
An exception seems perfectly adequate. We can either just use the existing Error.error for that, or, if we care about distinguishing expected from unexpected runtime errors, introduce a new Eval.Trap exception. |
It'd also be nice to add a new |
Given use of ML exceptions and ability to test with |
Forgot to remove these previously.
* Update Overview.md for element segments Passive element segments now include an element type, and have a sequence of expressions instead of function indices.
Clarify the relationship between the original proposal and Layer 1
[test] Add more tests for multi-memory
…mbly#41) This patch fixes the failing type check that would sometimes occur when storing a continuation reference in a table. The solution: remove the type check. We cannot recover the type of a continuation reference without tracing block types in the interpreter.
As suggested in WebAssembly/relaxed-simd#17 (comment).
AstSemantics.md has the concept of a trap, which means
Several operators are defined to trap, such as integer division when the denominator is zero. What's the best way to represent this in OCaml? Would an exception be appropriate?
In the future, trapping behavior may be made customizable, though I don't think it's necessary to try to anticipate this in the current code.
The text was updated successfully, but these errors were encountered: