Stream: git-wasmtime

Topic: wasmtime / PR #11812 Make Config::wasm_feature public.

Wasmtime GitHub notifications bot (Oct 08 2025 at 07:25):

graydon opened PR #11812 from graydon:surface-wasm-feature to bytecodealliance:main:

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 existing helper function publicly.

Wasmtime GitHub notifications bot (Oct 08 2025 at 07:25):

graydon requested alexcrichton for a review on PR #11812.

Wasmtime GitHub notifications bot (Oct 08 2025 at 07:25):

graydon requested wasmtime-core-reviewers for a review on PR #11812.

Wasmtime GitHub notifications bot (Oct 08 2025 at 08:48):

github-actions[bot] commented on PR #11812:

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• [ ] If you added a new Config method, you wrote extensive documentation for
  it.

  <details>

  Our documentation should be of the following form:

  ```text
  Short, simple summary sentence.

  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.

  Is this method fallible? If so, when can it return an error?

  Can this method panic? If so, when does it panic?

  Example

  Optional example here.
  ```

  </details>

• [ ] If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  <details>

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See [our docs on fuzzing][fuzzing-docs] for more details.

  </details>

• [ ] If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html

---

<details>

To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.

To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.

Learn more.

</details>

Wasmtime GitHub notifications bot (Oct 08 2025 at 14:48):

alexcrichton submitted PR review:

Thanks! While deceptively simple as a PR I think we'll want to flesh this out a bit more before exposing it for general usage given how low-level it is. I'm happy to do some of these changes as well, but some things I can think of are:

• The wasmtime crate should reexport the WasmFeatures flag so users have a way to reasonably use the right version (vs depending on wasmparser themselves)
• This method may want to be renamed to wasm_features since it can be used to set mutliple features at once.
• For the documentation I think it'd be worth calling out that it's always possible for Config to return an error when creating an Engine if the feature configuration isn't supported. For example if gc is enabled at runtime but was disabled at compile time that'll cause Engine creation to fail.
• I'm a bit worried about possible unsafety/unsoundness/panics/etc related to features that wasm-tools supports that Wasmtime doesn't support. Most of the time Wasmtime would probably panic at the compilation phase of a module which isn't the end of the world, but panicking at runtime is a possibility and would be much worse. To sole this the Config::compiler_panicking_wasm_features method I think should be updated to have a known set of "anything outside this set will panic". Basically an allow-list of the set of proposals Wasmtime understands well enough to not egregriously panic on. That way if wasmparser adds a new feature and there's no support in Wasmtime that's fine, it'll just return a first-class error during Engine creation saying "we don't support that".

That's what I can think of at least to make sure we've crossed our t's and dotted the i's here. I realize that's probably more than you wanted to take on with this PR though. Would you be ok applying some of these updates? Or would you prefer to hand it off?

Wasmtime GitHub notifications bot (Oct 08 2025 at 22:01):

graydon commented on PR #11812:

Would you be ok applying some of these updates? Or would you prefer to hand it off?

I'll see what I can do!

Wasmtime GitHub notifications bot (Oct 08 2025 at 22:37):

graydon updated PR #11812.

Wasmtime GitHub notifications bot (Oct 08 2025 at 22:39):

graydon commented on PR #11812:

@alexcrichton I've added what I _think_ ought to dot those i's and cross those t's though I am uncertain that I picked the list of "known to wasmtime at all" flags correctly; I don't know exactly what wasmtime knows implicitly or explicitly. So I just put in "every feature currently in wasmparser at the time of writing". I can pare it down a little if you can spot any "oh no we definitely don't support that one" entries in the list.

Wasmtime GitHub notifications bot (Oct 09 2025 at 15:21):

alexcrichton created PR review comment:

One way to organize this might be, at the top, to have let mut unsupported = !features_known_to_wasmtime; and then this match conditionally adds more features into the set, then after the match the unsupported set is returned. That way we don't have to worry about or-ing in the set on each branch.

Wasmtime GitHub notifications bot (Oct 09 2025 at 15:21):

alexcrichton created PR review comment:

Thanks for listing these out! For ones that we can remove, I'd drop: MEMORY_CONTROL, LEGACY_EXCEPTIONS, CM_VALUES, CM_NESTED_NAMES, and CM_FIXED_SIZE_LIST. Everything else should be reasonable enough to keep, however.

Wasmtime GitHub notifications bot (Oct 09 2025 at 15:22):

alexcrichton submitted PR review:

Thanks again for this!

Wasmtime GitHub notifications bot (Oct 09 2025 at 17:38):

graydon updated PR #11812.

Wasmtime GitHub notifications bot (Oct 09 2025 at 20:05):

alexcrichton updated PR #11812.

Wasmtime GitHub notifications bot (Oct 09 2025 at 20:06):

alexcrichton has enabled auto merge for PR #11812.

Wasmtime GitHub notifications bot (Oct 09 2025 at 21:26):

alexcrichton merged PR #11812.

Last updated: Dec 06 2025 at 07:03 UTC