Bug 165805 - WebAssembly API: implement WebAssembly.LinkError
Summary: WebAssembly API: implement WebAssembly.LinkError
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: JF Bastien
URL:
Keywords: InRadar
Depends on:
Blocks: 159775 166199 166295
  Show dependency treegraph
 
Reported: 2016-12-13 10:01 PST by JF Bastien
Modified: 2016-12-20 15:55 PST (History)
5 users (show)

See Also:


Attachments
patch (60.55 KB, patch)
2016-12-19 22:47 PST, JF Bastien
mark.lam: review+
mark.lam: commit-queue-
Details | Formatted Diff | Diff
patch (62.18 KB, patch)
2016-12-20 11:44 PST, JF Bastien
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description JF Bastien 2016-12-13 10:01:59 PST
Added in https://github.com/WebAssembly/design/pull/901
Comment 1 Radar WebKit Bug Importer 2016-12-19 20:56:23 PST
<rdar://problem/29747874>
Comment 2 JF Bastien 2016-12-19 22:47:31 PST
Created attachment 297510 [details]
patch

Most of this patch is boilerplate for a new JS object, copied as-is from the CompileError code and modified with sed.

I noted the interesting changes in the ChangeLog, but they're not that interesting either:
 - Change error types thrown in instance construction and module linking.
 - Update tests accordingly.

Overall, a good late-day patch: we need to do this, and it's brainless.
Comment 3 Mark Lam 2016-12-20 09:23:29 PST
Comment on attachment 297510 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=297510&action=review

r=me with fixes.

> Source/JavaScriptCore/wasm/js/JSWebAssemblyLinkError.cpp:55
> +JSObject* createWebAssemblyLinkError(ExecState* exec, const String& message)
> +{
> +    ASSERT(!message.isEmpty());
> +    JSGlobalObject* globalObject = exec->lexicalGlobalObject();
> +    return ErrorInstance::create(exec, globalObject->vm(), globalObject->WebAssemblyLinkErrorStructure(), message, defaultSourceAppender, TypeNothing, true);

This is weird.  The function name suggests that we're creating an WebAssemblyLinkError, but we're invoking the ErrorInstance factory instead of the JSWebAssemblyLinkError factory above.  Am I missing something?  Do we really need the JSWebAssemblyLinkError class?

I think the error here is that you're constructing an instance of ErrorInstance instead of JSWebAssemblyLinkError.

nit: I also recommend passing a VM& in as one of the arguments so that we don't have to recompute it.  We already know the VM& at all call sites below (except fro one ... but I'll provide details on how to address that one below).

> Source/JavaScriptCore/wasm/js/WebAssemblyLinkErrorConstructor.cpp:53
> +    RETURN_IF_EXCEPTION(scope, { });

This is wrong (and also wrong in the other places).  { } invokes the default constructor for int64_t which is not the same as the JSValue::encode(JSValue()).  What you want here is:
     RETURN_IF_EXCEPTION(scope, encodedJSValue());

> Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp:201
> +    return throwException(state, scope, createWebAssemblyLinkError(state, makeString(ASCIILiteral("Invalid data segment initialization: segment of "), String::number(segmentSize), ASCIILiteral(" bytes memory of "), String::number(memorySize), ASCIILiteral(" bytes, at offset "), String::number(offset), args...)));

if you do change createWebAssemblyLinkError() to take a VM&, you can get VM& from scope.vm().
Comment 4 JF Bastien 2016-12-20 11:44:20 PST
Created attachment 297542 [details]
patch

Address comments. I'll do follow-up patches to address similar issues (encoded value, error construction, VM) elsewhere in the wasm codebase. Thanks for pointing those out!
Comment 5 WebKit Commit Bot 2016-12-20 12:20:46 PST
Comment on attachment 297542 [details]
patch

Clearing flags on attachment: 297542

Committed r210028: <http://trac.webkit.org/changeset/210028>
Comment 6 WebKit Commit Bot 2016-12-20 12:20:51 PST
All reviewed patches have been landed.  Closing bug.