Blocked by: required trait based WasmFeatures in wasmparser crate.
The wasmparser crate and Wasmi dependency has a crate feature called features.
This crate feature is enabled by default when compiling Wasmi.
However, we could easily introduce our own features crate feature that is enabled by default to enable wasmparser/features to profit from this wasmparser feature and opt-out of the Wasm feature testing which might actually be pretty costly in some cases, both for runtime and binary artifact size.
One problem remains: the wasmparser crate without features simply enables all its supported Wasm features which is a strict superset of Wasmi's own supported Wasm features. Therefore, Wasmi can no longer trust its input and has to implement its own safe guards which kinda defeats the purpose of this feature.
So, for that to work out as a whole we'd need a way to statically enforce our own set of WasmFeatures if features is disabled which is missing functionality in wasmparser IIRC.
Blocked by: required
traitbasedWasmFeaturesinwasmparsercrate.The
wasmparsercrate and Wasmi dependency has a crate feature calledfeatures.This crate feature is enabled by default when compiling Wasmi.
However, we could easily introduce our own
featurescrate feature that is enabled by default to enablewasmparser/featuresto profit from thiswasmparserfeature and opt-out of the Wasm feature testing which might actually be pretty costly in some cases, both for runtime and binary artifact size.One problem remains: the
wasmparsercrate withoutfeaturessimply enables all its supported Wasm features which is a strict superset of Wasmi's own supported Wasm features. Therefore, Wasmi can no longer trust its input and has to implement its own safe guards which kinda defeats the purpose of this feature.So, for that to work out as a whole we'd need a way to statically enforce our own set of
WasmFeaturesiffeaturesis disabled which is missing functionality inwasmparserIIRC.