So, I opened this pull request for wasmparser, making it function in no-std environments (since if someone wants to use (say) cranelift-wasm in a no-std environment it wouldn't build at the moment because wasmparser is not no-std and it requires it). I was politely informed that I would need to open a discussion about merging it here, or else my PR would not be merged (even though this PR does not in fact touch wasmtime in any way and is completely unrelated to it). So, this issue is for the discussion for merging that PR. The PR does not modify any behavior of wasmparser or wasmtime, nor does it alter the development flow of (any) new developers (although they will simply have to avoid certain dependencies). However, that shouldn't be a problem, since wasmtime is an incremental wasm parser, and is media-agnostic as to where the wasm comes from.
The PR alters the dependency tree of wasmparser by adding the no-std-compat and an extern crate declaration above all use declarations in lib.rs. Additionally, I added a feature called std to facilitate the importation of libstd, and enabled it by default. Other than that, the code for the library is identical. This nullifies any reasons not to add no-std support to wasmparser, at minimum. CD/CI builds can be satisfied by adding another task to bench/test the wasmparser crate without any default features and with only the deterministic feature but not default/std.
Crates that should be avoided in wasmparsers development are typically any crates that depend on modules within libstd that aren't also in liballoc or libcore. (This is mitigated a bit by emulating mutexes/locks with spin and hashmaps with hashbrown, but things that touch the filesystem, networking, threads, processes, etc., should be avoided.) However, as I said previously I don't foresee any reason why wasmparser would ever need any of this functionality.