Proposal: add support for mocking generic functions and methods

[xhd2015]

Generic functions and methods are currently skipped because their generic definition is just a template, there is no function instrumentation emitted until concrete types have been decided.

But since we use source code rewritting instead of IR rewritting for stdlib functions(see #6), it should be easy to also use source code rewritting for intercepting generic method and functions.

Generic function example:

package mock_generic_func

import (
	"context"
	"net/http"
	"testing"

	"github.com/xhd2015/xgo/runtime/core"
	"github.com/xhd2015/xgo/runtime/mock"
)

func ToString[T any](v T) string {
    return fmt.Sprint(v)
}

func TestMockGenericFunc(t *testing.T) {
	mock.Mock(ToString[int], func(ctx context.Context, fn *core.FuncInfo, args, results core.Object) error {
		results.GetFieldIndex(0).Set("hello world")
		return nil
	})
        expect := "hello world"
        output := ToString(0)
	if expect != output {
		t.Fatalf("expect ToString[int](0) to be %s, actual: %s", expect, output)
	}
}

Generic method example:

package mock_generic_method

import (
	"context"
	"net/http"
	"testing"

	"github.com/xhd2015/xgo/runtime/core"
	"github.com/xhd2015/xgo/runtime/mock"
)

type Formatter[T any] struct {
    prefix T
}

func (c *Formatter[T]) Format(v T) string {
    return fmt.Sprintf("%v: %v", c.prefix, v)
}

func TestMockGenericMethod(t *testing.T) {
       formatter := &Formatter[int]{ prefix: 1 }
	mock.Mock(formatter.Format, func(ctx context.Context, fn *core.FuncInfo, args, results core.Object) error {
		results.GetFieldIndex(0).Set("hello world")
		return nil
	})
        expect := "hello world"
        output := formatter.Format(0)
	if expect != output {
		t.Fatalf("expect ToString[int](0) to be %s, actual: %s", expect, output)
	}
}

What about MockByName and MockMethodByName ? Still works, the name can still be referenced without any type parameter.

Are we going to support per-type parameter mock? Seems no, but we can provide type parameter infos to the user to decide the concrete type. Or, user can just type assert the receiver or arguments or results to check what actual type parameter is.

[xhd2015]

This has been done, see commit 0f3164c.

Side note: for go1.20~go1.22, adding generic support is easy.
However, for go1.18 and go1.19, there is much workaround because the implementation of generic instantiation in these two versions is based on closure.

One workaround can be found at here https://github.com/xhd2015/xgo/blob/master/patch/adapter_go1.18_19.go#:~:text=isClosureWrapperForGeneric