Skip to content
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: esc.go fails to mark anonymous receiver parameters as non-escaping #24305

Open
mdempsky opened this issue Mar 7, 2018 · 7 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@mdempsky
Copy link
Contributor

mdempsky commented Mar 7, 2018

package p

type T struct { x int }

//go:noinline
func (*T) M() {}  

//go:noinline
func (_ *T) N() {}

func f() {
        var t T
        t.M()
        t.N()
        (*T).M(&t)
        (*T).N(&t)
}

Compiling the above code with "go tool compile -m" outputs:

a.go:13:3: t escapes to heap
a.go:12:6: moved to heap: t
a.go:14:3: t escapes to heap
a.go:15:9: &t escapes to heap
a.go:16:9: &t escapes to heap

This doesn't happen if the receiver parameters are given a proper name, or if the receiver parameters are turned into normal parameters (i.e., changing the methods into functions).

The direct calls (t.M() and t.N()) are because (*EscState).esctag's unnamed parameter loop only touches fn.Type.Params(), not fn.Type.Recvs().

The indirect calls ((*T).M(&t) and (*T).N(&t)) appear to be because esc.go just doesn't look for esc tags for methods called as functions.

@mdempsky mdempsky added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 7, 2018
@mdempsky mdempsky added this to the Go1.11 milestone Mar 7, 2018
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/99335 mentions this issue: cmd/compile: mark anonymous receiver parameters as non-escaping

gopherbot pushed a commit that referenced this issue Mar 8, 2018
This was already done for normal parameters, and the same logic
applies for receiver parameters too.

Updates #24305.

Change-Id: Ia2a46f68d14e8fb62004ff0da1db0f065a95a1b7
Reviewed-on: https://go-review.googlesource.com/99335
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@dr2chase
Copy link
Contributor

This looks fixed. Any problems with closing?

@mdempsky mdempsky reopened this Jun 22, 2018
@mdempsky
Copy link
Contributor Author

mdempsky commented Jun 22, 2018

This is half fixed. (*T).M(&t) and (*T).N(&t) still escape.

@dr2chase
Copy link
Contributor

Still for 1.11, or do we put off to 1.12?

@dr2chase
Copy link
Contributor

Doesn't this have the obvious user workaround of applying the local purely local rewrite of (*T).M(&t) into (&t).M(), which can actually be written t.M()?

I'd like to postpone this to unplanned.

@mdempsky mdempsky modified the milestones: Go1.11, Unplanned Jun 25, 2018
@mdempsky
Copy link
Contributor Author

Still an issue with newescape.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/248217 mentions this issue: cmd/compile: mark receiver in indirect calls as non-escaping

gopherbot pushed a commit that referenced this issue Aug 15, 2020
Updates #24305

Change-Id: Ib0b093e33004a978467cdd1e77186798392d4eca
Reviewed-on: https://go-review.googlesource.com/c/go/+/248217
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

3 participants