Third-party imported type method is not callable from fast.Interp.Eval [gomacro repl works]

[Skird]

Third-party imported type method is not callable from fast.Interp.Eval [gomacro repl works]

[Skird]

One more interesting example from attempted workaround

package main

import (
	"fmt"
	"github.com/cosmos72/gomacro/fast"
	"github.com/holiman/uint256"
)

func main() {
	code := `
import (
	"github.com/holiman/uint256"
)

sign := uint256.Int.Sign

func Foo(x *uint256.Int) int {
	return sign(x)
}
`
	interp := fast.New()
	interp.Eval(code)

	foo := interp.ValueOf("Foo").Interface().(func(int2 *uint256.Int) int)

	z := uint256.NewInt(123)
	fmt.Println(foo(z))
}

Fails with

// debug: running "go get github.com/holiman/uint256" ...
go: added github.com/holiman/uint256 v1.2.1
// debug: running "go mod tidy" ...
// debug: compiling plugin "/home/divashchenko/go/src/gomacro.imports/gomacro_pid_37124/import_1" ...
panic: reflect.Value.Addr of unaddressable value

goroutine 1 [running]:
reflect.Value.Addr({0x17fe4e0?, 0xc0002cb2c0?, 0x1?})
        /usr/lib/go-1.19/src/reflect/value.go:271 +0x65
github.com/cosmos72/gomacro/xreflect.Value.Addr(...)
        /home/divashchenko/go/pkg/mod/github.com/cosmos72/[email protected]/xreflect/value.go:114
github.com/cosmos72/gomacro/fast.(*Comp).compileMethodAsFunc.func6({0xc0005965d0?, 0x1, 0x1})
        /home/divashchenko/go/pkg/mod/github.com/cosmos72/[email protected]/fast/selector.go:909 +0xbc
github.com/cosmos72/gomacro/xreflect.MakeFunc.func1({0xc0005965b8, 0x1, 0x1?})
        /home/divashchenko/go/pkg/mod/github.com/cosmos72/[email protected]/xreflect/wrap.go:39 +0xaa
reflect.Value.call({0x1658c20?, 0xc0002fbf70?, 0x7f3bfc913a68?}, {0x18027ed, 0x4}, {0xc0005965a0, 0x1, 0x1658c20?})
        /usr/lib/go-1.19/src/reflect/value.go:584 +0x8c5
reflect.Value.Call({0x1658c20?, 0xc0002fbf70?, 0xc0002b7830?}, {0xc0005965a0?, 0x100000000000475?, 0xc000197760?})
        /usr/lib/go-1.19/src/reflect/value.go:368 +0xbc
github.com/cosmos72/gomacro/xreflect.Value.Call({{0x1658c20?, 0xc0002fbf70?, 0x0?}}, {0xc000596588, 0x1, 0x92ddd2?})
        /home/divashchenko/go/pkg/mod/github.com/cosmos72/[email protected]/xreflect/value.go:127 +0x113
github.com/cosmos72/gomacro/fast.callxr({{0x1658c20?, 0xc0002fbf70?, 0xc0002cb2c0?}}, {0xc000596588, 0x1, 0x1})
        /home/divashchenko/go/pkg/mod/github.com/cosmos72/[email protected]/fast/call.go:453 +0x8e
github.com/cosmos72/gomacro/fast.(*Comp).callnret1.func2(0x17fe4e0?)
        /home/divashchenko/go/pkg/mod/github.com/cosmos72/[email protected]/fast/callnret1.go:58 +0xee
github.com/cosmos72/gomacro/fast.(*Comp).varSetExpr.func3(0xc0001da320)
        /home/divashchenko/go/pkg/mod/github.com/cosmos72/[email protected]/fast/var_set.go:2344 +0x2f
github.com/cosmos72/gomacro/fast.exec.func1(0xc0001da320?)
        /home/divashchenko/go/pkg/mod/github.com/cosmos72/[email protected]/fast/code.go:171 +0x236
github.com/cosmos72/gomacro/fast.(*Comp).funcGeneric.func2.1({0xc000596540, 0x1, 0x0?})
        /home/divashchenko/go/pkg/mod/github.com/cosmos72/[email protected]/fast/function.go:438 +0xf0
github.com/cosmos72/gomacro/xreflect.MakeFunc.func1({0xc000596528, 0x1, 0x1?})
        /home/divashchenko/go/pkg/mod/github.com/cosmos72/[email protected]/xreflect/wrap.go:39 +0xaa
main.main()
        /home/divashchenko/workspace/tmp/goplay/main.go:33 +0x7e

It seems that in fast/selector.go:843 it falls into wrong branch (with comment // method declared by interpreted code, manually retrieve it.). In following snippet

var x uint256.Int
interp := fast.New()
typ := interp.TypeOf(x)
fmt.Println(typ.ReflectType().NumMethod())

something strange happens with typ.ReflectType(), it has NumMethods() == 0.
Tried to dig into it a bit more with no luck, but I hope it hepls :)

[cosmos72]

Sorry for the very late answer.

Yes, it's definitely strange because running the same code directly from gomacro repl works:

import "github.com/holiman/uint256"

func Foo(x *uint256.Int) int {
	return x.Sign()
}

y := uint256.NewInt(123)
Foo(y)

produces the following output:

// debug: running "go get github.com/holiman/uint256" ...
go: added github.com/holiman/uint256 v1.2.4
// debug: running "go mod tidy" ...
// debug: compiling plugin "/home/max/go/src/gomacro.imports/gomacro_pid_17289/import_1" ...
1       // int

[cosmos72]

I am debugging this issue, and it's specific to methods attached to non-struct types.

Package github.com/holiman/uint256 defines type Int as follows:

type Int [4]uint64

then defines methods with pointer receiver *Int, as for example

func (z *Int) Sign() int {
  // ...
}

Which is perfectly legal, but less tested in gomacro than methods attached to structs.

Continuing the analysis...

[cosmos72]

Fixed in commit 960f329

It was a bug in method lookup: it checked for types that cannot have methods and failed early in such case,
but the logic for the early failure was bugged and worked by chance only if experimental generics were enabled.