Stream: wasmtime

Topic: preferred approach to disabling more WasmFeatures?


view this post on Zulip Graydon Hoare (Oct 08 2025 at 03:44):

I'm interested in turning a few of the WasmFeatures off (or explicitly asserting that they're on) that are not presently plumbed through to the surface of wasmtime::Config. Would folks be amenable to a PR that either (a) surfaces each of the missing ones separately as yet another Config::wasm_foo method or (b) just marks the Config::wasm_feature method as pub?

the latter seems easiest to me, but I am nervous it might be read as implying to callers that they can toggle on (or off) features that wasmtime isn't actually prepared to let them toggle. or something. any thoughts?

view this post on Zulip Alex Crichton (Oct 08 2025 at 04:23):

The main reason this wasn't done originally was the public API dependency on wasmparser, but nowadays we already have that and wasmtime's version policy is amenable to wasmparser breaking changes. I've also been not super satisfied with method-per-feature especially when it comes to feature sets like wasm{1,2,3}.

Basically I like the idea of exposing WasmFeatures myself. I think it'd be worth reexporting that type from the wasmtime crate for convenience too.

For the actual method one option might be to just expose a &mut WasmFeatures accessor as opposed to a pure getter setter since bitflags have a lot of convenient methods too. Exposing wasm_feature too though also I think would be fine

view this post on Zulip Alex Crichton (Oct 08 2025 at 04:23):

Sorry that's a lot of words for "good idea yes please!"

view this post on Zulip Graydon Hoare (Oct 08 2025 at 04:25):

weirdly enough Config has _two_ WasmFeatures subobjects -- one for things-enabled and one for things-disabled -- which are also, curiously, asserted to be disjoint. The exact nature of this perplexes me! but there is no single subobject to expose a &mut to in any case. It might be worth a bigger refactor someday?

view this post on Zulip Alex Crichton (Oct 08 2025 at 04:27):

Oh good point, method it is! The two sets are for explicit enables and explicit disables to handle how the default feature set also changes based on compiler and platform

view this post on Zulip Alex Crichton (Oct 08 2025 at 04:28):

It might be worth having a method that's "reset to this feature set" which takes WasmFeatures and resets both sets based on the contents

view this post on Zulip Graydon Hoare (Oct 08 2025 at 05:47):

like takes foo and sets enabled = foo; disabled = !foo; ?

view this post on Zulip Graydon Hoare (Oct 08 2025 at 05:47):

(I was literally going to open a 1-token PR that adds pub to the existing fn)

view this post on Zulip Graydon Hoare (Oct 08 2025 at 07:25):

https://github.com/bytecodealliance/wasmtime/pull/11812

(More than one token because it needs a doc comment)

I wanted to disable (and in some cases explicitly enable) WasmFeatures that are not currently surfaced with specific methods on Config. It seems like the simplest path is just to expose this existi...

view this post on Zulip Graydon Hoare (Oct 09 2025 at 04:47):

@Alex Crichton I expect you're perpetually buried in notifications so .. um I will .. add one here! .. but no pressure intended. just that I mostly made the necessary changes on this should-be-tiny PR. (and am wrapping up for the night anyway)


Last updated: Dec 06 2025 at 06:05 UTC