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: returning arguments should not cause their escape #32019

Closed
eliasnaur opened this issue May 14, 2019 · 2 comments
Closed

cmd/compile: returning arguments should not cause their escape #32019

eliasnaur opened this issue May 14, 2019 · 2 comments

Comments

@eliasnaur
Copy link
Contributor

@eliasnaur eliasnaur commented May 14, 2019

What version of Go are you using (go version)?

$ go version
go version devel +2e4edf4697 Sun May 12 07:14:09 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

$ cat escape.go 
package escape

type F struct {
}

func (f *F) Do() *F {
        // ... mutate f ...
	return f
}
$ go build -gcflags="-m -l" escape.go 
# command-line-arguments
./escape.go:6:7: leaking param: f to result ~r0 level=0

What did you expect to see?

That f does not escape.

What did you see instead?

f escapes.

I suppose a fix for this issue will also cover returning arguments and not just the method receiver, but the above simplified case matches my use better (method chaining).

@eliasnaur eliasnaur changed the title cmd/compile: returning arguments should not escape cmd/compile: returning arguments should not cause their escape May 14, 2019
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 14, 2019

We currently only compile (*F).Do once. And somebody might write

var V *F
func DoIt(f *F) {
    V = f.Do()
}

So I don't see how to avoid this escape. Other than compiling the method in two different ways, and choosing the implementation based on whether the result escapes.

@eliasnaur

This comment has been minimized.

Copy link
Contributor Author

@eliasnaur eliasnaur commented May 14, 2019

I see, thanks. I still have the inliner to fall back on.

@eliasnaur eliasnaur closed this May 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.