Enable gc feature by default

[tolumide-ng]

The c-api crate currently enables the gc feature on its wasmtime dependency, even though it exposes a gc feature to control this behaviour. This prevents downstream users from disabling gc, since Cargo.toml doesn't allow overriding it. However, structs like RootScope are only available when gc is enabled. Removing it from default features, without other options, would break internal implementations.

Changes

1. Enable the gc feature via the wasmtime-c-api crate by default.
2. Removes the explicitly set gc feature for the wasmtime dependency in c-api, thus enabling downstream users to specify this behaviour.

Closes #12783

[alexcrichton]

Returning now from vacation, thanks for your patience @tolumide-ng. Also I'll apologize that the scope of this issue is broadening to be a bit larger than I had originally anticipated. I thought there would be some minor edits required to get the c-api building without GC, but there's a number of API design decisions to make here which affect how exactly this works. I'm happy to help guide through these, but if you feel this is getting too broad in scope that's also totally fine.

[alexcrichton]

This is an example file where when gc is disabled the entire module may wish to disappear vs having lots of #[cfg] internally.

[tolumide-ng]

I'm not exactly sure what you mean here. There are some functions where the gc feature does not apply, and some other modules depend on the macros. I'd be happy to retry with more clarification.

[alexcrichton]

Ah what I mean is placing #![cfg(feature = "gc")] at the top of this file to avoid compiling the entire file when the gc feature is disabled. Everything in here looks GC-related so should be fine to omit when gc is disabled. What are the errors you're seeing though about other modules depending on this? Perhaps those dependencies should also be #[cfg]'d?

[tolumide-ng]

Thank you for the clarification. The errors mostly emanate from:

1. crates/c-api/src/table.rs:2:82 where wasm_ref_t is used
2. crates/c-api/src/val.rs:3:43 where wasm_val_union has *mut wasm_ref_t in its fields.

[alexcrichton]

For table.rs that's ok to exclude those functions when GC is disabled, and for val.rs the union will have fewer fields when GC is disabled and that's ok, too.

[tolumide-ng]

I'd update this right away, thank you

[tolumide-ng]

Returning now from vacation, thanks for your patience @tolumide-ng. Also I'll apologize that the scope of this issue is broadening to be a bit larger than I had originally anticipated. I thought there would be some minor edits required to get the c-api building without GC, but there's a number of API design decisions to make here which affect how exactly this works. I'm happy to help guide through these, but if you feel this is getting too broad in scope that's also totally fine.

Welcome back from your holiday @alexcrichton, and thank you for the review.
I'm happy to continue with the expanded scope. It looks like an informative introduction to the codebase.
I'd definitely appreciate your guidance as questions come up.

[alexcrichton]

Ah what I mean is placing #![cfg(feature = "gc")] at the top of this file to avoid compiling the entire file when the gc feature is disabled. Everything in here looks GC-related so should be fine to omit when gc is disabled. What are the errors you're seeing though about other modules depending on this? Perhaps those dependencies should also be #[cfg]'d?

[alexcrichton]

It looks like some merge conflicts have cropped up as well, I'd recommend rebasing and seeing how to resolve those as well.

[alexcrichton]

Would it be possible to make the definition of wasmtime_{any,extern}ref_t conditional based on WASMTIME_FEATURE_GC?

[alexcrichton]

For table.rs that's ok to exclude those functions when GC is disabled, and for val.rs the union will have fewer fields when GC is disabled and that's ok, too.