Skip to content

Provide a mechanism for disabling on-by-default config options regardless of the enabled cargo feature flags #10454

@Stebalien

Description

@Stebalien
Contributor

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.

Activity

fitzgen

fitzgen commented on Mar 21, 2025

@fitzgen
Member

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.

alexcrichton

alexcrichton commented on Mar 21, 2025

@alexcrichton
Member

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

Stebalien

Stebalien commented on Mar 21, 2025

@Stebalien
ContributorAuthor

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

fitzgen

fitzgen commented on Mar 21, 2025

@fitzgen
Member

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 👍

bjorn3

bjorn3 commented on Mar 21, 2025

@bjorn3
Contributor

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?

Stebalien

Stebalien commented on Mar 21, 2025

@Stebalien
ContributorAuthor

I have a PR here (#10455) but I need a small clarification on the default status of reference types with the "gc" feature disabled.

added 3 commits that reference this issue on Mar 21, 2025
88bab50
ef13941
655afbd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Participants

      @alexcrichton@fitzgen@Stebalien@bjorn3

      Issue actions

        Provide a mechanism for disabling on-by-default config options regardless of the enabled cargo feature flags · Issue #10454 · bytecodealliance/wasmtime