cc @golang/runtime

There is only so much that can FuncForPC can do when the compiler must introduce wrappers. In this case, the wrapper main.main.func1 is to introduce the dictionary argument before calling Contains.

Similar situations occur without generics. For example:

package main

import (
	"reflect"
	"runtime"
)

type T struct {
	a int
}

func (t T) M() int {
	return t.a
}

func main() {
	var t T
	ptr := reflect.ValueOf(t.M).Pointer()
	println(runtime.FuncForPC(ptr).Name())
}

prints main.T.M-fm, not main.T.M. This "-fm" thingy is a wrapper which makes a function from a method (aka a method value).

FuncForPC is a very low-level API and exposes a lot of the internal workings of the compiler/runtime. Generally its use is discouraged in favor of using runtime.Callers. runtime.Callers/runtime.CallersFrames does work correctly, as it is in a position to correctly compensate for wrappers/inlining/etc.

If you're trying to introspect a function closure without calling it, then unfortunately runtime.Callers isn't an option. But I don't think that introspection is possible to do in a way that fixes this bug, unfortunately.

package main

import (
	"fmt"
	"runtime"
)

func Contains[E any](list []E, e E) {
	var pcs [10]uintptr
	n := runtime.Callers(1, pcs[:])
	frames := runtime.CallersFrames(pcs[:n])
	for {
		frame, more := frames.Next()
		fmt.Printf("%s\n", frame.Function)
		if !more {
			break
		}
	}
}

func main() {
	Contains[string](nil, "")
}

reports

main.Contains[...]
main.main
runtime.main
runtime.goexit

Change https://go.dev/cl/416455 mentions this issue: cmd/compile,runtime: use better line numbers and names for wrappers

FWIW, at tip, the test program https://go.dev/play/p/DNXU3SaUlSK?v=gotip now prints:

main.ContainsStringItem
main.Contains[...]

This is because of the switch to GOEXPERIMENT=unified.

(Misclicked.)