wasm32: define c_uint_fast16_t as u32

[egasimus]

I've approached SimplicityHL by compiling the SimplicityHL compiler to wasm32-unknown-unknown, so that I would be able to invoke it from JS.

After producing a program's P2TR address, the next step is to construct a spend PSET; trying to do that, I kept running into an opaque JetFailed error when calling satisfy_with_env.

I traced that to the UWORD size/align checks in simplicity::ffi::c_jets::sanity_checks. Defining c_uint_fast16_t it as u32 on WASM seems to fix it.

[apoelstra]

This value was originally set in commit 0386d3c in #204. The PR description there explicitly says that this value should be u16 not u32.

cc @uncomputable do you remember anything about this, what toolchain you used, etc?

Meanwhile, @egasimus I'm going to need you to write up a bunch more details about what you're doing, so that when we inevitably need to change this again we'll have more information.

[uncomputable]

I ran the unit tests using the wasm-unknown-unknown toolchain. The web IDE uses wasm-pack test --headless --firefox.

[egasimus]

Hi, sorry it took a bit to respond.

I build for wasm32-unknown-unknown in the environment defined in this Dockerfile. My most frequent build command is just just, which amounts to invoking this in the container:

wasm-pack build --target web --debug --no-opt

Wrote up more details in README of hackbg/simf where the action happens. Given Nix, it's easy to run the tests (though you'd have to clone the parent repo and chdir).

Since reporting this, I've pinned rust-simplicity and simplicityhl submodules in deps/ to my slightly patched versions (this PR and BlockstreamResearch/SimplicityHL#219).

So, reverting deps/rust-simplicity to mainline, and then running tests, would reproduce the issue.

What you'd see: an unmemorable jet error, which does not overtly present as a toolchain bug. But which did, eventually, trace to the sanity_checks function mentioned above. First check IIRC. What I have not, admittedly, sanity checked: whether the native uint on wasm32-unknown-unknown is indeed u32 (as sanity would ostensibly have it).

With the present PR applied, I'm seeing the resulting WASM compiling SimplicityHL programs to P2TR correctly in V8 (Deno, Chrome). I should put it through its paces more, definitely run the test suite.

Here's one weird occurence: I expected cargo to pick up the build.rs of simplicity-sys automatically, but instead it didn't. Came down to adding a "top-level" build.rs to the crate. IMO low probability for this to have altered the size of a type... and yet.

I wonder whether similar behavior can be observed in LWK builds as well. I see some good work in https://github.com/Blockstream/lwk/blob/master/lwk_wasm/flake.nix for example. Maybe Clang 15 is what's dodging this footgun in that case.