Bump wasmparser from 0.224.1 to 0.235.0

[dependabot]

Bumps wasmparser from 0.224.1 to 0.235.0.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[jsturtevant]

Looking at the errors. this is going to need manual intervention to update the API changes

[jsturtevant]

pulling the commit message out:

This was a bit more involved due to a big change in the way function return types are handled. The orginal change was done in WebAssembly/component-model#368 and put initially put behind a feature flag in bytecodealliance/wasm-tools#1670. In 0.226.0 version of wasmparser this feature flag was removed to simplify the return results. This in turn simplifies the handling of the results here as well.

[jsturtevant]

@syntactically could you take a look at these updates?

[syntactically]

Some of this is sensible, but we should (a) still use a Result type alias or newtype struct for the Option<Value> used for result types and (b) think harder about whether there is a more ergonomic way to do FixedSizeList in the generated APIs.

[jsturtevant]

Some of this is sensible, but we should (a) still use a Result type alias or newtype struct for the Option used for result types and (b) think harder about whether there is a more ergonomic way to do FixedSizeList in the generated APIs.

Added an alias, let me know what you think

for (b), is this something we need to do for bumping the dependency or something we can defer (and open an issue to fix)?

[jsturtevant]

for (a), is the reasoning for the alias/type so we keep the types in etypes inline with types in like https://github.com/WebAssembly/component-model/blob/35c6d24fb952f3810db3d0f966cfe9ccb8240501/design/mvp/Binary.md?plain=1#L219?

[syntactically]

for (a), is the reasoning for the alias/type so we keep the types in etypes inline with types in like https://github.com/WebAssembly/component-model/blob/35c6d24fb952f3810db3d0f966cfe9ccb8240501/design/mvp/Binary.md?plain=1#L219?

Pretty much. Ideally the type section of the spec document but that's still being updated with these latest changes :)

[syntactically]

for (b), is this something we need to do for bumping the dependency or something we can defer (and open an issue to fix)?

Maybe test that it works at all the current way, but yeah can probably put off for a couple of weeks if it does.

[jsturtevant]

Maybe test that it works at all the current way, but yeah can probably put off for a couple of weeks if it does.

I added a test to verify that fixed lists do work with no modifications. Once I was doing that I saw how I could modify the rest the API so took a try at it.