Bug 1703105 - wasm: Move generate-spectest tool into tree. r=lth

This commit moves the wasm-generate-testuite [1] tool into the
tree so that we have everything we need to update spectests in
one place. Documentation is updated.

Differential Revision: https://phabricator.services.mozilla.com/D111306

.hgignore

@@ -60,8 +60,10 @@ _OPT\.OBJ/
 # SpiderMonkey test result logs
 ^js/src/tests/results-.*\.(html|txt)$
 ^js/src/devtools/rootAnalysis/t/out
-# SpiderMonkey clone of the wasm-generate-testsuite repository
-^js/src/jit-test/etc/wasm/wasm-generate-testsuite/
+# SpiderMonkey wasm/generate-spectests artifacts
+^js/src/jit-test/etc/wasm/generate-spectests/specs/
+^js/src/jit-test/etc/wasm/generate-spectests/tests/
+^js/src/jit-test/etc/wasm/generate-spectests/target/
 
 # Java HTML5 parser classes
 ^parser/html/java/(html|java)parser/

js/src/jit-test/etc/wasm/Makefile

@@ -1,23 +1,10 @@
-.PHONY: update run expectations
+.PHONY: update
 
 warning = '\# Wasm Spec Tests\n\nThese tests are autogenerated using a tool, do not edit.\n\nSee `jit-test/etc/wasm/` for more information.'
 
 update:
-	[ -d ./wasm-generate-testsuite ] || git clone https://github.com/eqrion/wasm-generate-testsuite ./wasm-generate-testsuite
-	cp ./config.toml ./wasm-generate-testsuite/config.toml
-	cp ./config-lock.toml ./wasm-generate-testsuite/config-lock.toml
-	(cd ./wasm-generate-testsuite && RUST_LOG=info cargo run)
-	cp ./wasm-generate-testsuite/config-lock.toml ./config-lock.toml
+	(cd ./generate-spectests && RUST_LOG=info cargo run)
 	rm -r ../../tests/wasm/spec
-	cp -R wasm-generate-testsuite/tests/js ../../tests/wasm/spec
+	cp -R generate-spectests/tests/js ../../tests/wasm/spec
 	echo $(warning) > ../../tests/wasm/spec/README.md
 	[ ! -d ./spec-tests.patch ] || (cd ../../tests/wasm/spec && patch -u -p7 < ../../../etc/wasm/spec-tests.patch)
-
-run:
-	@[ -z $(MOZCONFIG) ] && echo "You need to define the MOZCONFIG env variable first."
-	@[ -z $(MOZCONFIG) ] || ../../../../../mach wpt /_mozilla/wasm
-
-expectations:
-	@[ -z $(MOZCONFIG) ] && echo "You need to define the MOZCONFIG env variable first." || true
-	@[ -z $(MOZCONFIG) ] || ../../../../../mach wpt /_mozilla/wasm --log-raw /tmp/expectations.log || true
-	@[ -z $(MOZCONFIG) ] || ../../../../../mach wpt-update /tmp/expectations.log --no-patch

js/src/jit-test/etc/wasm/README.md

@@ -9,28 +9,21 @@ Spec tests are given in `test/core` of the `spec` repository as `.wast` files.
 A `.wast` file is a superset of the `.wat` format with commands for running
 tests.
 
-The spec interpreter can natively consume `.wast` files to run the tests, or
-generate `.js` files which rely on the WebAssembly JS-API plus a harness file
-to implement unit-test functionality.
-
-We rely on the spec interpreter to generate `.js` files for us to run.
+The spec interpreter can natively consume `.wast` files to run the tests, but
+we cannot run them directly ourselves. To workaround this, we have a tool which
+can convert `.wast` files to `.js` that can be run efficiently in our jit-test
+harness.
 
 ## Running tests
 
-Tests are imported to `jit-test` and `wpt` to be run in both the JS shell or the
-browser.
+Tests are imported to `jit-test` to be run in the JS shell.
 
 To run under `jit-test`:
 ```bash
 cd js/src
 ./jit-test.py path_to_build/dist/bin/js wasm/spec/
 ```
 
-To run under `wpt` (generally not necessary):
-```bash
-./mach web-platform-test testing/web-platform/mozilla/tests/wasm/
-```
-
 ## Test importing
 
 There are many proposals in addition to the canonical spec. Each proposal is a
@@ -44,12 +37,9 @@ Testing each proposal separately in full isn't an attractive option either, as
 most tests are unchanged and that would cause a significant amount of wasted
 computation time.
 
-For this reason, we use a tool [1] to generate a set of separate test-suites
-that are 'pruned' to obtain a minimal set of tests. The tool works by merging
-each proposal with the proposal it is based off of and removing tests that
-have not changed.
-
-[1] https://github.com/eqrion/wasm-generate-testsuite
+For this reason, we generate a set of separate test-suites that are 'pruned' to
+obtain a minimal set of tests. The tool works by merging each proposal with the
+proposal it is based off of and removing tests that have not changed.
 
 ### Configuration
 
@@ -63,39 +53,23 @@ useful as proposals often make inconvenient and breaking changes.
 
 ```bash
 # Add, remove, or modify proposals
-vim config.toml
+vim generate-spectests/config.toml
 # Remove locks for any proposals you wish to pull the latest changes on
-vim config-lock.toml
+vim generate-spectests/config-lock.toml
 # Import the tests
 make update
 # View the tests that were imported
 hg stat
 # Run the imported tests and note failures
 ./jit-test.py dist/bin/js wasm/spec/
 # Exclude test failures
-vim config.toml
+vim generate-spectests/config.toml
 # Re-import the tests to exclude failing tests
 make update
 # Commit the changes
 hg commit
 ```
 
-### Debugging test failures
-
-Imported tests use the binary format, which is inconvenient for understanding
-why a test is failing.
-
-Luckily, each assertion in an imported test contains the line of the source file
-that it corresponds with.
-
-Unfortunately, the '.wast' files are not commited in the tree and so you must
-use the import tool to get the original source.
-
-Follow the steps in 'Operation' to get a `wasm-generate-testsuite` repo with
-the '.wast' files of each proposal. All proposals are stored in a single git
-repo named `specs/`. Each proposal is a branch, and you can find all tests
-under `test/core`.
-
 ### Debugging import failures
 
 Proposals can often have conflicts with their upstream proposals. This is okay,
@@ -104,10 +78,6 @@ and the test importer will fallback to building tests on an unmerged tree.
 This will likely result in extra tests being imported due to spurious
 differences between the proposal and upstream, but generally is okay.
 
-It's also possible that a proposal is 'broken' and fails to generate '.js' test
-files with the spec interpreter. The best way to debug this is to check out the
-proposal repo and debug why `./test/build.py` is failing.
-
 The import tool uses `RUST_LOG` to output debug information. `Makefile`
 automatically uses `RUST_LOG=info`. Change that to `RUST_LOG=debug` to get
 verbose output of all the commands run.