tolumide-ng requested wasmtime-core-reviewers for a review on PR #12805.
tolumide-ng requested cfallin for a review on PR #12805.
tolumide-ng opened PR #12805 from tolumide-ng:fix/wasmtime-c-api-gc-update to bytecodealliance:main:
The
c-apicrate currently enables thegcfeature on itswasmtimedependency, even though it exposes agcfeature to control this behaviour. This prevents downstream users from disablinggc, sinceCargo.tomldoesn't allow overriding it. However, structs likeRootScopeare only available whengcis enabled. Removing it from default features, without other options, would break internal implementations.Changes
- Enable the
gcfeature via the wasmtime-c-api crate by default.- Removes the explicitly set
gcfeature for thewasmtimedependency inc-api, thus enabling downstream users to specify this behaviour.Closes https://github.com/bytecodealliance/wasmtime/issues/12783
github-actions[bot] added the label wasmtime:c-api on PR #12805.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Oh for this the
defaultfeature lives here instead which includesgc, so I think it's reasonable to just from[dependencies]
tolumide-ng requested wasmtime-default-reviewers for a review on PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng created PR review comment:
Thank you for your response @alexcrichton, I am missing part of your suggestion here. Do you mean removing
gcas a default feature in' wasmtime/Cargo. toml' and adding#[cfg(feature = "gc")]to the affected parts?
tolumide-ng submitted PR review.
tolumide-ng updated PR #12805.
tolumide-ng requested alexcrichton for a review on PR #12805.
alexcrichton created PR review comment:
We generally prefer to avoid having conditionally-noop functions like this, so this'll want some different treatment to handle the GC feature being disabled. The general shape of things is:
- Rust-defined functions are entirely
#[cfg]'d away, aka there's a#[cfg]on the method itself (or the containing module if applicable)- The C header needs a
#ifdefguard to see ifWASMTIME_FEATURE_GCis enabled.That way when the
gcfeature is disabled the functions "disappear" as opposed to being present but not actually doing anything (which can be confusing). Would you be up for refactoring in that style?
alexcrichton created PR review comment:
This is an example file where when
gcis disabled the entire module may wish to disappear vs having lots of#[cfg]internally.
alexcrichton created PR review comment:
I feel it would be best to avoid the duplication here (and in a number of locations). Handling this will be a bit tricky though due to
to_valwanting aRootScope. Thinking a bit about this, I think a way to thread this needle would be:
- Conditionally define
to_valbased on thegcfeature -- if it's enabled it's as-is, and if it's disabled the argument is justimpl AsContextMut(e.g. drop theRootScope)- For methods using
to_valuse the pattern#[cfg(feature = "gc")] let mut store = RootScope::new(&mut store);-- that way it shadows thestorelocal variable meaning thatto_valworks both with/without thegcfeature.how's that sound?
alexcrichton submitted PR review:
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.
tolumide-ng commented on PR #12805:
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.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng created PR review comment:
This makes sense. I'd do that
tolumide-ng submitted PR review.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng submitted PR review.
tolumide-ng created PR review comment:
Yes, done. Thank you
tolumide-ng created PR review comment:
I'm not exactly sure what you mean here. There are some functions where the
gcfeature does not apply, and some other modules depend on the macros. I'd be happy to retry with more clarification.
tolumide-ng submitted PR review.
tolumide-ng requested alexcrichton for a review on PR #12805.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Similar to above, this entire
AnyReftype is safe to go away when GC is disabled
alexcrichton created PR review comment:
For this the entire
ExternReftype should be#define'd away when GC is disabled
alexcrichton created PR review comment:
This
#ifdefshould be fine to extend to this entirestructblock asExternRefwill go away when GC is disabled.
alexcrichton created PR review comment:
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 created PR review comment:
For this you can use one
#ifdeffor an entire group of functions, e.g. everything related toexternrefandanyref, and both of those types' functions should be entirely gone when the GC feature is disabled
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng submitted PR review.
tolumide-ng created PR review comment:
Thank you for the clarification. The errors mostly emanate from:
- crates/c-api/src/table.rs:2:82 where it's mostly used as
fnarguments or return types.- crates/c-api/src/val.rs:3:43 where
wasm_val_unionhas*mut wasm_ref_tin its fields.
tolumide-ng edited PR review comment.
tolumide-ng requested alexcrichton for a review on PR #12805.
alexcrichton submitted PR review:
It looks like some merge conflicts have cropped up as well, I'd recommend rebasing and seeing how to resolve those as well.
alexcrichton created PR review comment:
For
table.rsthat's ok to exclude those functions when GC is disabled, and forval.rsthe union will have fewer fields when GC is disabled and that's ok, too.
alexcrichton created PR review comment:
Would it be possible to make the definition of
wasmtime_{any,extern}ref_tconditional based onWASMTIME_FEATURE_GC?
tolumide-ng submitted PR review.
tolumide-ng created PR review comment:
I'd update this right away, thank you
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng updated PR #12805.
tolumide-ng requested alexcrichton for a review on PR #12805.
alexcrichton submitted PR review:
Thanks!
alexcrichton added PR #12805 Enable gc feature by default to the merge queue.
github-merge-queue[bot] removed PR #12805 Enable gc feature by default from the merge queue.
tolumide-ng commented on PR #12805:
Thanks!
You're welcome. Thank you for the reviews and your patience.
Last updated: Apr 13 2026 at 00:25 UTC