Stream: git-wasmtime

Topic: wasmtime / issue #10454 Provide a mechanism for disabling...

Wasmtime GitHub notifications bot (Mar 21 2025 at 18:35):

Stebalien opened issue #10454:

Feature

Provide some mechanism for disabling on-by-default config options without having to enable their associated cargo feature flags.

Benefit

The wasmtime Config has a bunch of options like Config::wasm_reference_types that are enabled by-default if the corresponding cargo feature is enabled. Unfortunately, these config options are gated by the same feature flags making it impossible to turn them off without enabling the underlying cargo feature.

This is fine when building an application, but is a problem for library authors. If a library author wants to configure wasmtime in a specific way, they need to enable features (in cargo) they don't actually want so they can disable them in the config. Unfortunately, there's no way to actually _detect_ if the feature has been enabled.

Implementation

The simplest solution is to provide some form of Config::minimal() constructor (or something like that) that turns off all optional features. New versions of wasmtime may make some of these features mandatory, but, IMO, that's fine. I'm mostly looking for predictability.

Alternatives

Another option is to let users call all config methods even if the associated capabilities are disabled via cargo features:

1. Remove the #[cfg(feature = ...)] gates on all Config methods and their associated fields in the config.
2. Return an error from Engine::new if unsupported features are requested.

The main drawback is that we'll lose the compile-time check on whether or not the feature is enabled.

Wasmtime GitHub notifications bot (Mar 21 2025 at 18:44):

fitzgen commented on issue #10454:

Your motivation definitely makes sense, however I think the alternative you describe is probably the best approach here, mainly because

1. I think that a Config::minimal() is a little too ambiguous and some people might think it means "good config for embedded use with minimal platform assumptions" while other might think it means "good config for my target platform with minimal wasm features" and I don't think it is worth trying to word-smith our way out of that kind of confusion or whatever and that trying to make everyone happy will make no one happy.

2. We already do some config validation during engine creation and return errors if incompatible config options are set and things like that.

Wasmtime GitHub notifications bot (Mar 21 2025 at 18:51):

alexcrichton commented on issue #10454:

Agreed yeah, I think it'd be reasonable to un-gate most of the Config methods and have them always available

Wasmtime GitHub notifications bot (Mar 21 2025 at 18:56):

Stebalien commented on issue #10454:

I'm quite happy with either option and I'm happy to take a stab at implementing this.

Wasmtime GitHub notifications bot (Mar 21 2025 at 19:19):

fitzgen commented on issue #10454:

I'm quite happy with either option and I'm happy to take a stab at implementing this.

Great! Let me know (here or zulip) if you need any pointers or anything like that :+1:

Wasmtime GitHub notifications bot (Mar 21 2025 at 19:53):

bjorn3 commented on issue #10454:

Would it make sense to have a method which returns a Config containing exactly the features in the lime1 target (as defined in the tool convensions repo) without any other features enabled?

Wasmtime GitHub notifications bot (Mar 21 2025 at 20:23):

Stebalien commented on issue #10454:

I have a PR here (https://github.com/bytecodealliance/wasmtime/pull/10455) but I need a small clarification on the default status of reference types with the "gc" feature disabled.

Last updated: Apr 17 2025 at 22:03 UTC