Bug 192190 - Add first-class support for .mjs files in jsc binary
Summary: Add first-class support for .mjs files in jsc binary
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Dean Jackson
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-11-29 15:10 PST by Mathias Bynens
Modified: 2018-11-30 17:22 PST (History)
10 users (show)

See Also:


Attachments
Patch (2.53 KB, patch)
2018-11-30 10:00 PST, Dean Jackson
keith_miller: review+
ews-watchlist: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews100 for mac-sierra (2.48 MB, application/zip)
2018-11-30 12:28 PST, EWS Watchlist
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mathias Bynens 2018-11-29 15:10:36 PST
jsc should treat files with the .mjs extension as modules instead of classic scripts, even when the --module-file=foo flag is not used.

This would make it more convenient to run the same JavaScript modules a) in a browser, b) in Node.js (which currently requires .mjs), and c) in JS engine shells directly such as `jsc`.

FWIW, V8’s `d8` supports this: https://bugs.chromium.org/p/v8/issues/detail?id=7950
Comment 1 Radar WebKit Bug Importer 2018-11-30 09:55:22 PST
<rdar://problem/46375715>
Comment 2 Dean Jackson 2018-11-30 10:00:22 PST
Created attachment 356189 [details]
Patch
Comment 3 Keith Miller 2018-11-30 11:07:45 PST
Comment on attachment 356189 [details]
Patch

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

r=me with fix.

> Source/JavaScriptCore/jsc.cpp:2577
> +static int isMJSFile(char *filename)

This should return a bool.
Comment 4 Mathias Bynens 2018-11-30 11:14:25 PST
This change can be tested by saving the following JavaScript program as both `module.mjs` and as `script.js`:

    console.log(this === undefined ? 'strict' : 'sloppy');

Then, run these files in `jsc` without passing `--module-file=…`. The expected output is:

    $ jsc module.mjs
    strict

    $ jsc script.js
    sloppy
Comment 5 Mathias Bynens 2018-11-30 11:14:52 PST
s/console.log/print/
Comment 6 EWS Watchlist 2018-11-30 12:28:35 PST
Comment on attachment 356189 [details]
Patch

Attachment 356189 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/10217540

New failing tests:
workers/bomb.html
Comment 7 EWS Watchlist 2018-11-30 12:28:37 PST
Created attachment 356219 [details]
Archive of layout-test-results from ews100 for mac-sierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-sierra  Platform: Mac OS X 10.12.6
Comment 8 Dean Jackson 2018-11-30 13:56:06 PST
Committed r238753: <https://trac.webkit.org/changeset/238753>
Comment 9 Ross Kirsling 2018-11-30 16:32:41 PST
This broke Windows builds, for the reason indicated by EWS.
Comment 10 Ross Kirsling 2018-11-30 16:51:30 PST
Oops, couldn't land my fix quickly enough.
It appears that bug 180009 established a precedent of using `equalLettersIgnoringASCIICase` instead of `!strcasecmp`.
Comment 11 Dean Jackson 2018-11-30 17:18:27 PST
(In reply to Ross Kirsling from comment #10)
> Oops, couldn't land my fix quickly enough.
> It appears that bug 180009 established a precedent of using
> `equalLettersIgnoringASCIICase` instead of `!strcasecmp`.

I stuck with old skool C because the rest of the file is using dumb C strings. This might cause issues on Windows or case-sensitive file systems if the files are .MJS.
Comment 12 Dean Jackson 2018-11-30 17:19:33 PST
I don't understand the iOS Sim WK2 Release tests crashes:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation      	0x000000010f752842 CFStringLowercase + 34
1   libWebCoreTestSupport.dylib   	0x0000000684958585 WebCoreTestSupport::convertWebResourceDataToString(__CFDictionary*) + 101 (WebArchiveDumpSupport.mm:88)
2   libWebCoreTestSupport.dylib   	0x0000000684957b59 WebCoreTestSupport::createXMLStringFromWebArchiveData(__CFData const*) + 2761
3   com.apple.WebKitTestRunner.InjectedBundle	0x000000068480e5a6 WTR::InjectedBundlePage::dumpDOMAsWebArchive(OpaqueWKBundleFrame const*, WTF::StringBuilder&) + 68
4   com.apple.WebKitTestRunner.InjectedBundle	0x000000068480e7c8 WTR::InjectedBundlePage::dump() + 476
5   com.apple.WebKitTestRunner.InjectedBundle	0x000000068482097a WTR::TestRunner::notifyDone() + 52
6   com.apple.WebKitTestRunner.InjectedBundle	0x000000068481a30a WTR::JSTestRunner::notifyDone(OpaqueJSContext const*, OpaqueJSValue*, OpaqueJSValue*, unsigned long, OpaqueJSValue const* const*, OpaqueJSValue const**) + 30
7   JavaScriptCore                	0x0000000672ce90ff long long JSC::APICallbackFunction::call<JSC::JSCallbackFunction>(JSC::ExecState*) + 495 (APICallbackFunction.h:63)
8   ???                           	0x000000d2761c502d 0 + 903924699181
9   JavaScriptCore                	0x0000000672cbbab1 llint_entry + 62110
10  JavaScriptCore                	0x0000000672cac659 vmEntryToJavaScript + 200
11  JavaScriptCore                	0x0000000673096a59 JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::ExecState*, JSC::JSObject*) + 11081 (Interpreter.cpp:832)


This change was just to the jsc binary. Does WKTR call "jsc"?
Comment 13 Dean Jackson 2018-11-30 17:22:53 PST
Oh. That's from yesterday's change :)