You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This post is prompted by WebAssembly/function-references#44 (comment), where it is observed that the current EH design will make it impossible for compilers to pull instructions out into a separate function without necessarily invalidating the original function (meaning that functions cannot be decomposed into smaller functions). Please refer to that comment for more details.
I labeled this is a discussion, not an issue, because it is not an action item. It is merely something for y'all to ponder as you consider how to address issues like the above (if you choose to address them at all).
Wasm Design
Function/block/instruction types are extended to include an optional (throws type*) clause. This clause essentially indicates the function has a secondary non-trapping return path (though engines are free to implement it instead using zero-cost EH techniques like stack marking and stack walking). To clarify: there can only be at most one such clause.
The instruction sequence (catches $label) instr* end jumps to $label whenever any values are "thrown" during the execution of instr*. The throws type of instr* must be a subtype of the label type of $label. That is, it has type [ti*] -> [to*] provided $label has type [t*] and instr* has type [ti*] -> [to*] (throws t*).
An instruction throw n is added, which "throws" the top n instructions on the stack. It has type [t1 ... tn] -> unreachable (throws t1 ... tn). To clarify: there is no event. In fact, this design has no events whatsoever; every throw is always caught by the most immediately enclosing catches, making events unnecessary (and the type system ensures this is sound).
JS API
The JS API for existing function types is left unchanged. In particular, if a JS function is imported as a wasm function whose type has no throws clause, then exceptions thrown by that JS function are modelled as traps.
If a JS function is imported as a wasm function whose type has a throws t* clause, then any exception thrown by the JS function is converted to t*—akin to how JS values are converted to result types—and thrown as a (wasm) exception.
If a wasm function whose type has a throws t* clause is exported as a JS function, then any exception thrown by the wasm function is converted from t*—akin to how JS values are converted from result types—and thrown as a (JS) exception.
The text was updated successfully, but these errors were encountered:
This post is prompted by WebAssembly/function-references#44 (comment), where it is observed that the current EH design will make it impossible for compilers to pull instructions out into a separate function without necessarily invalidating the original function (meaning that functions cannot be decomposed into smaller functions). Please refer to that comment for more details.
I labeled this is a discussion, not an issue, because it is not an action item. It is merely something for y'all to ponder as you consider how to address issues like the above (if you choose to address them at all).
Wasm Design
Function/block/instruction types are extended to include an optional
(throws type*)
clause. This clause essentially indicates the function has a secondary non-trapping return path (though engines are free to implement it instead using zero-cost EH techniques like stack marking and stack walking). To clarify: there can only be at most one such clause.The instruction sequence
(catches $label) instr* end
jumps to$label
whenever any values are "thrown" during the execution ofinstr*
. Thethrows
type ofinstr*
must be a subtype of the label type of$label
. That is, it has type[ti*] -> [to*]
provided$label
has type[t*]
andinstr*
has type[ti*] -> [to*] (throws t*)
.An instruction
throw n
is added, which "throws" the topn
instructions on the stack. It has type[t1 ... tn] -> unreachable (throws t1 ... tn)
. To clarify: there is no event. In fact, this design has no events whatsoever; everythrow
is always caught by the most immediately enclosingcatches
, making events unnecessary (and the type system ensures this is sound).JS API
The JS API for existing function types is left unchanged. In particular, if a JS function is imported as a wasm function whose type has no
throws
clause, then exceptions thrown by that JS function are modelled as traps.If a JS function is imported as a wasm function whose type has a
throws t*
clause, then any exception thrown by the JS function is converted tot*
—akin to how JS values are converted toresult
types—and thrown as a (wasm) exception.If a wasm function whose type has a
throws t*
clause is exported as a JS function, then any exception thrown by the wasm function is converted fromt*
—akin to how JS values are converted fromresult
types—and thrown as a (JS) exception.The text was updated successfully, but these errors were encountered: