Add partial wasm codegen for token definitions#155
Open
rvcas wants to merge 4 commits into
Open
Conversation
Replace the token codegen stub with real Component-Model output, mirroring the existing `utxo` codegen: - Generalize the resource machinery: rename UtxoContext/current_utxo to ResourceContext/current_resource and make generate_storage_exports take (name, ty) so tokens and utxos share it. - `mint fn` is compiled as a constructor: it spawns a fresh token resource at entry (reusing the UtxoMain spawn path in visit_function) and returns an owned token handle, exported as `[static]token.<name>`. - Storage globals are emitted with the same `storage` record plus `get-storage`/`set-storage` exports as utxos. - Lower `Type::TokenAny`/`Type::TokenNamed` to an i32 core handle (the `_ => Err` fallthrough in star_to_core_types previously missed them). `burn`, the `impl Token` `attach`/`detach` methods, and plain helpers are compiled and validated but not exported yet: - TODO(token-burn): the WIT shape of `burn` is undecided. - TODO(token-impl-export): `attach`/`detach` take a `Utxo`, i.e. a foreign resource referenced from inside the token interface. The current resource-index model conflates it with the token's own resource, so the emitted WIT would be wrong; this needs cross-resource index handling. `indexed` storage is carried inert. Adds token_mint / token_mint_burn codegen fixtures and updates the spec's token status note. Signed-off-by: rvcas <x@rvcas.dev>
Signed-off-by: rvcas <x@rvcas.dev>
Per design clarification: `mint`/`burn` carry no special wasm semantics — what they do is a runtime concern — so they are generated as ordinary functions distinguished only by export naming. - `mint fn` stays a `[static]token.<name>` constructor returning an owned token handle. - `burn fn` is now exported as a plain `[static]token.<name>` function with its declared signature (previously compiled but unexported). `impl Token`'s `attach`/`detach` remain compiled-but-unexported: their `Utxo` parameter is a foreign resource referenced from inside the token interface, which the current shared resource-index model mis-resolves to the token's own resource (it would emit `borrow<token>` instead of `borrow<utxo>`). Exporting them needs proper cross-resource references in the component encoder. Signed-off-by: rvcas <x@rvcas.dev>
`Token` is a built-in ABI, so `impl Token` is now generated exactly like a `utxo`'s `impl <Abi>`: each method is exported as a `[method]` on the token resource. This drops the earlier hold-back of attach/detach. The `Utxo` parameter of attach/detach renders as `borrow<token>` rather than `borrow<utxo>`. This is the same shared resource-index mechanism the utxo ABI-impl path already uses for foreign-resource parameters (it only looks correct for utxos because a utxo's own resource is itself named `utxo`), so it is a pre-existing general codegen limitation, not token-specific. Signed-off-by: rvcas <x@rvcas.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces the token codegen stub in
starstream-to-wasmwith real Component-Model output, mirroring the existingutxocodegen. For atoken MyToken { ... }it now emits:export my-token: interface { resource token { mint: static func() -> token; } record storage { supply: s32, ... } get-storage: func(self: borrow<token>) -> storage; set-storage: func(storage: storage) -> token; }What's emitted
mintis compiled as a constructor: it spawns a fresh token resource at entry (reusing theUtxoMainspawn path invisit_function) and returns an owned token handle, exported as[static]token.<name>. Multiple mints → multiple static constructors.storagerecord andget-storage/set-storageexports, identical to utxos.burn,impl Tokenattach/detach, and plain helpers are compiled and validated (real core functions, storage-checked) but not exported yet — see TODOs.Supporting changes
UtxoContext/current_utxo→ResourceContext/current_resource, andgenerate_storage_exportsnow takes(name, ty)so tokens and utxos share it (pure refactor).Type::TokenAny/Type::TokenNamedto an i32 core handle —star_to_core_typeshas a_ => Errfallthrough that previously missed them (compiled, but errored on a method'sselfparam).TODOs left (deliberately deferred)
TODO(token-burn)— the WIT shape ofburnis undecided (consuming[method]token.burn(self: own<token>)vs a resource-drop). Body compiled, not exported.TODO(token-impl-export)—attach/detachtake aUtxo, i.e. a foreign resource referenced from inside the token interface. The current resource-index model (raw indices shared withworld_type) conflates that borrow with the token's own resource, so exporting them produced wrong WIT (borrow<token>instead ofborrow<utxo>). Correctly emitting cross-resource references needs encoder index-space work; compiled-but-unexported until then.indexedstorage is carried inert (per team decision to handle later).starstream-runtime-next) has no token support; out of scope.