Support weval-based ahead-of-time compilation of JavaScript.

[cfallin]

When the WEVAL option is turned on (cmake -DWEVAL=ON), this PR adds:

• Integration to the CMake machinery to fetch a PBL+weval-ified version of SpiderMonkey artifacts;
• Likewise, to fetch weval binaries;
• A rule to pre-build a compilation cache of IC bodies specific to the StarlingMonkey build, so weval can use this cache and spend time only on user-provided code on first run;
• Integration in componentize.sh.

When built with:

$ mkdir build/; cd build/
$ cmake .. -DCMAKE_BUILD_TYPE=Release -DUSE_WASM_OPT=OFF -DWEVAL=ON
$ make

We can then do:

$ build/componentize.sh file.js --aot -o file.wasm
$ wasmtime serve -S cli=y file.wasm

Using the Richards Octane benchmark adapted slightly with a main() for the HTTP server world 1, I get the following results:

%  build/componentize.sh
richards.js --aot -o weval.wasm
Componentizing richards.js into weval.wasm
[ verbose weval progress output ]

% wasmtime serve -S cli=y weval.wasm
Serving HTTP on http://0.0.0.0:8080/
stdout [0] :: Log: Richards: 676
stdout [0] :: Log: ----
stdout [0] :: Log: Score (version 9): 676

% wasmtime serve -S cli=y base.wasm
Serving HTTP on http://0.0.0.0:8080/
stdout [0] :: Log: Richards: 189
stdout [0] :: Log: ----
stdout [0] :: Log: Score (version 9): 189

[cfallin]

I believe this is now ready for review, except possibly for CI testing integration: I haven't yet added a job to run all tests with wevaling enabled. Happy to hear early feedback though (e.g.: should we require a separate --aot flag to componentize.sh?).

[guybedford]

@cfallin I've pushed two new commits here - one to enable testing the new weval option, and one to add a new CI run that tests against it. I'm getting 7/10 passes here with the failing tests as:

Integration test timers?setInterval-handler-parameter-not-callable

Which seems to be related to catching an error.

And two e2e tests when there is invalid JS syntax / a top-level error:

          3 - syntax-err (Failed)
          4 - tla-err (Failed)

where the output gets stuck on (per tests/e2e/tla-err/stderr.log):

Reading raw module bytes...

but then it doesn't actually print the expected error:

Exception while pre-initializing: (new Error("blah", "tla-err.js", 3))

We definitely need to improve the above error printing in general, we should at least ensure some error printing here.

We can also diverge the error printing between Wizer and Weval no problem, and create a separate expectation for Weval, happy to help with that too.

[cfallin]

Thanks @guybedford! At least the expected-output failure above is due to weval's progress-output verbosity; I can silence that by default. I'll look into the setInterval failure as well.

[cfallin]

I've got all integration tests passing locally with the changes in bytecodealliance/spidermonkey-wasi-embedding#19 (and a weval update pushed here); there are three review-merge-rebase cycles required to get this PR up to date (bytecodealliance/gecko-dev#54, bytecodealliance/gecko-dev#55, bytecodealliance/spidermonkey-wasi-embedding#19, then update commit hash here) but once all that's done this should be green too.

[cfallin]

@guybedford tests are green now, I think ready for final review?

[guybedford]

@cfallin previously when I tried to build the web platform tests test case I was getting this error:

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at src/eval.rs:1362:25:
PC is a runtime value: Runtime(Some(v12146))

now when I try to build the web platform tests I get a silent failure without any stderr.

Was this issue resolved, or did the work to remove the logging also disable legitimate stderr logging?

[cfallin]

@guybedford the error was resolved by the fix in bytecodealliance/gecko-dev#54; none of my changes should have disabled legitimated stderr output; I can take a look at WPT, I hadn't tried running those tests yet.

[guybedford]

Thanks for confirming the panic was also resolved. In that case, it must be something else unrelated.

Of course, it would be great to get the WPT passing as well, but since we've established no regressions let's go ahead and land for now.