Trimming of `SumTypes`

[simsurace]

This is more of a question since I don't know if trimming support is even on the table for this package.

The following cannot be trimmed:

using SumTypes

@sum_type MySumtype begin
    V1
    V2
    V3
end

function (@main)(args::Vector{String})::Cint
    chosen = isempty(args) ? V1 : V2
    println(Core.stdout, chosen == V1)
    return 0
end

i.e. when running julia --project=@juliac -e 'using JuliaC; JuliaC.main(ARGS)' -- \ --output-exe mre --project . --trim=safe --experimental mre.jl one obtains:

Verifier error #1: unresolved call from statement (==)((getfield)(x::MySumtype, :data)::Union{SumTypes.Variant{:V1, (), Tuple{}}, SumTypes.Variant{:V2, (), Tuple{}}, SumTypes.Variant{:V3, (), Tuple{}}}, (getfield)(y::MySumtype, :data)::Union{SumTypes.Variant{:V1, (), Tuple{}}, SumTypes.Variant{:V2, (), Tuple{}}, SumTypes.Variant{:V3, (), Tuple{}}})::Bool
Stacktrace:
 [1] ==(x::MySumtype, y::MySumtype)
   @ Main ~/.julia/packages/SumTypes/aO6qd/src/sum_type.jl:294
 [2] main(args::Vector{String})
   @ Main /path/to/mre.jl:11 [inlined]
 [3] _main(argc::Int32, argv::Ptr{Ptr{Int8}})
   @ Main ~/.julia/juliaup/julia-1.12.7+0.x64.linux.gnu/share/julia/juliac/juliac-buildscript.jl:33

Verifier error #2: <identical to #1>

Trim verify finished with 2 errors, 0 warnings.

With two variants this trims fine. The behavior seems to be related to union splitting due to the generated Base.:(==)(x::T, y::T) = ==(unwrap(x), unwrap(y)) method. Manually defining Base.:(==)(x::MySumtype, y::MySumtype) = SumTypes.get_tag(x) === SumTypes.get_tag(y) makes this trim cleanly, but it wouldn't work for variants with data. In that case, something more complicated like

@sum_type Shape begin
    Circle(::Float64)
    # ...more shapes
end

function Base.:(==)(x::Shape, y::Shape)
    return @cases x begin
        Circle(a) => (@cases y begin
            Circle(b) => a == b
            _ => false
        end)
        # ...one branch per variant
    end
end

would need to be generated.

[MasonProtter]

Thanks! Yeah this was a missed optimization I'm surprised I never ran into when benchmarking. PR here: #86