Skip to content
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

Closed
sunfishcode opened this issue Sep 1, 2015 · 3 comments
Closed

Support for trapping #41

sunfishcode opened this issue Sep 1, 2015 · 3 comments

Comments

@sunfishcode
Copy link
Member

AstSemantics.md has the concept of a trap, which means

execution [...] is terminated and abnormal termination is reported to the outside environment.

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.

@rossberg
Copy link
Member

rossberg commented Sep 2, 2015

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.

@lukewagner
Copy link
Member

It'd also be nice to add a new (asserttrap (invoke ...)) command to test trapping behavior.

@lukewagner
Copy link
Member

Given use of ML exceptions and ability to test with assert_trap (#74, #76), I think this issue is resolved, but feel free to reopen if there is more to do here. When we specify JS<->wasm integration, we'll have to talk about how spec traps turn into JS exceptions (I assume), but I think that's outside ml-proto (it's just what the host does when Eval.invoke throws).

littledan pushed a commit to littledan/spec that referenced this issue Mar 4, 2018
eqrion pushed a commit to eqrion/wasm-spec that referenced this issue Jul 18, 2019
* Update Overview.md for element segments

Passive element segments now include an element type, and have a sequence of expressions instead of function indices.
dhil pushed a commit to dhil/webassembly-spec that referenced this issue Mar 2, 2023
Clarify the relationship between the original proposal and Layer 1
backes pushed a commit to backes/spec that referenced this issue Jul 12, 2023
dhil added a commit to dhil/webassembly-spec that referenced this issue Aug 1, 2024
…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.
rossberg pushed a commit that referenced this issue Sep 4, 2024
rossberg pushed a commit that referenced this issue Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants