…p` instead. (bytecodealliance#89)

As per bytecodealliance#8, it seems the main purpose of using wasm-opt was to reduce
module size by stripping debug sections. The comment in the CMake file
also indicates an intent to optimize the binary.

However, `wasm-opt -O3` is extremely expensive on large programs; on
my 18-core, 36-thread workstation, it took several minutes to
complete. This is very painful when part of a debug loop that requires
release builds (e.g. for performance features).

This PR adds a `USE_WASM_OPT` CMake option, on by default to preserve
existing behavior, that allows one to do `cmake
-DCMAKE_BUILD_TYPE=Release -DUSE_WASM_OPT=OFF` to get a release build
without `wasm-opt`. In its place, this PR uses `wasm-tools strip -a`,
which strips debug sections (and all other custom sections) without
rewriting code.

…ytecodealliance#90)

SpiderMonkey CMake package: use alternate artifacts if specified.

When developing StarlingMonkey using an existing SpiderMonkey build with
no SM changes, it is very convenient to download and use pre-built
artifacts for SM from the CI on `spidermonkey-wasi-embedding`, and we do
not want to lose this convenience or approachability.

However, when modifying SpiderMonkey itself, it is nearly impossible to
do development with the current setup: the debug loop requires merging
changes to `gecko-dev` with one PR, updating the hash in
`spidermonkey-wasi-embedding` with another PR, getting both merged
and waiting for the build in CI before StarlingMonkey can use the
new engine.

Rather than require a local hack for such cases, this modifies the
SpiderMonkey CMake module to recognize a `SPIDERMONKEY_BINARIES`
environment variable, and use artifacts there instead. This allows the
developer to point this to a local clone of
`spidermonkey-wasi-embedding` with a modified `gecko-dev`, rebuilt with
`rebuild.sh` as needed. The `README` is updated with details on how to
use this.

…sm-opt config. (bytecodealliance#99)

In bytecodealliance#89, I had added an alternative (under `USE_WASM_OPT=OFF`) to avoid
expensive wasm-opt runs for local development. However I had replaced
this with `wasm-tools strip`, which strips all custom sections,
including those important for component-related linkage. Getting further
along my integration path I discovered the world info for the module was
missing.

This PR instead uses `wasm-opt -O0 --strip-debug`, which does what I
want (using the same tool as the ordinary build path) without the
expensive opt passes.

* Cleanup: make `Request::method` infallible

It already is infallible internally, so might as well reflect that in the signature and clean up the callsites.

* Bugfix: always reify input headers in the `Request` initializer

I stumbled upon this while implementing `Request.clone`, and while this change doesn't cause any additional WPT tests to pass, I'm certain that it's required: otherwise, `new Request(incomingRequest)` will not apply `incomingRequest`'s header entries to the new request if `.headers` has never been read on `incomingRequest`.

* Implement `Request.clone`

Fixes bytecodealliance#84

* add simple clone test

* fix headers clone

---------

Co-authored-by: Guy Bedford <[email protected]>

…ealliance#91)

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

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
```

[1]: https://gist.github.com/cfallin/4b18da12413e93f7e88568a92d09e4b7

* support weval testing

* add ci workflow for Weval test suite

* Update weval, resolving two test failures.

This commit updates to weval v0.2.7 which has no output by default,
allowing the expected-failure tests checking syntax error messages to
pass; we now pass 9/10 integration tests.

It also updates the flags on `componentize.sh`: a `--verbose` flag to
allow the user to see weval progress messages (perhaps useful if the
build is taking a long time, or to see the stats on function
specializations); and removal of the `--aot` flag, because there is only
one valid setting for a build configuration and it is not baked into the
shell script automatically.

* Update SpiderMonkey version to include two fixes (bytecodealliance/spidermonkey-wasi-embedding#19).

---------

Co-authored-by: Guy Bedford <[email protected]>

Update upstream SpiderMonkey and weval for a PBL+weval fix.

Pulls in bytecodealliance/gecko-dev#56.

Updates to commit hash of
bytecodealliance/spidermonkey-wasi-embedding#21, which pulls in
bytecodealliance/gecko-dev#57.

* ci: fix WPT failures for missing tests

* fixup

* fixup

* exclude currently missing tests

* fixup backtrace logging

…nce#113)

# Conflicts:
#	tests/tests.cmake