New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: escape analysis of interface calls to unexported method names #16001

Open
mdempsky opened this Issue Jun 8, 2016 · 0 comments

Comments

Projects
None yet
1 participant
@mdempsky
Member

mdempsky commented Jun 8, 2016

Consider this Go source:

package p

import "fmt"

type A int
func (A) f(x *int) { fmt.Println("A", *x) }

type B int
func (B) f(x *int) { fmt.Println("B", *x) }
func (B) g() {}

type Fer interface { f(x *int); g() }

func H(f Fer) {
    i := 42
    f.f(&i)
}

At the f.f(&i) call site in H, we can't be sure exactly what method will be called. However, since it's an unexported method name, it must be implemented by a method in the same package. Consequently, if we know that all candidate methods in the package are non-escaping (such as A.f and B.f are), we can still be sure that f.f(&i) is a non-escaping call.

Note that we still have to consider A.f even though A itself doesn't implement Fer, because a downstream package could do something like:

package q

import "p"

type X struct { p.B }
type Y struct { p.A; X }

func Z() {
    p.H(Y{})
}

There are probably refinements that could avoid this though.

I happened to notice this because of package net's "exchange" function, which calls the unexported TCPConn.dnsRoundTrip or UDPConn.dnsRoundTrip methods. I haven't investigated how common this situation is though.

/cc @dr2chase @alandonovan

@mdempsky mdempsky added this to the Unplanned milestone Jun 8, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment