Merge the wit-parser and wit-component crates into this repository
#819
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
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.
* 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.
…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.
This commit applies the new instance formatting to the `component.wat` files in wit-component
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.
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
* 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 <peter@huene.dev> Co-authored-by: Peter Huene <peter@huene.dev>
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
* 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`.
* Implement parsing for the `stream` type. Stream has two types, a stream element type and an end type. In the ABI, it's represented as an i32 index. Lifting and lowering is not yet implemented. * Update the rest of wit-bindgen to compile with the new Stream type. * Handle `Stream` in crates/test-helpers/src/lib.rs. * Use `todo!` instead of `panic!` for unimplemented features.
* Implement bytecodealliance#163 * Update component to wit printing to use func instead of function * Run rustfmt Co-authored-by: Kyle Brown <kyleb@liquidrocketry.com>
…liance#239) This commit updates and refactors `wit-component` so that it produces components compatible with the latest component model proposal changes. Most of the big changes were to the encoding, which also was reimplemented in places to make the assignment of indexes more manageable. The `post-return` option is not yet implemented as wit-bindgen has not added support for it yet, so right now any components created by this tool will leak any data returned by exported functions. I also made the tool more consistently use `IndexMap` and `IndexSet` (an existing dependency) so that iterating of various things is stable.
* Implement parsing for the `future` type. Future has one type. In the ABI, it's represented as an i32 index. Lifting and lowering is not yet implemented. * Fix future syntax in a test. * Add `future` and `stream` to WIT.md. * Update types.wit.result with the new expected results.
Closes bytecodealliance#274 Signed-off-by: Klim Tsoutsman <klim@tsoutsman.com>
This commit refactors encoding in `wit-component` to only export types from the default interface and stop exporting types from instance types used in imports. It also makes "type only" encodings more explicit with `InterfaceEncoder` that will encode the types from a single interface only.
) * wit-component: emit function type encodings first. This commit ensures that components encoded with `wit-component` have the function types from the exports encoded before the instance types for instance imports. Previously, if an instance import defined a type it would be inserted into a map tracking duplicate types and not exported; when the default interface was later processed with a matching type, the type index was reused without adding an export for the type. By encoding export function types first, it guarantees that the default exported interface has its named types exported. * wit-component: add test case to ensure default types are exported.
…e#357) The `params_equal` closure accidentally forgot to take into account parameter lists of different lengths which would mean that everything would be equal to the empty list. While reviewing this code I also noticed a number of cases where the `Hash` needed to improve to ensure that lengths of lists, variant numbers, and `None` cases all are hashed to improve the quality of the hash. Long-term my hope is that this need of `wit-component` will go away as "world files" are pushed deeper into `wit-parser` which will push this global-level deduplication into the type resolver instead of needing to duplicate it here manually.
Signed-off-by: Brian H <brian.hardock@fermyon.com> Signed-off-by: Brian H <brian.hardock@fermyon.com>
* Embed named type information in components In writing support for the JS host generator recently I found myself unable to take a `wit-component`-generated component and generate bindings for it, namely because the names of types were not present so it wasn't clear what records and such would be named. Currently `wit-component` has a solution to this in the form of an "interface encoder" which produces a `*.wasm` file which is a theoretical bijection between a component and a `*.wit` interface as defined today. This `wit2wasm` and `wasm2wit` tooling, however, was all geared towards individual interfaces and didn't clearly fit within a full-fledged component produced by `wit-component`. In this PR I've decided to smash all of this together and get everything working in concert at the same time. Specifically in this PR I've done an large number of changes to `wit-component` along the lines of: * The `wit2wasm` tooling is not gone and replaced by `wit-component --types-only`. This was a large shift in the direction of `wit2wasm` as well as it wasn't merely moved but was instead integrated with `wit-component`'s idea of "worlds" where multiple interfaces are expressed simultaneously within a component (e.g. imports, exports, and the default interface). * The `--types-only` output, taken from `wit2wasm` is updated to support simultaneously describing multiple interfaces. Namely imported interfaces are instance imports, exported interfaces are exports of an instance type, and the default export exports types representing all the items in the default interface. * The default output of `wit-component` was updated to always embed type naming information. For example imported instances now also export type names on each individual instance. Exported instances export type names in addition to actual functions. This means that components always have named type information in them now when run through `wit-component`. * The `tests/interfaces.rs` test for components was overhauled to look more like `tests/components.rs`: multiple interfaces are supported. The test itself is still testing the same thing, though, namely it produces a `types-only` component which is verified against `types_only.wat`. The `types_only.wat` component is then additionally decoded using `wasm2wit` and the input `*.wit` files are asserted to all be correctly inferred from the input. Finally a second test was added to additionally produce a `component.wat` which is not `types-only` to check that interfaces can be inferred from full components in addition to types-only components. The "types only" interface of components may not be long-lived in `wit-component` depending on how things shape up over time. This isn't too bad though because the support for this mode is quite minimal. Otherwise there's a lot of effective churn in this PR largely around tests but the changes to Rust source files should all hopefully be more straightforward. One worry I have about this PR is that this is much more strongly leveraging a part of `wit-component` which isn't necessarily "battle-tested" yet. For example the mapping from a set of `*.wit` interfaces onto a component should be a bijection where one can always be generated from the other (modulo documentation at this time) but there are a number of features of `*.wit` which won't be recovered, for example type aliases. I would ideally like to write a fuzzer soon to fuzz-generate an `Interface` and round-trip that through a component to ensure the same interface pops out. This may not be the best thing to prioritize so early on though but I am still fearful that this can otherwise create really subtle and hard-to-understand bugs for users if the low-levels of tooling here have basic issues in them. For now though this should be sufficient to get the JS generator back on track since there's type information present and usable for generating human-readable and meaningful bindings. * Clarify self-describing
…ealliance#372) Previously a panic would be hit during encoding since type type wasn't encoded. This commit updates to encode all named types unconditionally for exports to ensure this panic isn't hit. Along the way this also removes an unnecessary `index_primitive` method and map since during my prior refactorings in this code I found that it was necessary to implement the functionality deeper and forgot to come back and remove the original solution.
* js: Take a component as input, not interfaces This commit is the implementation of bytecodealliance#314 for the JS host generator. The commit here covers basically everything in that issue for JS except it generates a slightly different structure of the JS output. Otherwise the main highlights are: * The JS host generator no longer implements the core `Generator` trait since it doesn't really fit in the component-as-input world. For now I created an `InterfaceGenerator` trait since similar functionality is used just not precisely the same. I expect that this will get iterated on over time as worlds and other host generators take shape. * The `wasmtime-environ` crate from Wasmtime itself, typically a "private" dependency of Wasmtime, is used to parse the input component and generate an `instantiate` function in JS. Wasmtime does all the heavy lifting of creating a linear list of initializers for the component and this empowers the generator to simply generate JS that is the list of initializers. * The `wit-component` crate is used to "extract" the `Interface` descriptions from the input component. This is used to generate type information for TypeScript as well as types for lifting/lowering. Internally a correlation is done from a lowering/lifting to an `Interface` function to connect the dots when instantiating a component. Lots of pieces needed updating here such as the runtime tests, the `wit-bindgen` CLI tool, and the demo web page. These are all updated for the new structure of the JS host generator. Overall this surprisingly went much more smoothly than I expected. With `wit-bindgen` being able to extract `Interface` representations from a component most of the prior JS host code generation was able to be reused. Along the way I also felt that the addition of "worlds" would have relatively obvious insertion points and would be relatively easily handled in all the places. The demo and runtime tests are proof enough to me at least that this all works internally, and this feels like a solid foundation to iterate from with the addition of worlds and continued support for JS hosts. * Rebase and fix tests * Pull in latest `wasmtime` where `main` now works * Add a `testwasi` implementation for JS and use it in all tests * Add a dummy `printf` to a C test to ensure it imports `testwasi` like the other languages. * Add a `fd_fdstat_get` stub to make C happy * Update `fd_write` to only work for fd 1 * Review comments
* Extract common code from JS host generation This commit extracts a few traits and utilities to the `wit-bindgen-core` crate and the `wit-bindgen` CLI. The intention here is to make it simple to implement this same generation scheme for other languages, such as Python, and additionally provide a path forward to centering the CLI interface around world files. * Migrate the host-wasmtime-rust generator to `WorldGenerator` This is intended to be the first step down the path of reorienting the Wasmtime generator around worlds instead of single interfaces through the new `WorldGenerator` trait rather than the old `Generator` trait. * Initial support for worlds in Rust guests * Get all tests working again for Rust guests/hosts * Fix demo build * Minor nits
…alliance#382) * Implement the component-model lexing rules for identifiers. The [component-model grammer] for kebab-case identifiers now looks like this: ``` name ::= <word> | <name>-<word> word ::= [a-z][0-9a-z]* | [A-Z][0-9A-Z]* ``` Implement the rules. This continues to use XID rules for the initial lexing, as that corresponds to what users might accidentally use, so that we can issue appropriate errors in those cases. The precise grammer is validated in a separate step. [component-model grammer]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#instance-definitions * Add more lexing tests. * Update the tests in tests/codegen/conventions.wit. * Comment out identifiers that collide when mapped to snake_case, for now. See WebAssembly/component-model#118.
* Fix some typos and linter warnings. This commit fixes some random comment typos and various linter warnings. * wit-component: rename `decode_interface_component`. This commit renames `decode_interface_component` to `decode_component_interfaces` to better describe what the function does. Previously it was meant to decode an "interface-only" component, but now it returns all the interfaces (i.e. the "world") of the component. * wit-component: implement multi-value return printing. This commit implements printing of multi-value returns of interfaces decoded from a component. * Remove `module` field from `Interface`. The `module` field was originally used by `cargo component` but is no longer necessary and otherwise unused from `wit-bindgen` itself. * Remove `symbol_namespace` from Rust generator. This field is no longer used anywhere in the wit-bindgen repo. * Add method to `Interface` for determining core export names. This commit extracts the expected core export name out of `wit-component` and into `Interface`, allowing generators to conform to the name expected by `wit-component`.
…codealliance#397) This commit leverages a new convenience API in `wasmparser` to strip the `component-type*` custom sections emitted by `wit-bindgen` guests during the componentization process for a core wasm module. These custom sections don't have any place in the core wasm module except as part of the build process and will end up just duplicating bits and pieces of the component itself, so there's no need for them to stick around once a component has been created.
This commit lifts the restriction that an adapter module as part of `wit-component` can only import a single interface. That restriction was a temporary artifact of the initial implementation due to the fact that at the time there was no convenient way to communicate about multiple imported interfaces. With the `ComponentInterfaces` encoding of a "world" now, though, the `wit-component` CLI is updated to require that the incoming adapter module has a `component-type*` custom section describing the world that it's importing.
…odealliance#401) * Refactor how string encodings are specified to `wit-component` This commit is motivated by the recent addition of utf-16 support into the C generator. Currently that works by "passing a flag" to the `wit-component` invocation effectively, but the level of abstraction of this flag isn't quite right: * The utf16 flag must be specified in two separate locations that need to be kept in sync. * Interfaces aren't necessarily all generated in one location, meaning that it's not always correct to specify utf16 for everything all at-once. Instead it would be better to on a per-unit-generation granularity for the encoding to be specified. The contents of this commit aim to address this issue by changing the `component-type` custom section in wasm binaries generated by guest-generators to include the string encoding used. The encoding of strings wasn't moved into the `Interface` structure since it's an implementation-level detail rather than an interface-level detail. The `component-type` custom section is now encoded as a leading version byte, a string encoding byte, followed by the component as before. The `wit-component` tooling internally has been refactored to take all of this into account. Notably the import/exports/default lists were replaced with a new `BindgenMetadata` structure which handles all the merging between different custom sections and CLI flags. Additionally new maps are plumbed around which keep track of core wasm imports/exports and their registered encoding to ensure that the liftings/lowerings use the right encoding. The main limitation of this commit is that the same interface cannot be imported with two different encodings into the same core wasm module. Implementing this will require unique names of the import into the module (e.g. some form of name mangling). Otherwise for now it returns an error. It's expected that user-level interactions with `wit-component` are largely unchanged after this commit. The main change is that if the `wit-component` tool is run manually then the `--encoding` flag is largely not necessary unless the binary doesn't previously have `component-type` embedded sections. * Fix demo build
…ytecodealliance#409) * gen-host-js: Error wrapping and unwrapping for singular results When an exported component function has a singular return of type result, treat this as a throwable in the JS enviroment, by throwing the error payload. Similarly, when an imported function has a singular return of type result, add a catch handler and wrap the function in a result object when handling. Further optimization work should be done to avoid unnecessary wrapping in future. * better payload check, return fixup * fixup demo * improved error payload extraction * fixup tests, intrinsic dependence * remove unnecessary tostring * pr feedback * remove unnecessary include * simpler throws check * review feedback * explicit result flattening * throws signature * fixup throws signature
…#421) * start of support for adapter exports. doesnt actually work we're stuck on wit-bindgen-guest-rust performing allocations when it creates all the glue for the default export. we need a mode in the guest-rust crate for putting the type information about the default export into the object file, but not generating the actual functions, because in the case of this adapter, we want to create those functions manually so that they dont pull in std & therefore an allocator. * testwasi: export a "command" via an off-by-default feature * encode_exports: optional instance & realloc index in case the adapter isnt required * Remove command support from dummy preview1 This is only used for tests and none of the tests are exercising commands. * Disable default features for workspace deps Gets `wasi_snapshot_preview1` compiling correctly by actually turning off default features. * Finish up exported interfaces from adapters * Add missing default feature Co-authored-by: Pat Hickey <phickey@fastly.com>
Nothing major, just keeping up to date.
* syntax: world + interface Signed-off-by: Brian H <brian.hardock@fermyon.com> * Get tests passing Remove all parsing tests related to `use` along the way to get re-added once `use` is re-implemented for top-level worlds. * Update wit-parser tests to worlds Drop usage of the old `Interface::parse_file` function. * Add some basic tests for world Assert some assorted failures as well as a basic successful structure. * Remove existing support for `use` This will come back shortly with worlds, but for now nothing uses this in the repository any more and it's not implemented within the resolver so temporarily remove it. * Thread through docs on worlds/interfaces * Remove docs from imports/exports They're not threaded anywhere right now so remove them. Can be added back in if needed in the future. * Implement temporary stopgap of `default export` * Fix demo build Signed-off-by: Brian H <brian.hardock@fermyon.com> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
…ecodealliance#430) * Remove a dead `load` function in bindgen-core * Update all `interfaces` tests to use worlds Migrate all `import-*.wit` and `export-*.wit` files to `world.wit` and additionally plumb through various fixes and such throughout `wit-component` to print the right names and support worlds when printing. * Migrate `components` tests to world syntax Replace all various `*.wit` files with singular `world.wit` files, plus optional `adapt-*-world.wit` files for adapters in their tests. The CLI interface for `wit-component` has also changed here to take a world file as input, optionally take a module to represent types-only encodings, and then additionally prints to stdout by default instead of a file. * Fix guest generators for recent changes * Fix CLI build
* Update all codegen tests to world syntax This enables simplifying codegen tests as well by having each test exercise imports/exports instead of having all code generators have one case for imports and one for exports. * Update codegen tests for the C guest generator * Update teavm codegen tests for worlds * Remove the `--name` argument from the CLI No longer needed as the name is inferred from the `*.wit` world. * Get all js host generator tests working Update all `runtime/*` tests with new naming conventions, world files, etc. Minor updates were made to names as I ended up using different conventions for the `*.wit` world files than were previously exercised. This also fixes a few minor issues with the output for the JS generator in the default ESM mode. * Get all host-wasmtime tests working with worlds Various small updates here and there to namings and such. * Get all Python tests working with worlds Fix support for exported instances by using correct import paths for various types/intrinsics/etc. Additionally update the codegen tests to specify a mypy cache dir to avoid racing between tests. * Update demo build for worlds Also fix an issue with the Rust host generator where it used an interface's name instead of the name of the import for import module names. * Update demo with world files
This commit adds two new commands to the `wasm-tools` CLI suite: * `wasm-tools component new` * `wasm-tools component wit` The previous `wit-component` tool is the `new` subcommand and the previous `wasm2wit` is the `wit` subcommand. The interface is roughly the same with some minor tweaks the input/output to account for the conventions of the `wasm-tools` CLI.
pchickey
approved these changes
Nov 16, 2022
alexcrichton
added a commit
to alexcrichton/witx-bindgen
that referenced
this pull request
Nov 16, 2022
These crates have been migrated to the `wasm-tools` repository as part of bytecodealliance/wasm-tools#819 to handle the first step of bytecodealliance#395
alexcrichton
added a commit
to bytecodealliance/wit-bindgen
that referenced
this pull request
Nov 17, 2022
* Remove wit-{component,parser} from this repository
These crates have been migrated to the `wasm-tools` repository as part
of bytecodealliance/wasm-tools#819 to handle the
first step of #395
* Use `wasm-tools` for demo instead of `wit-component`
rvolosatovs
pushed a commit
to bytecodealliance/wrpc
that referenced
this pull request
May 23, 2024
* Remove wit-{component,parser} from this repository
These crates have been migrated to the `wasm-tools` repository as part
of bytecodealliance/wasm-tools#819 to handle the
first step of bytecodealliance/wit-bindgen#395
* Use `wasm-tools` for demo instead of `wit-component`
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.
This PR uses the
git filter-reposubcommand to extract thecrates/wit-{parser,component}directory history from the bytecodealliance/wit-bindgen repository and merges them into this repository. This completes the first step of bytecodealliance/wit-bindgen#395 where these two core utilities for working with*.witand components are extracted into a more stable location here. The intention is that these crates will start to get published and versioned naturally as the crates in this repository are published.In integrating into this repository I've also updated the CLI integration of
wit-componentto get hooked into thewasm-toolsCLI. I've opted to create two new subcommands:wasm-tools component new- the oldwit-componentbinarywasm-tools component wit- the oldwasm2witbinaryThe CLI flags are slightly different due to how input/output is handled in this repository but they're otherwise largely the same. The final commit in this PR contains the refactoring for this as well as
README.mdupdates for the various folders and such to provide at least some brief documentation of what's going on here.The next step for this will be to delete the corresponding folders in the
wit-bindgenrepository and instead depend on git versions of this repository until these are published.