1.65.0.0-wasm32.1

wasm32-correct Plutus evaluator, rebased onto upstream 1.65.0.0.

Recommended build for 1.65.0.0. This is a bugfix over 1.65.0.0-wasm32 and supersedes it. Same upstream base, no API changes.

Bugfix — 64-bit neutrality of the platform-Int lift/unlift

1.65.0.0-wasm32 un-poisoned the Int/Word KnownType instances on wasm32 and unlifted them through a platform-Int bounds check. On a 32-bit target that bounds at 2³¹, while the chain (64-bit) bounds at 2⁶³ — i.e. the unlift direction was not 64-bit-neutral. No default builtin exercises it, so it was latent, but it's exactly the silent-narrowing class this fork exists to prevent.

The fix splits the two directions (see Note [Platform Int on non-64-bit targets] in PlutusCore.Default.Universe):

• makeKnown (lift) kept — upcasting an Int to Integer is lossless on any word size, and it is used on wasm32 (lengthOfByteString, countSetBits, findFirstSetBit return a bare Int). Identical result on 32- and 64-bit.
• readKnown (unlift) poisoned — a 32-bit Int cannot represent the chain's full Int64 range, so rather than ship a non-neutral instance we fail loudly. Any future builtin (or user extension) that unlifts a platform Int on a 32-bit target now errors instead of silently diverging.

Verification

Full upstream suite re-run at WORD_SIZE_IN_BITS == 32 under wasmtime, green:

• plutus-core-test — 2294
• untyped-plutus-core-test — 870

64-bit codegen is unchanged: the fix and its helper are gated #if WORD_SIZE_IN_BITS != 64, so the source a 64-bit node compiles is byte-identical to upstream.

What changed across the fork and how to use the artifacts: WASM32.md.

Assets

9d11ad68a5e511197df72438c9885b72f7d81914095105bb7b870ce47b39b715  uplc.wasm