forked from bytecodealliance/wasm-tools
-
Notifications
You must be signed in to change notification settings - Fork 1
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 up to release 1.217.0 #133
Merged
Merged
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
Fix some warnings related to a new lint cropping up on nightly.
Move the static assertion about size to a runtime test to enable building with randomized layouts for testing.
This commit goes through some of the coverage information for the operator validator for the roundtrip test suite and fills in gaps of modules which are invalid but were previously not tested anywhere.
) Right now all upstream spec tests are asserted to have roughly the same shape of error as wasmparser produces to ensure that wasmparser isn't failing for the wrong reason on an invalid wasm module. This involves quite a large function, however, which is quite fuzzy on how it matches error strings. None of this logic should be applicable in the `tests/local/**/*.wast` tests however because those are all checked in to this repository and aren't intended to reflect upstream error messages. This commit disables the sloppy error matching and requires that the exact error contains the exact string in the assertion. This then goes through some tests and updates some of the expected errors.
With the new wit64 fuzzer don't use the old `wit-smith` but instead use the newer version. The old version still generates multi-return functions which are no longer supported by default in WIT. This will eventually cause a problem when the newest wit-smith generates features the "old" version no longer supports, but I figure that's a bridge that can be crossed when we get there.
…odealliance#1759) * Added and improved some accessors * Better name for serde (type instead of ty) * cargo fmt
* Add a shorthand feature constructor for Wasm 3.0 This is still in-development but is likely close to the final set of proposals. Additionally move the previous function constructors to associated `const` values to be a bit more idiomatic with other feature names. Finally refactor the CLI to more easily support these named sets in suggestions and refactor some feature selection in the roundtrip tests. * Update some tests
* Add write permissions to release process This looks to be required now due to recent repo settings changes * Also add pull-requests permission
The previous version of test output used the `:?` formatter for `anyhow::Error` which would include the native backtrace when `RUST_BACKTRACE=1` is set. This commit updates formatters to use `:#` which is a bit less readable but doesn't include the backtrace when this env var is set. Additionally a test is added to CI to ensure this doesn't regress in the future. This is adapted from bytecodealliance#1578. Closes bytecodealliance#1578
…codealliance#1753) * Proceed to the next step in the "remove `interface`" transition Starting in WebAssembly/component-model#263 the component model binary specification was updated in a technically breaking way to encode binaries differently. This was intended to be rolled out in a manner that minimized breakage however so bytecodealliance#1262 implemented validation where the prefix byte which changed was actually ignored if it was 0 or 1. The encoder at the time still emitted 1 as the prefix byte, however. The intention was that once the validator had percolated enough the encoder would switch to using 0. Unfortunately this change was basically forgotten about until now with WebAssembly/component-model#391, but now's probably "enough time passed" so the encoder is updated to emit a 0x00 leading byte in this situation instead of the historical 0x01 byte. This will start the transition period to eventually removing the validator's acceptance of the 0x01 byte. * Update test expectation
…tecodealliance#1767) The `wast` crate is responsible for turning textual WebAssembly into binary WebAssembly. This crate predates the existence of `wasm-encoder` and as such had its own implementation of converting the textual AST to binary. This works by effectively having a method for most AST nodes which says "put yourself into this list of bytes" and then making sure to carefully call everything in the correct order to ensure that the final bytes are indeed valid. Since `wast` was originally created, however, the `wasm-encoder` crate was created. This crate provides a static API and guarantee that the created module will be at least syntactically valid if not semantically valid. This makes emission less error prone and additionally deduplicates the encoding details between `wast` and the `wasm-encoder` crate. For quite some time now the `component` support in the `wast` crate has already been using the `wasm-encoder` crate to encode components. This is done by implementing conversions of AST fragments in `wast` to equivalent fragments in `wasm-encoder`. These conversions are then used to feed data into the right sections to produce the final binary. The purpose of this commit is to start moving in the same direction for core wasm. This commit itself doesn't update all of `binary.rs` but instead only replaces the top-level module with `wasm_encoder::Module`. This updates a few other minor locations too but the bulk of the work is left for a future commit. This is done to ensure there's support for this direction first before completing this work. One downside to this approach is that it might mean that the `wast` crate's binary size grows a bit since the `wasm-encoder` crate isn't quite as "tight" as the encoding in `wast` today. That being said the binary size of `wast` itself has not so far been a concern for anyone and this concern is mostly theoretical and can hopefully be worked around with alternative API design in `wasm-encoder` if needed. Another downside of this approach is that it's coupling `wast` to `wasm-encoder` more tightly, meaning change is harder. That is a good thing in that it reduces duplication but it's a bad thing where if you're only interested in text parsing then it means that adding new features would also require adding features to `wasm-encoder`. This downside is somewhat inescapable though and the only mitigating factor I'd have to offer is that so far most minor wasm extensions have already been coupled with sibling changes to the parser/validator/printer/encoder/etc. This does mean that it's less likely that a new contributor could implement a major proposal like Wasm GC which required large refactorings in all crates (whereas GC was initially implemented in `wast` by an external contributor as it was relatively localized). Overall I personally at least feel that the benefit of not having a duplicate encoder is the worth the tradeoffs here. All other crates in this repository are already deeply intertwined in terms of testing and feature support, and this is continuing that trend for the `wast` crate as well.
) This commit chiefly fixes the validator panic found in bytecodealliance#1763. This is done by sharing more infrastructure when validating types between the core module validator and the component validator. This sharing is done by extracting a new trait and moving methods from the core module to the trait and then implementing the trait for both component and core contexts. When writing tests this additionally discovered that name resolution on core types wasn't happening within components. The fix there was the same as the core module validator which was to extract shared bits to a trait and then implement the trait in both locations. Closes bytecodealliance#1763
* Rename `MaybeType` variants, tweak documentation This tweaks bytecodealliance#1734 to use terms I consider a bit more clear. It also updates the documentation to explain some more of the context that I currently have paged in but may not later. * review: tweak naming for @fitzgen
Pointed out in [this comment] this should help `wasm-smith` generate offsets/data segments with a wider range of valid values in wasm-smith rather than accidentally thinking the page size is much smaller than it actually is. [this comment]: bytecodealliance@fe1307b#r146408758
Put a space before `(pagesize ...)` and additionally use `start_group`/`end_group` so it gets colors automatically applied.
…ce#1762) * Update `*.wast` parser with recently added directives Parsing them is a bit wonky because it looks like this crate isn't architected the same way as the reference interpreter, but this so far otherwise seems to work. I've copied the upstream test added in WebAssembly/spec#1796 here for reference. * Fix compile of benches * Minor fixes
[automatically-tag-and-release-this-commit] Co-authored-by: Auto Release Process <auto-release-process@users.noreply.github.com>
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.
No description provided.