guybedford
commented
10 months ago Here's my best shot at formal trap semantics:
- We make
WebAssembly.RuntimeErrorthe formal trap error, and update all bindgen-level validation functions to throwWebAssembly.RuntimeErroras opposed to genericError,TypeErrororRangeError. - When calling an imported function that does not return a result, any error is treated as a trap, and we rewrap that error in a
WebAssembly.RuntimeErrorif it is not already aWebAssembly.RuntimeError(possibly with acauseproperty pointing to the original JS error). - If calling an imported function that returns a result, we strictly verify that the error is not an instance of
WebAssembly.RuntimeError. If it is, then we rethrow the runtime error as a trap error. - At all places we detect a runtime error, we immediately mark the component as trapped, similarly to the mayenter state, which should also be checked on all calls already.
- All WASI errors that are traps in the JS implementation should be thrown as
WebAssembly.RuntimeErroras well.
Even if we don't get to the full trap handling right now, at the very least we can start to formalize WebAssembly.RuntimeError checks as the primary mechanism where traps are being initiated and caught already currently.
We should be stricter about traps in jco.
When a component traps it moves into a trapped state and is no longer callable, so this should be a flagged state of the component.
All call validation errors should also be traps as well, trickling up and setting the trapped flag on call calling components.
In the case or exported function validation errors, these do not need to trap as they happen before entering the component.