Skip to content
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 48 commits into from
May 31, 2022
Merged

feat: prep for 0.1.0 release #8

merged 48 commits into from
May 31, 2022

Conversation

willemneal
Copy link

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.

willemneal and others added 30 commits February 7, 2022 12:34
* 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
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
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.
alexcrichton and others added 18 commits April 21, 2022 09:38
* 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.
@willemneal willemneal merged commit fce0296 into main May 31, 2022
@willemneal willemneal deleted the feat/release branch May 31, 2022 18:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.