Remove the explicit gc feature from the wasmtime dependency in the c-api crate

[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.

Changes

1. Removes the explicitly set gc feature for the wasmtime dependency in c-api, thus enabling downstream users to specify this behaviour.
2. Adds ci job for building the c-api crate without default features, and with the gc feature

Note

This introduces a breaking change for downstream users who may not have explicitly enabled the gc feature on the c-api crate but rely on it.

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.

[alexcrichton]

Thanks!

[tolumide-ng]

Thanks!

You're welcome. Thank you for the reviews and your patience.

[tolumide-ng]

I updated the title and description of this PR to reflect the changes this PR introduces