forked from bytecodealliance/wit-bindgen
-
Notifications
You must be signed in to change notification settings - Fork 0
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
feat: prep for 0.1.0 release #8
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(TS): use `/**` doc string in TS * fix(TS): comment allignment * fix: update g
* feat: initial work to make nullable fields use option `?` * fix: unwrap nullable type and update test to use `?` * fix: missing semicolon * fix: refactor to return option when unwrapping nullables * feat: refactor nullable methods to iface struct * fix: fmt forgot to run it in root * chore: refactor nullable methods back to js impl
This commit implements simple CLI tools for encoding a single wit file to a WebAssembly component (`wit2wasm`) or decoding a WebAssembly component to a wit file (`wasm2wit`). The latter tool right now only works with the output of `wit2wasm` and may eventually be made more generic to spit out a wit representation for all imported/exported interfaces of a WebAssembly component.
This commit adds some tests to round trip from wit files to a component (in-memory), decoding the component bytes back to an `Interface`, and then printing the interface to compare against the original input file (which is expected to be from a previously "blessed" test run). Also fixes the printing of flags to use `flags` rather than record of bools in `InterfacePrinter` and functions with the same signature decoding to the wrong names.
…-encode Implement wit2wasm and wasm2wit tools.
…codealliance#123) * Replace string-literal syntax with a new '@' identifier syntax. Following up on bytecodealliance#119, this removes the string-literal syntax for identifiers, and introduces a new '@'-prefixed syntax. '@' identifiers are just like regular identifiers, except they start with '@' and are never parsed as keywords. Suggestions for better syntax are welcome. * Fix tests. * Switch from '@' to '%'.
* wit-component: update interface-only encodings. This commit updates the `wit2wasm` and `wasm2wit` tools to encode and decode direct exports rather than using an instance type to model the interface. The intent behind this is to better align with a component that exports its "default" interface as direct function exports rather than always exporting instances. * wasm2wit: only validate the top-level parser is for a component. * wasm2wit: validate nested modules in the component.
This update will make it easier to keep track of the index space of each section while constructing modules by relying on the provided `len` method of each section rather than having to maintain internal data structure for this purpose.
…-encoder chore: [wasmlink] Update wasmencoder to v0.10.0
* Added a failing test * Implement clone where possible * Arguments can't be called "i"
…tecodealliance#183) * wit-component: initial implementation. This commit provides the initial implementation for the `wit-component` tool. The tool is responsible for converting a core module implementing the canonical ABI into a component based on the WebAssembly component model proposal. Users provide the tool with the interfaces to be exported or imported by the component in `wit` format. The output of the tool is a component file. The tool validates that the core module is satisfied with the given imports and also exports the provided interfaces. The output component is also verified with the validator from `wasmparser`. * wit-component: add more tests. This commit adds a test to encode an interface, decode the bytes using `wasmprinter`, and then compare the output with a baseline wat file. It also adds a `simple` test case for encoding components where a component exports a single default interface. * wit-component: add more component tests. This commit adds more tests to `wit-component` for component encoding. * wit-component: add error handling test cases. This commit adds several test cases for validation of the module that will be encoded as a component. * wit-component: be smarter about canonical option encoding. This commit only adds an encoding option if the function signatures contain strings. It also only adds the `into` option only if the function signature requires it. Added tests for lifting and lowering of various function signatures to ensure the canonical options emitted are correct. * wit-component: update and better doc test cases. This commit updates the documentation for the tests in `wit-component` and restructures the interface encoding tests directory layout to match that of the component encoding tests. * wit-component: update test baseline for new wasmprinter. This commit updates wasmprinter and the test baselines now that it correctly prints outer aliases. * wit-component: update assert_eq! for better diff printing. The `pretty_assertions` crate prints a nice diff for `assert_eq!` failures, but the tests were reversing left and right to make it more confusing when conceptually seeing changes from the baseline. This commit swaps the two arguments to `assert_eq!` so that left is the baseline and right is the output of the test. * wit-component: give names to one of the test core modules. This commit adds some names to one of the test module's canonical definitions. This helps to test that the names survive encoding and are also present when printed. * wit-component: add an import and export test case. This commit adds a test to cover both importing and exporting interfaces from the same component. Fixes a bug where importing functions wasn't contributing to the function type list. * wit-component: use type information from wasmparser for validation. This commit uses the type information returned from wasmparser for the validation of the core module. It also reduces the complexity of parsing the core module by using methods provided by wasmparser. * wit-component: code review feedback changes. Various code review feedback changes. * wit-component: be smarter about import lowerings. This commit changes how imports are lowered. Previously, the tool used indirect lowerings for all imports, even if the import didn't need the `into` option. Now such lowerings are lowered before the inner core module is instantiated and directly given as an argument. Additionally, if there are indirect lowerings to perform, at most two additional modules are encoded: a module storing a table for only the indirect lowerings and another that initializes the table once the core module has been instantiated.
…tecodealliance#188) Fixes code generation for Wasmtime list lowering. List lowering happens in a for loop and thus opens a new scope, which invalidates previous caller_memory bindings. This previously was not ensured, resulting in borrow checker errors in the generated code if the items in a list required allocation. The `lists.wit` tests is modified to contain previously problematic definitions. Fixes bytecodealliance#187
…copied via the copy button. (bytecodealliance#189)
This commit applies the new instance formatting to the `component.wat` files in wit-component
Signed-off-by: Radu Matei <[email protected]>
I today started looking at updating this project to the new draft of the canonical ABI specified at WebAssembly/component-model#23 and while there's quite a few changes that need to happen the first thing that struck me was that maintaining all of the support for old-style witx files is pretty onerous. Especially the ABI-calculating code has lots of special cases for various witx constructs and the Preview1 ABI, and I wasn't really sure how to update this in many situations. Overall the original purpose of the witx support was to prove out that it's possible to support both the old witx abi and the new canonical ABI in the same generator. The canonical ABI has changed significantly in the meantime however and this doesn't necessarily make sense to do any more. I think it would be best now to reevaluate at the point when WASI is ready to switch to the component model what to do with the old witx support. I no longer think that "build it in here" is the obvious option. As this diff shows there's quite a bit of weight to carry the old witx abis as this commit clocks in at nearly 7000 lines removed. The specifics being dropped here are: * Parsing support for `*.witx` * Support for `Pointer` and `ConstPointer` * Support for `WitxInstruction` * Support for push/pull buffers The push/pull buffer feature was never actually fully implemented, even for Rust hosts they only kind-of worked. Most other generators never even implemented support for them. Additionally support for other `*.witx` constructs was somewhat spotty at best with very few tests. My hope is that there are no existing users of this support. If there are then I think it's best to re-evaluate how best to solve the scenario on-hand.
Some more vestigial remains from bytecodealliance#195
Further iteration from bytecodealliance#195 and dropping more features that are only needed for `*.witx`, the `usize` and `char8` types were only added for backcompat with witx itself.
* Rename f32/f64 to float32/float64 This commit renames the previously-known `f32` and `f64` interface types to `float32` and `float64` to match the upstream specification. * Fix a test
Not actually needed for anything after bytecodealliance#195
This commit changes the ABI for variants such as `union { f32, f64 }` which in the prior version of the canonical ABI would look like `i32 f64` but with the current canonical ABI draft it would instead look like `i32 i64`. The previous `unify` function is updated to the new name used in the canonical ABI explainer, `join`, the contents are modified, and one form of bitcast was removed as a result. Additionally I updated the bless'd output for `wasmlink` to ensure everything has newlines at the end since I was getting some otherwise odd changes locally. This is hopefully a one-time change for those baselines.
This commit feature gates most of the dependencies for `wit-bindgen-rust`. The intention behind this change is to make it so that we can optionally build `wit-bindgen-rust` as only the runtime support and effectively disable code generation support. The async support is also gated so that it can, potentially, be selectively enabled depending upon the presence of async functions in interface definitions. With these changes, systems that generate the bindings ahead-of-time can effectively take a dependency on `wit-bindgen-rust` only for implementing runtime support; this helps minimize the build dependencies when code generation isn't needed.
* Add a `Type::String` variant This removes the implicit interpretation that `list<char>` is equivalent to `string`, enabling `list<char>` to be equivalent to `&[char]` in Rust, for example. This commit is plumbed throughout all generators with new pseudo-instructions for lifting/lowering strings. * Apply suggestions from code review Co-authored-by: Peter Huene <[email protected]> Co-authored-by: Peter Huene <[email protected]>
This fixes an issue where some structures of "anonymous" types such as results/etc would accidentally only place types in the C implementation files instead of the header files where they were needed. Closes bytecodealliance#194
This splits out the `bool` type from `Variant` and additionally adds a new `unit` type. The new `unit` type will need some more tests in the future and this is just laying the groundwork for it for now. This'll soon get automatically tested though as the type of each case in `Variant` becomes required and functions will also switch to one return type.
This commit changes wit-defined functions to have precisely one return value instead of a list of return values. This matches the upstream component-model draft specification and canonical ABI. The main fallout here is that the spidermonkey tests stopped testing multiple-returns since while multi-value was implemented struct lifting/lowering is not yet implemented. Otherwise this is relatively straightforward although there are a few gotchas here and there as some language like JS, Python, and C don't have native tuple types and we still want to generate reasonable-ish code.
* Change the ABI for multi-value returns This commit aligns the implementation of wit-bindgen to the current draft of the canonical ABI to have multi-value returns expressed via pointers to the in-memory canonical ABI rather than the prior pointers-to-the-lowered-values-in-memory ABI. Due to the structure of wit-bindgen this ended up being a relatively simple change where the lowered instructions generators are using were already almost all appropriate. Mostly the parser ABI implementation changed here along with some fiddly bits in `wasmlink`. * Review comments
* Add support for params passed indirectly This commit adds support for the `MAX_FLAT_PARAMS` variable in the current canonical ABI draft. Argument lists which exceed a static number of parameters are now always passed indirectly through memory. In export this is dynamically allocated/freed and in imports this is statically passed. * Review comments
* Split out the `flags` type from `record` This commit creates a dedicated `flags` type which is distinct from the `record` type rather than the previous inferred-from-the-structure logic. This also additionally changes the canonical ABI of the `flags` type where 64-bit flags are now passed as two `i32` values instead of one `i64`. This ended up changing a significant amount of the logic internally in each code generator, notably around the new lift/lower behavior. Along the way I tried to refactor code to support 64+ flags in a few more places. While some support may be there, though, this is untested and will need a full-fledged feature in the future. * Fix a test * Fix some more flags * Fix more tests
This makes the `tuple` type a dedicated type in the type system which splits the lifting/lowerings for code generators. This ends up simplifying most code generators since they already had an if/else handling for most `Record` types for tuples and not-tuples.
* Split out an `Enum` type from the `Variant` type This was not 100% straightforward as the lowering of an enum wants to be `the_value as i32` in the Rust-to-wasm generator, but that's not working because sometimes `the_value` has type `&T` instead of `T` which can't be cast to `i32`. This means that lowerings in Rust are now always producing a `match` statement which should optimize to the same thing but won't be as easy on the eyes. Additionally a small change was made to the C code generator that `expected<_, _>` is now represented as a struct-of-union instead of special-cased to be an `enum`. The only reason it was special cased prior was that it was accidentally interpreted as an `enum` due to the `Variant::is_enum` check (which is now removed). * Move a test
…lliance#215) * Split out the `Option` and `Expected` types from `Variant` This commit is like prior PRs to split out specializations of types into their own AST type to avoid conflicting with the main type (in this case `variant`). I originally thought these two types would be relatively simple but this is probably one of the more complicated transitions, as evidenced by the lines changed here. The main churn was that variants already have a significant amount of code to support them and this is in some places "duplicating" code for option/expected and in other cases splitting what was already an if/else. Overall I think that the generated code gets a little better since it's clear when something is and `option` vs `expected` now rather than trying to have everything shoehorned into one. Notably the C code generator now generates descriptive fields like `bool is_some` or `bool is_err` instead of a bland `uint8_t tag` with some comments about how to use it. * Remove `Variant::as_{option,expected}` ... as these are separate variants now. * Review comments
* Split out a `Union` type from `Variant` This commit splits out the union specialization from `variant`, finalizing the transition to the new AST of types available in the current component model draft. This is mostly like the prior splittings-out where there's some duplication but it's relatively localized and hopefully not too hard to follow. * Fill out TODO
…e#220) This commit updates the internal representation of the `Variant` type to have a non-optional payload type as well as no customizable `tag` type. This brings the `Variant` type into alignment with the current canonical ABI where the payload type is non-optional as well. The `*.wit` syntax is not changing, however, where `variant { foo }` is sugar for `variant { foo(unit) }`. Various code generators were tweaked as well to get the new type representation to work as well.
…iance#221) This commit updates the `wasm-tools` dependencies for wit-component to the latest out of main. Fixes a test case baseline that changed due to fixes in `wasmprinter`.
When using other Executors for poll tasks, such as `wasm-bindgen-futures` (yes, I removed the web-related ones and just kept the task and queue). wake and poll are separate calls, and when the host calls `sender` of `wit-bindgen-rust`'s When the host calls the `send` method of `Sender` of `wit-bindgen-rust`, `Sender` will be released and the inner instance will be released at the same time, which will cause `OneShot` to not get the `inner` instance.
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.
Now that the upstream project has release a 0.1.0 version this PR updates this repo to use the new
aha-*
packages so that the parser can be used in production.