WIP Threads merge upstream spec #196
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The following test was failing in SpiderMonkey: (module $Global (export "e" (global $g)) (global $g i32 (i32.const 42)) ) (assert_return (get "e") (i32.const 42)) The issue was a generated call to index.js `get` which would return the exported WebAssembly.Global object and compare it to a literal 42. The harness emitted by js.ml seems to include this check. Not sure why that's a separate harness, but for now it seems good to have the check in all harnesses.
1. shelve.DbfilenameShelf no longer has has_key, use `in` 2. dict no longer has iteritems(), use items() 3. open subprocess as text, since we are passing text to it
latex_paper_size is deprecated since 1.6.1 [0]. Also add override keyword when adding node to silence the warnings. [0] https://www.sphinx-doc.org/en/master/changes.html#id100
* Upgrade Sphinx to 2.3.0 and fixes to extensions Couple of breaking changes due to the Sphinx upgrade, requiring fixes: 1. node['latex'] is an invalid access. It was used when Sphinx created custom math nodes for the math role. But now that docutils supports it, we don't need to do this anymore. 2. we copied latex_visit_math and latex_visit_displaymath from sphinx's LaTeXTranslator visit_math and visit_math_block, we can't call them directly because those call respective superclass methods, and since we call add_node, it will override those methods with ext_latex_visit_math, and ending up in a stack overflow. 3. directly create a math node rather than calling into docutils math_role, because it only looks at raw_text, and overrides text, which contains what we care about (latex code). 4. Similar changes to mathdefbs Finally we can pin the Sphinx version to 2.3.0 in .travis.yml. I mostly manually verified that this change is okay, looking at the html (multi-page), html (single-page), and pdf, checking the math equations, both inline and block, making sure the links still work. Issue #1157 * Fix Sphinx name in travis.yml * No sudo for pip install Sphinx * Add TODOs for code copied from sphinx
* WIP upgrade to bionic * Remove c++ from language in .travis.yml * Remove extra apt-get instructions
With the Sphinx upgrade in #1157 we no longer need these sed commands. At the same time, clean up the way we configure mathjax, using a config value, instead of sed.
* Fix TeX maxbuffer option for MathJax The configuration is case sensitive. Fixes #1166 * Update comment to MathJax TeX configuration
With #1162, we install ocaml via apt, not via our download script, so we no longer need to modify the PATH to find ocaml.
Instead of overwriting the nodes, we extend the translators provided by Sphinx, and customize the visit_math and visit_math_block logic, to do our hyperlinking logic before calling the base class visit methods. This allows us to deduplicate the logic we copied earlier. For mathdefbs.py, remove all latex related logic, since we don't use this extension to build latex. Issue #1157
See the non-trapping-float-to-int-conversions proposal here: https://github.com/WebAssembly/nontrapping-float-to-int-conversions
See the sign-extension-ops proposal here: https://github.com/WebAssembly/sign-extension-ops This PR is built on top of #1143 (merge nontrapping-float-to-int).
See the multi-value proposal here: https://github.com/WebAssembly/multi-value This PR is built on top of the following PRs: * #1143 (merge nontrapping-float-to-int) * #1144 (merge sign-extension-ops)
There are already tests for effective address overflow, but those have a large value baked into the offset. These tests all use `1` as the immediate offset, and use `-1` for the address on the stack, which may be compiled differently.
We've recently found a bug in a WebAssembly library we've been working
with where we're mapping WebAssembly to a tree-like IR internally. The
way we parse into this representation, however, has a bug when the
function isn't itself tree-like but rather exibits properties that
exploit a stack machine. For example this isn't so straightforward to
represent in a tree-like fashion:
(import "" "a" (func $foo))
(import "" "b" (func $foo (result i32)))
(func (result i32)
call $b
call $b
call $a
i32.xor)
The extra `call $a` in the middle is valid `WebAssembly` but needs
special treatment when converting to a more tree-like IR format. I
figured it'd be good to ensure there's a spec test covering this case as
we currently pass the suite of spec tests but still contain this bug!
This also required disambiguating the references to "module", as there are now two definitions by that name.
Fixes #1514.
Improve wording.
… sync upstream JS with tests (#1546)
WebAssembly/spec@82a613d added `print_i64` to the standalone test files, but not to the ones generated by the spec interpreter.
Rather than describing keyword tokens as always being defined implicitly by terminal symbols in syntactic productions, describe them as being defined implicitly or explicitly. This accounts for the explicit definitions of `offset` and `align` phrases, which are lexically keywords, later in the chapter. Fixes #1552.
|
The latest changes to the upstream-rebuild branch (tracking issue #198) should mean that this PR is now superseded. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At the moment this is merged up to spec commit f9b461a
The document should build, but not yet the interpreter.
To try and make sure no threads addition was left out, I created a branch
spec-oldat the latest commit of the upstream spec that was merged previously, (that is I think7526564b56c30250b66504fe795e9c1e88a938af), and compared (withdiffand withmeld):git diff spec-old threads/main > old-changes.diffgit diff spec/main threads-update > updated-changes.diffSo the comparison was done with inspecting
meld old-changes.diff updated-changes.diffand editing appropriately.