c-api: `gc` feature unconditionally enabled in `wasmtime` crate

[leonm1]

In the c-api crate, the c-api specifies wasmtime as a dependency and explicitly enumerates its default features. Cargo permits overriding the features in a subdependency by explicitly passing the subdependency and a set of features, such as this:

[dependencies]
wasmtime = {version = "42.0.1", default-features = false, features = ['std', 'runtime']}
wasmtime-c-api-impl = {version = "42.0.1", features = ['cranelift']}

However, this is not able to disable explicitly selected features of subdependencies (as default-features = false only applies to the features in the wasmtime crate's own Cargo.toml).

wasmtime's c-api crate already includes a feature to toggle gc, so the explicit inclusion of gc in the wasmtime's features is unnecessary. The fix would be to avoid specifying features for the wasmtime dependency in the c-api crate's Cargo.toml.

This change could be made backwards compatible by enabling the wasmtime c-api crate's gc feature by default, which would transitively enable wasmtime's gc feature in a way that could be disabled by consumers.

Related: proxy-wasm/proxy-wasm-cpp-host#502 (comment)

[alexcrichton]

Thanks for the report! This is indeed currently the case, and it should be fine to change this whenever. It's ok to break back-compat, that's why Wasmtime has major version releases every month.

The fix for this is, in theory:

• Remove gc from this dependency directive
• Everywhere there's WASMTIME_FEATURE_LIST the gc feature is already listed, so nothing to do there (but maybe double check)
• Add a CI job which builds the C API without default features and with the gc feature to double-check it works.

Happy to review/help with a PR if anyone's interested!

[tolumide-ng]

Happy to pick this up, thank you 😄