cmd/link: removing deadcode check for reflect.Value.Call causes miscompilation

[mdempsky]

This program now panics at master due to CL 228792:

package main

import "reflect"

type foo struct {}
func (foo) X() { println("ok") }

var h = reflect.Type.Method

func main() {
	v := reflect.ValueOf(foo{})
	m := h(v.Type(), 0)
	m.Func.Call([]reflect.Value{v})
}

It should print "ok".

/cc @cherrymui @bradfitz

[mdempsky]

This program failed even before CL 228792:

package main

import "reflect"

type foo struct {}
func (foo) X(x ...int) { println("ok") }

var h = reflect.Type.Method

func main() {
	v := reflect.ValueOf(foo{})
	m := h(v.Type(), 0)
	m.Func.CallSlice([]reflect.Value{v, reflect.ValueOf([]int(nil))})
}

[mdempsky]

I think as a short-term workaround, we should revert CL 228792, and also add a check for reflect.Value.CallSlice, and add these as regress tests.

Longer term, we should figure out how to make the reflection-use analysis more precise without compromising soundness.

[mdempsky]

Observation: Changing

var h = reflect.Type.Method

to

var h = (interface { Method(int) reflect.Method }).Method

causes the test cases to pass, even with CL 228792.

It looks like what's happening is the ReflectMethod check doesn't work within package reflect itself. While compiling a package, localpkg.Path will be "", not it's actual package path (e.g., "reflect").

Changing s.Pkg.Path == "reflect" to s.Pkg.Path == "reflect" || s.Pkg == localpkg && myimportpath == "reflect" seems like it might work.

[mvdan]

CC @cherrymui

[bradfitz]

This program failed even before CL 228792:

@mdempsky, thanks! Nice! That was the program I was trying to write that prompted my golang-dev post.

In playground form: https://play.golang.org/p/8L3UVmShhQf (showing that a Call anywhere else makes it work fine in Go 1.14)

[cuonglm]

Changing s.Pkg.Path == "reflect" to s.Pkg.Path == "reflect" || s.Pkg == localpkg && myimportpath == "reflect" seems like it might work.

@mdempsky How about using Type.LongString():

diff --git a/src/cmd/compile/internal/gc/walk.go b/src/cmd/compile/internal/gc/walk.go
index 06910450ff..7b9dee746a 100644
--- a/src/cmd/compile/internal/gc/walk.go
+++ b/src/cmd/compile/internal/gc/walk.go
@@ -3657,8 +3657,8 @@ func usemethod(n *Node) {
        }

        // Note: Don't rely on res0.Type.String() since its formatting depends on multiple factors
-       //       (including global variables such as numImports - was issue #19028).
-       if s := res0.Type.Sym; s != nil && s.Name == "Method" && s.Pkg != nil && s.Pkg.Path == "reflect" {
+       //       (including global variables such as numImports - was issue #19028)
+       if s := res0.Type.Sym; s != nil && res0.Type.LongString() == "reflect.Method" {
                Curfn.Func.SetReflectMethod(true)
        }
 }

[cherrymui]

Yeah, actually I was thinking about this the other day. It looks like the compiler only marks direct call to reflect.Type.Method, but not call by function pointers. And reflect.Value.Call doesn't really matter, as you could get a method and do other things with it without actually call it, and the method should be live in this case as well. I'm thinking there could be a different way of doing it.

[gopherbot]

Change https://golang.org/cl/228879 mentions this issue: cmd/link: handle indrect call of reflect.Type.Method in deadcode pass

[mdempsky]

@cuonglm I wouldn't think that would fix the test cases. Does it?

@cherrymui I don't think the linker should be involved in checking for interface wrapper methods. There can be many wrappers semantically equivalent to reflect.Type.Method (as a method expression) in different packages, and only the compiler can detect them all correctly.

[cuonglm]

@mdempsky it does, I have a patch in my local, do you want to take a look?

[cuonglm]

@mdempsky it does, I have a patch in my local, do you want to take a look?

Ah, sorry, I haven’t tested with the CallSlice case.

[cuonglm]

@mdempsky it does, I have a patch in my local, do you want to take a look?

Ah, sorry, I haven’t tested with the CallSlice case.

It does pass.

[mdempsky]

@cuonglm Oh, right, LongString uses package name, not package path.

No, I don't think that's a desirable change. It's not likely to cause problems in practice, but that can lead to false positives. We always want to identify standard library packages by path, not name.

[cherrymui]

Yeah, I think you're probably right. There could be more method wrappers, like

type I interface { Method(int) reflect.Method }
I.Method

It seems those wrapper functions actually do have REFLECTMETHOD set. Only reflect.Type.Method itself. Maybe we just didn't check the package name correctly, then.