working with gc types

[oovm]

Add Canonical ABI options to support passing parameters by reference type

• Close Working with GC types without copy #305

[oovm]

I realized that the discriminant actually is required for variants that have multiple arms of the same type, like:

variant either-list {
    left(list<u8>),
    right(list<u8>),
}

In this case, both left and right would have the same (ref eq) subtype.

@fitzgen It occurred to me that the method compiled to (ref eq) still exists, that is, each variant is actually a new type.

If a language went the (enum, ref null eq) route, then the binding might look like (rust pseudocode):

enum Variants {
    Null,                 // (0, 0, 0)
    Bool { value: i32 },  // (1, i32, 0)
    U64 { value: i64 },   // (2, i64) , flatten i64 to i32 + i32
    I64 { value: i64 },   // (3, i64) , flatten i64 to i32 + i32
}

impl Variants {
    fn is_bool(&self) -> bool {
        match self {
            Variants::Bool { value } => true,
            _ => false,
        }
    }
}

If a language took the (ref eq) route, then the binding might look like (C# pseudocode):

// (struct $variants)
abstract class Variants
{
    // (struct $None)
    // (ref eq $variants)
    class Null : Variants
    {
        public override bool isBool()
        {
            return false;
        }
    }
    // (struct $Bool (field value i32))
    // (ref eq $variants)
    class Bool : Variants
    {
        int value;

        public override bool isBool()
        {
            return true;
        }
    }

    // (struct $U64 (field value u64))
    // (ref eq $variants)
    class U64 : Variants
    {
        long value;

        public override bool isBool()
        {
            return false;
        }
    }
    // (struct $U64 (field value i64))
    // (ref eq $variants)
    class I64 : Variants
    {
        int value;

        public override bool isBool()
        {
            return false;
        }
    }

    // virtual table pointer
    public abstract bool isBool();

    // static method
    public static bool isBool(Variants v)
    {
        switch (v)
        {
            case Null _:
                return false;
            case Bool _:
                return true;
            case U64 _:
                return false;
            case I64 _:
                return false;
            default:
                throw new Exception("unreachable");
        }
    }
}

These languages are more likely to implement variant determination through virtual tables

• X is Variants
• X is Variants::None
• X is Variants::Bool
• X is Variants::U64
• X is Variants::I64

I think it would also help to achieve: #136

[lukewagner]

I think the right place to put this spec information is in CanonicalABI.md (along-side the current spec information for how non-gc works) and in canonical-abi/definitions.py (which has the benefit that you can write tests for it in run_tests.py)

[oovm]

I don't know how to rewrite definitions.py. The binary needs to reference an index of an already defined type.

[lukewagner]

Since definitions.py is not a complete Python reference implementation but, rather, just a "suggestive" subset that describes just the lifting/lowering/built-in rules, what we do is, for canon definitions that take a typeidx in the binary format, we have the corresponding canon_* Python function take a Python object that directly represents the type (e.g., see how canon_lift takes a FuncType directly). That being said, I don't think there are any cases where you'll need to take a core wasm gc type as an immediate -- core wasm types are programmatically derived from component-level types by, e.g., flatten_functype which is called by canon_lift and canon_lower. Thus, I think you just need to add CoreArrayType and CoreStructType Python classes (analogous to CoreFuncType) so they can be created by flatten_functype in the appropriate cases when cx.opts.gc is true (which you'd also add to CanonicalOptions.

[lukewagner]

Thanks for starting this! I left a few comments and requests above.

[oovm]

reference-type now focuses on the mapping of three heap types: string, array, and struct.

The reference types corresponding to option, result, variants have been moved to #325

[kevmoo]

Super excited about the possibilities here. What's the status?

[oovm]

• The mapping of struct <-> record, struct <-> tuple, list <-> array has been agreed upon.
• For enum and flags, no mapping is required.
• For variant and string, there are objections and they have been removed from the proposal.

---

The unprepared part is mainly the implementation of the python validator (definitions.py), which has recently changed.

I have not been able to spend too much time on implementing this part recently due to my employer, so I am very sorry.