Thanks for the careful review.

Given that reflect.Type is widely used and reflect.Method is always going to be used inside the reflect package, I think the thing to do here is look to see if the program ever calls an interface method with either of the signatures:

Method(int) reflect.Method
MethodByName(string) (reflect.Method, bool)

and treat the existence of those calls as equivalent to reflect.Value.Call in the linker.

Now, to work out how to send that fact neatly to cmd/link...

reflect.makeMethodValue is also a canary here, but I guess too many things end up referring to that to be useful?

CL https://golang.org/cl/20489 mentions this issue.

For the record, another test case:

package main

import (
    "fmt"
    "reflect"
)

type MyType int

func (m MyType) UniqueMethodName() {
    fmt.Println("My unique method string")
}

var v MyType

func main() {
    reflect.ValueOf(v).Method(0).Interface().(func())()
}

CL https://golang.org/cl/20562 mentions this issue.

This is a test case distilled from #14771 that still crashes after applying the patch in the CL:

package main

import (
    "fmt"
    "reflect"
)

type Foo struct {
    Ptr func()
}

func (f *Foo) Bar() {
    fmt.Println("Hello, world!")
}

func main() {
    f := &Foo{}

    val := reflect.ValueOf(f).Elem()

    meth := val.Addr().MethodByName("Bar")
    valueField := val.FieldByName("Ptr")
    valueField.Set(meth)

    f.Ptr()
}

@rasky which CL are you applying? I would expect that case to be caught by cl/20562. (Because the implementation of reflect.Value.MethodByName calls reflect.Value.Method.)