-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge with WebAssembly/spec branch wasm-3.0
#90
Conversation
An extra 0 byte is added after the function index, to make room for possibible future function-level hints. Also the offset and hint values in the branchint structure are swapped. Again, for flexible forward compatibility. See WebAssembly/branch-hinting#6 for the rationale
…Assembly#12) * Fix binary grammar definition of the branch hints custom section The overall section structure definition wasm missing.
This does not change much but it is more compatible with the code metadata format, where the field is not fixed but it represents the size of the payload as a u32.
* [interpreter] Handle custom sections and annotations Co-authored-by: Yuri Iozzelli <[email protected]> * Fix merge conflict * Fix lexer priorities * Fix wast.ml * Oops * Update wast.ml --------- Co-authored-by: Andreas Rossberg <[email protected]>
* [interpreter] Handle custom sections and annotations Co-authored-by: Yuri Iozzelli <[email protected]> * Fix merge conflict * Fix lexer priorities * Fix wast.ml * Oops * Update wast.ml --------- Co-authored-by: Andreas Rossberg <[email protected]>
This was renamed to kWasmVoid in WebAssembly/memory64@2f5a7c5.
wasm-3.0-exn
wasm-3.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rubberstamp.
Exn has been merged into wasm-3.0 a while ago, so you shouldn't need to merge that separately. (Though as long as you didn't get any merge conflicts from the latter, it shouldn't harm either. Did the 2nd merge say anything but "is already included"?)
I made the merge using the 'ort' strategy. It didn't say anything about already included. The diff from
If you like, I can redo the merge straight from |
Hm, to be sure nothing weird has happened, can you diff this branch against upstream/wasm-3.0? AFAICS, the diff should be empty if everything is correct. |
This is the diff https://gist.github.com/dhil/01e35c5ffaaf1e9513350010a73520d2 TL;DR: explainer documents and code examples. |
I can just roll back to HEAD and apply the changes from |
OK, I have remerged it now. The additions/deletions seem to be the same. The merge with |
Perfect, thanks! |
It looks to me like this PR is entirely uncontroversial and ready to go (it's just a case of bringing the stack-switching repo up-to-date). @fgmccabe please can you confirm that you're happy for it to be merged. |
* Rename "index type" to "address type" across the spec * Update "index type" to "address type" in the spec interpreter * Update section underlines It is very important that you have precisely the correct number of dots. It would be too much work for the computer otherwise. * Rename "address type" to "addr type" in the spec interpreter * Revert one stray interpreter update
…bAssembly#94) "index" was renamed to "address". Without this change, all JS tests generated from the core tests will fail.
This patch brings in the specification and reference interpreter changes from the
wasm-3.0
branch (https://github.com/WebAssembly/spec/tree/wasm-3.0).