fn wasm_features(&self) -> wasmparser::WasmFeatures {
        wasmparser::WasmFeatures {
            // Proposals that we support.
            multi_memory: self.wasm_multi_memory.unwrap_or(DEFAULT_WASM_MULTI_MEMORY),
            multi_value: self.wasm_multi_value.unwrap_or(DEFAULT_WASM_MULTI_VALUE),
            module_linking: self
                .wasm_module_linking
                .unwrap_or(DEFAULT_WASM_MODULE_LINKING),

            // Proposals that we should add support for.
            reference_types: false,
            simd: false,
            threads: false,
            tail_call: false,
            memory64: false,
            exceptions: false,

            // XXX: Though we don't actually support bulk memory yet, we
            // unconditionally turn it on.
            //
            // Many parsers, notably our own `wasmparser`, assume that which
            // Wasm features are enabled or disabled cannot affect parsing, only
            // validation. That assumption is incorrect when it comes to data
            // segments, the multi-memory proposal, and the bulk memory
            // proposal. A `0x01` prefix of a data segment can either mean "this
            // is a passive segment" if bulk memory is enabled or "this segment
            // is referring to memory index 1" if both bulk memory is disabled
            // and multi-memory is enabled. `wasmparser` fails to handle this
            // edge case, which means that everything built on top of it, like
            // Wasmtime, also fail to handle this edge case. However, because
            // bulk memory is merged into the spec proper and is no longer
            // technically a "proposal", and because a fix would require
            // significant refactoring and API changes to give a
            // `wasmparser::Parser` a `wasmparser::WasmFeatures`, we won't ever
            // resolve this discrepancy in `wasmparser`.
            //
            // So we enable bulk memory during parsing, validation, and
            // execution, but we add our own custom validation pass to ensure
            // that no table-mutating instructions exist in our input modules
            // until we *actually* support bulk memory.
            bulk_memory: true,

            // We will never want to enable this.
            deterministic_only: false,
        }
    }
// NB: keep this in sync with the Wasmtime config.
keep this in sync with the Wasmtime config.
keep this in sync with the Wasmtime config .
fn wasm_features(&self) -> wasmparser::WasmFeatures {
        wasmparser::WasmFeatures {
            // Proposals that we support.
            multi_memory: self.wasm_multi_memory.unwrap_or(DEFAULT_WASM_MULTI_MEMORY),
            multi_value: self.wasm_multi_value.unwrap_or(DEFAULT_WASM_MULTI_VALUE),
            module_linking: self
                .wasm_module_linking
                .unwrap_or(DEFAULT_WASM_MODULE_LINKING),
            // Proposals that we should add support for.
            reference_types: false,
            simd: false,
            threads: false,
            tail_call: false,
            memory64: false,
            exceptions: false,
            // XXX: Though we don't actually support bulk memory yet, we
            // unconditionally turn it on.
            //
            // Many parsers, notably our own `wasmparser`, assume that which
            // Wasm features are enabled or disabled cannot affect parsing, only
            // validation. That assumption is incorrect when it comes to data
            // segments, the multi-memory proposal, and the bulk memory
            // proposal. A `0x01` prefix of a data segment can either mean "this
            // is a passive segment" if bulk memory is enabled or "this segment
            // is referring to memory index 1" if both bulk memory is disabled
            // and multi-memory is enabled. `wasmparser` fails to handle this
            // edge case, which means that everything built on top of it, like
            // Wasmtime, also fail to handle this edge case. However, because
            // bulk memory is merged into the spec proper and is no longer
            // technically a "proposal", and because a fix would require
            // significant refactoring and API changes to give a
            // `wasmparser::Parser` a `wasmparser::WasmFeatures`, we won't ever
            // resolve this discrepancy in `wasmparser`.
            //
            // So we enable bulk memory during parsing, validation, and
            // execution, but we add our own custom validation pass to ensure
            // that no table-mutating instructions exist in our input modules
            // until we *actually* support bulk memory.
            bulk_memory: true,
            // We will never want to enable this.
            deterministic_only: false,
        }
    }
fn wasm_features ( & self ) -> wasmparser :: WasmFeatures { wasmparser :: WasmFeatures { // Proposals that we support. multi_memory : self . wasm_multi_memory . unwrap_or ( DEFAULT_WASM_MULTI_MEMORY ) , multi_value : self . wasm_multi_value . unwrap_or ( DEFAULT_WASM_MULTI_VALUE ) , module_linking : self . wasm_module_linking . unwrap_or ( DEFAULT_WASM_MODULE_LINKING ) , // Proposals that we should add support for. reference_types : false , simd : false , threads : false , tail_call : false , memory64 : false , exceptions : false , // XXX: Though we don't actually support bulk memory yet, we // unconditionally turn it on. // // Many parsers, notably our own `wasmparser`, assume that which // Wasm features are enabled or disabled cannot affect parsing, only // validation. That assumption is incorrect when it comes to data // segments, the multi-memory proposal, and the bulk memory // proposal. A `0x01` prefix of a data segment can either mean "this // is a passive segment" if bulk memory is enabled or "this segment // is referring to memory index 1" if both bulk memory is disabled // and multi-memory is enabled. `wasmparser` fails to handle this // edge case, which means that everything built on top of it, like // Wasmtime, also fail to handle this edge case. However, because // bulk memory is merged into the spec proper and is no longer // technically a "proposal", and because a fix would require // significant refactoring and API changes to give a // `wasmparser::Parser` a `wasmparser::WasmFeatures`, we won't ever // resolve this discrepancy in `wasmparser`. // // So we enable bulk memory during parsing, validation, and // execution, but we add our own custom validation pass to ensure // that no table-mutating instructions exist in our input modules // until we *actually* support bulk memory. bulk_memory : true , // We will never want to enable this. deterministic_only : false , } }
NB: keep this in sync with the Wasmtime config.
NB : keep this in sync with the Wasmtime config .
&self
&self