Skip to content

fix(moonbit)!: separate exported resource objects from handles - #1742

Draft
peter-jerry-ye wants to merge 5 commits into
bytecodealliance:mainfrom
peter-jerry-ye:codex/moonbit-managed-resources
Draft

peter-jerry-ye wants to merge 5 commits into
bytecodealliance:mainfrom
peter-jerry-ye:codex/moonbit-managed-resources

Conversation

@peter-jerry-ye

@peter-jerry-ye peter-jerry-ye commented Oct 12, 2026 •

Copy link
Copy Markdown
Contributor

Exported resource methods and destructors receive resource representations, but the MoonBit bindings currently wrap those values as handles. Calling rep() on them can trap or resolve the wrong resource.

This change keeps the original resource name, such as Counter, for the application-defined object and generates an opaque CounterHandle for owned exported resources. Generated array storage translates incoming representations to objects without a hash table. Constructors return objects, including Result[Counter, E] for fallible constructors; adapters register successful results. Handle methods forward to the object implementation, including async methods.

Ownership transfer invalidates the handle wrapper and its aliases. Destruction releases the storage slot before application cleanup, allowing cleanup to allocate or destroy other resources safely. Imported resources keep their existing type and method names, with opaque representations and generated conversion helpers for use across packages.

This is a breaking change to generated MoonBit source interfaces; the WIT interface and component ABI are unchanged. The migration guide explains constructors, ownership, visibility, and cleanup. It distinguishes method computation, explicit background children, and returned endpoint producers: each needs ownership through its own lifetime. The body example labels its collection-before-destruction requirement and explains the additional abandonment policy a production API needs.

Existing resource fixtures retain ordinary call and transfer coverage. The borrowed-record fixture gains a MoonBit implementation; the payload fixture covers nested ownership, async forwarding, collection errors, and cancellation, with a Rust cancellation control. The focused exported-resource-lifecycle fixture covers fallible construction, alias invalidation, reentrant slot reuse, background ownership with explicit completion, and started versus unstarted producer cleanup. A code-generation fixture covers generated-name collisions across interfaces; unsupported collisions in Rust, C++, and D use the existing expected-failure mechanism. The lifecycle runner is MoonBit, so other language jobs do not select it without its implementation.

Production changes remain confined to the MoonBit generator. Broader async API and runtime collection redesigns are deferred.

Fixes #1724.

@peter-jerry-ye
peter-jerry-ye force-pushed the codex/moonbit-managed-resources branch from e9f84f3 to d40dde6 Compare October 20, 2026 08:07
@peter-jerry-ye
peter-jerry-ye force-pushed the codex/moonbit-managed-resources branch from 9db1e57 to 1675284 Compare October 21, 2026 06:53

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

moonbit: self of exported resource methods and dtor is a rep, but rep() treats it as a handle and traps

1 participant