From 4d89a557857789bfdde23397fad6438b0c52e38e Mon Sep 17 00:00:00 2001 From: Felix Sausmikat <50841330+Felix-El@users.noreply.github.com> Date: Tue, 21 Apr 2026 01:31:25 +0200 Subject: [PATCH 1/4] Add bounded lists (list) via opcode 0x6c Cherry-picked the essence of cpetig's commit d2874eba526cdba442a9a4125b213b01df7b371c from https://github.com/cpetig/component-model/tree/bounded-lists, adapted to the current codebase (ptr_type/opts threading, updated class names). Bounded strings are intentionally excluded. Co-authored-by: Christof Petig --- design/mvp/Binary.md | 147 ++++++++++++------------ design/mvp/canonical-abi/definitions.py | 78 ++++++++++--- design/mvp/canonical-abi/run_tests.py | 10 ++ 3 files changed, 143 insertions(+), 92 deletions(-) diff --git a/design/mvp/Binary.md b/design/mvp/Binary.md index 508f870f..569d166d 100644 --- a/design/mvp/Binary.md +++ b/design/mvp/Binary.md @@ -87,12 +87,12 @@ sort ::= 0x00 cs: => co | 0x03 => type | 0x04 => component | 0x05 => instance -inlineexport ::= na: si: => (export na si) +inlineexport ::= n: si: => (export n si) ``` Notes: * Reused Core binary rules: [`core:name`], (variable-length encoded) [`core:u32`] * The `core:sort` values are chosen to match the discriminant opcodes of - [`core:externtype`]. + [`core:importdesc`]. * `type` is added to `core:sort` in anticipation of the [type-imports] proposal. Until that proposal, core modules won't be able to actually import or export types, however, the `type` sort is allowed as part of outer aliases (below). @@ -101,8 +101,8 @@ Notes: for aliases (below). * Validation of `core:instantiatearg` initially only allows the `instance` sort, but would be extended to accept other sorts as core wasm is extended. -* Validation of `instantiate` requires each `` in `c` to match a - `name` in a `with` argument (using plain string equality) and for the types to +* Validation of `instantiate` requires each `` in `c` to match a + `name` in a `with` argument (compared as strings) and for the types to match. * When validating `instantiate`, after each individual type-import is supplied via `with`, the actual type supplied is immediately substituted for all uses @@ -116,23 +116,24 @@ Notes: (See [Alias Definitions](Explainer.md#alias-definitions) in the explainer.) ```ebnf -alias ::= s: 0x00 i: n: => (alias export i n (s)) - | s: 0x01 i: n: => (alias core export i n (s)) - | s: 0x02 ct: idx: => (alias outer ct idx (s)) (if s in outeraliassort) +alias ::= s: t: => (alias t (s)) +aliastarget ::= 0x00 i: n: => export i n + | 0x01 i: n: => core export i n + | 0x02 ct: idx: => outer ct idx ``` Notes: * Reused Core binary rules: (variable-length encoded) [`core:u32`] -* For (`core`) `export` aliases, `i` is validated to refer to a (core) instance - in the (core) instance index space that exports `n` with the specified `sort`. -* For `outer` aliases: - * `ct` is validated to be *less than or equal to* the number of enclosing - "scopes" (where a "scope" is one of: a `component` definition, a `component` - type, an `instance` type) - * `i` is validated to be a valid index in the `s` index space of the target - scope (counting outward, starting with `0` referring to the current scope) - * if `ct` is greater than 0 and crosses a component (as opposed to type) - boundary and `s` is `type`, the target type may not transitively refer to a - resource type. +* For `export` aliases, `i` is validated to refer to an instance in the + instance index space that exports `n` with the specified `sort`. +* For `outer` aliases, `ct` is validated to be *less or equal than* the number + of enclosing `component`s and `type`s and `i` is validated to be a valid index + in the `sort` index space of the targeted `component`/`type` (counting + outward, starting with `0` referring to the current `component`/`type`). +* For `outer` aliases, validation restricts the `sort` to one of `type`, + `module` or `component`. +* For `outer` aliases that reach across a `component` boundary (as opposed to + a `type` boundary), validation additionally requires that any outer-aliased + `type` does not transitively refer to a `resource` type. ## Type Definitions @@ -148,12 +149,13 @@ core:moduledecl ::= 0x00 i: => i | 0x01 t: => t | 0x02 a: => a | 0x03 e: => e -core:alias ::= 0x10 0x01 ct: idx: => (alias outer ct idx (type)) +core:alias ::= s: t: => (alias t (s)) +core:aliastarget ::= 0x01 ct: idx: => outer ct idx core:importdecl ::= i: => i -core:exportdecl ::= n: t: => (export n t) +core:exportdecl ::= n: d: => (export n d) ``` Notes: -* Reused Core binary rules: [`core:import`], [`core:externtype`], +* Reused Core binary rules: [`core:import`], [`core:importdesc`], [`core:rectype`] * Unfortunately, the `core:deftype` rule results in an encoding ambiguity: the `0x50` opcode is used by both `core:moduletype` and a non-final @@ -169,9 +171,8 @@ Notes: core type index space will not contain any core module types. * As described in the explainer, each module type is validated with an initially-empty type index space. -* In `core:alias`, the first `0x10` is the opcode for `type` in `core:sort` and - `0x01` is an opcode to distinguish `outer` aliases from potential future - `export` aliases. +* `alias` declarators currently only allow `outer` `type` aliases but + would add `export` aliases when core wasm adds type exports. ```ebnf type ::= dt: => (type dt) @@ -200,8 +201,8 @@ defvaltype ::= pvt: => pvt | 0x70 t: => (list t) | 0x67 t: len: => (list t len) (if len > 0) πŸ”§ | 0x6f t*:vec() => (tuple t+) (if |t*| > 0) - | 0x6e l*:vec() => (flags l+) (if 0 < |l*| <= 32) - | 0x6d l*:vec() => (enum l+) (if |l*| > 0) + | 0x6e l*:vec() => (flags l+) (if 0 < |l*| <= 32) + | 0x6d l*:vec() => (enum l+) (if |l*| > 0) | 0x6b t: => (option t) | 0x6a t?:? u?:? => (result t? (error u)?) | 0x69 i: => (own i) @@ -209,9 +210,9 @@ defvaltype ::= pvt: => pvt | 0x66 t?:? => (stream t?) πŸ”€ | 0x65 t?:? => (future t?) πŸ”€ | 0x63 k: v: => (map k v) (if k is in ) πŸ—ΊοΈ -labelvaltype ::= l: t: => l t -case ::= l: t?:? 0x00 => (case l t?) -labellit ::= len: l: