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
The algorithm for run a host function
uses ReturnIfAbrupt ([=?=]) when calling the underlying JS function (meaning it can just return the completion record), or otherwise returns the result value(s) converted with ToWebAssemblyValue. But 'create a host function' just treats its result value as a completion record when it asserts that the type is normal or throw and returns result.Value. Maybe 'run a host function' should just convert the JS results to WebAssembly values as it does now and put them back into result.Value, and return the whole completion record.
I noticed this while while working on WebAssembly/exception-handling#301 which changes some of this code. We could just fix the issue there, which would simplify merging the EH proposal into the spec. Or we could fix it in both places.
The text was updated successfully, but these errors were encountered:
dschuff
changed the title
[JS API]
[JS API] 'run a host function' and 'create a host function' don't consistently handle completion records
Apr 9, 2024
Agree that some clarification could be helpful here. Generally outside of JS and prose that interfaces with it closely, notably when using WebIDL, we use the infra convention. Not sure where we might switch between the conventions.
The algorithm for run a host function
uses
ReturnIfAbrupt
([=?=]
) when calling the underlying JS function (meaning it can just return the completion record), or otherwise returns the result value(s) converted withToWebAssemblyValue
. But 'create a host function' just treats its result value as a completion record when it asserts that the type isnormal
orthrow
and returnsresult.Value
. Maybe 'run a host function' should just convert the JS results to WebAssembly values as it does now and put them back intoresult.Value
, and return the whole completion record.I noticed this while while working on WebAssembly/exception-handling#301 which changes some of this code. We could just fix the issue there, which would simplify merging the EH proposal into the spec. Or we could fix it in both places.
The text was updated successfully, but these errors were encountered: