Remove witx crate dependency (or maintain it)

[oscargus]

Feature

I think it makes sense to either work around the witx crate or take maintenance over it. (Not sure how crucial it is so cannot judge which is the better approach.)

The witx crate is quite old and has some (very) old dependencies:

• thiserror 1 (probably OK, but for my project it is now the only one that uses version 1)
• wast 35 (latest version is 248)

Benefit

No need to compile and depend on these old dependencies. Reduces transitive-dependency hell a bit.

Implementation

Easiest is probably to start to maintain it. Looking at https://crates.io/crates/witx/reverse_dependencies?page=1 it seems like wiggle-* and wasmtime-* are the main users.

The code is available at https://github.com/WebAssembly/WASI/tree/wasi-0.1/tools/witx (took me a while to find it)

Alternatives

No idea.

[bjorn3]

The witx crate is only used by wasi-common, which is the legacy implementation of wasip1 in wasmtime. It is only used when using wasi-threads as threads are not yet compatible with the wasm component model (the new wasip1 implementation is built on top of wasip2 and by extension the component model) There is an open RFC to remove support for wasi-threads and remove wasi-common: bytecodealliance/rfcs#47

or take maintenance over it

All three owners on crates.io work on Wasmtime, so there is no maintenance to take over.

[alexcrichton]

Unfortunately wasmtime-wasi does transitively use this crate with the wasip1 implementation. Specifically wasmtime-wasi uses wiggle the same way wasi-common does, and wiggle depends on witx. I do think that it would be reasonable to solve this, but solving this will require refactoring wiggle to not depend on witx.

Another option perhaps, since wiggle is more-or-less frozen, is to remove the macro part of wiggle and just check in the generated code. That would enable removing this dependency entirely.