go/test/fixedbugs/issue12006.go

175 lines
3.9 KiB
Go
Raw Normal View History

// errorcheck -0 -m -l
// Copyright 2015 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Test escape analysis through ... parameters.
package foo
func FooN(vals ...*int) (s int) { // ERROR "vals does not escape"
for _, v := range vals {
s += *v
}
return s
}
// Append forces heap allocation and copies entries in vals to heap, therefore they escape to heap.
func FooNx(x *int, vals ...*int) (s int) { // ERROR "leaking param: x" "leaking param content: vals"
cmd/compile: allocate backing store for append on the stack When appending, if the backing store doesn't escape and a constant-sized backing store is big enough, use a constant-sized stack-allocated backing store instead of allocating it from the heap. cmd/go is <0.1% bigger. As an example of how this helps, if you edit strings/strings.go:FieldsFunc to replace spans := make([]span, 0, 32) with var spans []span then this CL removes the first 2 allocations that are part of the growth sequence: │ base │ exp │ │ allocs/op │ allocs/op vs base │ FieldsFunc/ASCII/16-24 3.000 ± ∞ ¹ 2.000 ± ∞ ¹ -33.33% (p=0.008 n=5) FieldsFunc/ASCII/256-24 7.000 ± ∞ ¹ 5.000 ± ∞ ¹ -28.57% (p=0.008 n=5) FieldsFunc/ASCII/4096-24 11.000 ± ∞ ¹ 9.000 ± ∞ ¹ -18.18% (p=0.008 n=5) FieldsFunc/ASCII/65536-24 18.00 ± ∞ ¹ 16.00 ± ∞ ¹ -11.11% (p=0.008 n=5) FieldsFunc/ASCII/1048576-24 30.00 ± ∞ ¹ 28.00 ± ∞ ¹ -6.67% (p=0.008 n=5) FieldsFunc/Mixed/16-24 2.000 ± ∞ ¹ 2.000 ± ∞ ¹ ~ (p=1.000 n=5) FieldsFunc/Mixed/256-24 7.000 ± ∞ ¹ 5.000 ± ∞ ¹ -28.57% (p=0.008 n=5) FieldsFunc/Mixed/4096-24 11.000 ± ∞ ¹ 9.000 ± ∞ ¹ -18.18% (p=0.008 n=5) FieldsFunc/Mixed/65536-24 18.00 ± ∞ ¹ 16.00 ± ∞ ¹ -11.11% (p=0.008 n=5) FieldsFunc/Mixed/1048576-24 30.00 ± ∞ ¹ 28.00 ± ∞ ¹ -6.67% (p=0.008 n=5) (Of course, people have spotted and fixed a bunch of allocation sites like this, but now we're ~automatically doing it everywhere going forward.) No significant increases in frame sizes in cmd/go. Change-Id: I301c4d9676667eacdae0058960321041d173751a Reviewed-on: https://go-review.googlesource.com/c/go/+/664299 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org>
2025-04-09 14:38:03 -07:00
vals = append(vals, x) // ERROR "append does not escape"
return FooN(vals...)
}
var sink []*int
cmd/compile: update escape analysis tests for newescape The new escape analysis implementation tries to emit debugging diagnostics that are compatible with the existing implementation, but there's a handful of cases that are easier to handle by updating the test expectations instead. For regress tests that need updating, the original file is copied to oldescapeXXX.go.go with -newescape=false added to the //errorcheck line, while the file is updated in place with -newescape=true and new test requirements. Notable test changes: 1) escape_because.go looks for a lot of detailed internal debugging messages that are fairly particular to how esc.go works and that I haven't attempted to port over to escape.go yet. 2) There are a lot of "leaking param: x to result ~r1 level=-1" messages for code like func(p *int) *T { return &T{p} } that were simply wrong. Here &T must be heap allocated unconditionally (because it's being returned); and since p is stored into it, p escapes unconditionally too. esc.go incorrectly reports that p escapes conditionally only if the returned pointer escaped. 3) esc.go used to print each "leaking param" analysis result as it discovered them, which could lead to redundant messages (e.g., that a param leaks at level=0 and level=1). escape.go instead prints everything at the end, once it knows the shortest path to each sink. 4) esc.go didn't precisely model direct-interface types, resulting in some values unnecessarily escaping to the heap when stored into non-escaping interface values. 5) For functions written in assembly, esc.go only printed "does not escape" messages, whereas escape.go prints "does not escape" or "leaking param" as appropriate, consistent with the behavior for functions written in Go. 6) 12 tests included "BAD" annotations identifying cases where esc.go was unnecessarily heap allocating something. These are all fixed by escape.go. Updates #23109. Change-Id: Iabc9eb14c94c9cadde3b183478d1fd54f013502f Reviewed-on: https://go-review.googlesource.com/c/go/+/170447 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2019-04-02 14:44:13 -07:00
func FooNy(x *int, vals ...*int) (s int) { // ERROR "leaking param: x" "leaking param: vals"
cmd/compile: allocate backing store for append on the stack When appending, if the backing store doesn't escape and a constant-sized backing store is big enough, use a constant-sized stack-allocated backing store instead of allocating it from the heap. cmd/go is <0.1% bigger. As an example of how this helps, if you edit strings/strings.go:FieldsFunc to replace spans := make([]span, 0, 32) with var spans []span then this CL removes the first 2 allocations that are part of the growth sequence: │ base │ exp │ │ allocs/op │ allocs/op vs base │ FieldsFunc/ASCII/16-24 3.000 ± ∞ ¹ 2.000 ± ∞ ¹ -33.33% (p=0.008 n=5) FieldsFunc/ASCII/256-24 7.000 ± ∞ ¹ 5.000 ± ∞ ¹ -28.57% (p=0.008 n=5) FieldsFunc/ASCII/4096-24 11.000 ± ∞ ¹ 9.000 ± ∞ ¹ -18.18% (p=0.008 n=5) FieldsFunc/ASCII/65536-24 18.00 ± ∞ ¹ 16.00 ± ∞ ¹ -11.11% (p=0.008 n=5) FieldsFunc/ASCII/1048576-24 30.00 ± ∞ ¹ 28.00 ± ∞ ¹ -6.67% (p=0.008 n=5) FieldsFunc/Mixed/16-24 2.000 ± ∞ ¹ 2.000 ± ∞ ¹ ~ (p=1.000 n=5) FieldsFunc/Mixed/256-24 7.000 ± ∞ ¹ 5.000 ± ∞ ¹ -28.57% (p=0.008 n=5) FieldsFunc/Mixed/4096-24 11.000 ± ∞ ¹ 9.000 ± ∞ ¹ -18.18% (p=0.008 n=5) FieldsFunc/Mixed/65536-24 18.00 ± ∞ ¹ 16.00 ± ∞ ¹ -11.11% (p=0.008 n=5) FieldsFunc/Mixed/1048576-24 30.00 ± ∞ ¹ 28.00 ± ∞ ¹ -6.67% (p=0.008 n=5) (Of course, people have spotted and fixed a bunch of allocation sites like this, but now we're ~automatically doing it everywhere going forward.) No significant increases in frame sizes in cmd/go. Change-Id: I301c4d9676667eacdae0058960321041d173751a Reviewed-on: https://go-review.googlesource.com/c/go/+/664299 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org>
2025-04-09 14:38:03 -07:00
vals = append(vals, x) // ERROR "append escapes to heap"
sink = vals
return FooN(vals...)
}
func FooNz(vals ...*int) (s int) { // ERROR "leaking param: vals"
sink = vals
return FooN(vals...)
}
func TFooN() {
for i := 0; i < 1000; i++ {
var i, j int
FooN(&i, &j) // ERROR "... argument does not escape"
}
}
func TFooNx() {
for i := 0; i < 1000; i++ {
var i, j, k int // ERROR "moved to heap: i" "moved to heap: j" "moved to heap: k"
FooNx(&k, &i, &j) // ERROR "... argument does not escape"
}
}
func TFooNy() {
for i := 0; i < 1000; i++ {
var i, j, k int // ERROR "moved to heap: i" "moved to heap: j" "moved to heap: k"
FooNy(&k, &i, &j) // ERROR "... argument escapes to heap"
}
}
func TFooNz() {
for i := 0; i < 1000; i++ {
var i, j int // ERROR "moved to heap: i" "moved to heap: j"
FooNz(&i, &j) // ERROR "... argument escapes to heap"
}
}
var isink *int32
func FooI(args ...interface{}) { // ERROR "leaking param content: args"
for i := 0; i < len(args); i++ {
switch x := args[i].(type) {
case nil:
println("is nil")
case int32:
println("is int32")
case *int32:
println("is *int32")
isink = x
case string:
println("is string")
}
}
}
func TFooI() {
a := int32(1) // ERROR "moved to heap: a"
b := "cat"
c := &a
cmd/compile/internal/escape: propagate constants to interface conversions to avoid allocs Currently, the integer value in the following interface conversion gets heap allocated: v := 1000 fmt.Println(v) In contrast, this conversion does not currently cause the integer value to be heap allocated: fmt.Println(1000) The second example is able to avoid heap allocation because of an optimization in walk (by Josh in #18704 and related issues) that recognizes a literal is being used. In the first example, that optimization is currently thwarted by the literal getting assigned to a local variable prior to use in the interface conversion. This CL propagates constants to interface conversions like in the first example to avoid heap allocations, instead using a read-only global. The net effect is roughly turning the first example into the second. One place this comes up in practice currently is with logging or debug prints. For example, if we have something like: func conditionalDebugf(format string, args ...interface{}) { if debugEnabled { fmt.Fprintf(io.Discard, format, args...) } } Prior to this CL, this integer is heap allocated, even when the debugEnabled flag is false, and even when the compiler inlines conditionalDebugf: v := 1000 conditionalDebugf("hello %d", v) With this CL, the integer here is no longer heap allocated, even when the debugEnabled flag is enabled, because the compiler can now see that it can use a read-only global. See the writeup in #71359 for more details. CL 649076 (earlier in our stack) added most of the tests along with debug diagnostics in convert.go to make it easier to test this change. Updates #71359 Updates #62653 Updates #53465 Updates #8618 Change-Id: I19a51e74b36576ebb0b9cf599267cbd2bd847ce4 Reviewed-on: https://go-review.googlesource.com/c/go/+/649079 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com>
2025-02-12 18:55:04 -05:00
FooI(a, b, c) // ERROR "a escapes to heap" ".cat. escapes to heap" "... argument does not escape"
}
func FooJ(args ...interface{}) *int32 { // ERROR "leaking param: args to result ~r0 level=1"
for i := 0; i < len(args); i++ {
switch x := args[i].(type) {
case nil:
println("is nil")
case int32:
println("is int32")
case *int32:
println("is *int32")
return x
case string:
println("is string")
}
}
return nil
}
func TFooJ1() {
a := int32(1)
b := "cat"
c := &a
cmd/compile/internal/escape: propagate constants to interface conversions to avoid allocs Currently, the integer value in the following interface conversion gets heap allocated: v := 1000 fmt.Println(v) In contrast, this conversion does not currently cause the integer value to be heap allocated: fmt.Println(1000) The second example is able to avoid heap allocation because of an optimization in walk (by Josh in #18704 and related issues) that recognizes a literal is being used. In the first example, that optimization is currently thwarted by the literal getting assigned to a local variable prior to use in the interface conversion. This CL propagates constants to interface conversions like in the first example to avoid heap allocations, instead using a read-only global. The net effect is roughly turning the first example into the second. One place this comes up in practice currently is with logging or debug prints. For example, if we have something like: func conditionalDebugf(format string, args ...interface{}) { if debugEnabled { fmt.Fprintf(io.Discard, format, args...) } } Prior to this CL, this integer is heap allocated, even when the debugEnabled flag is false, and even when the compiler inlines conditionalDebugf: v := 1000 conditionalDebugf("hello %d", v) With this CL, the integer here is no longer heap allocated, even when the debugEnabled flag is enabled, because the compiler can now see that it can use a read-only global. See the writeup in #71359 for more details. CL 649076 (earlier in our stack) added most of the tests along with debug diagnostics in convert.go to make it easier to test this change. Updates #71359 Updates #62653 Updates #53465 Updates #8618 Change-Id: I19a51e74b36576ebb0b9cf599267cbd2bd847ce4 Reviewed-on: https://go-review.googlesource.com/c/go/+/649079 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com>
2025-02-12 18:55:04 -05:00
FooJ(a, b, c) // ERROR "a does not escape" ".cat. does not escape" "... argument does not escape"
}
func TFooJ2() {
a := int32(1) // ERROR "moved to heap: a"
b := "cat"
c := &a
cmd/compile/internal/escape: propagate constants to interface conversions to avoid allocs Currently, the integer value in the following interface conversion gets heap allocated: v := 1000 fmt.Println(v) In contrast, this conversion does not currently cause the integer value to be heap allocated: fmt.Println(1000) The second example is able to avoid heap allocation because of an optimization in walk (by Josh in #18704 and related issues) that recognizes a literal is being used. In the first example, that optimization is currently thwarted by the literal getting assigned to a local variable prior to use in the interface conversion. This CL propagates constants to interface conversions like in the first example to avoid heap allocations, instead using a read-only global. The net effect is roughly turning the first example into the second. One place this comes up in practice currently is with logging or debug prints. For example, if we have something like: func conditionalDebugf(format string, args ...interface{}) { if debugEnabled { fmt.Fprintf(io.Discard, format, args...) } } Prior to this CL, this integer is heap allocated, even when the debugEnabled flag is false, and even when the compiler inlines conditionalDebugf: v := 1000 conditionalDebugf("hello %d", v) With this CL, the integer here is no longer heap allocated, even when the debugEnabled flag is enabled, because the compiler can now see that it can use a read-only global. See the writeup in #71359 for more details. CL 649076 (earlier in our stack) added most of the tests along with debug diagnostics in convert.go to make it easier to test this change. Updates #71359 Updates #62653 Updates #53465 Updates #8618 Change-Id: I19a51e74b36576ebb0b9cf599267cbd2bd847ce4 Reviewed-on: https://go-review.googlesource.com/c/go/+/649079 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com>
2025-02-12 18:55:04 -05:00
isink = FooJ(a, b, c) // ERROR "a escapes to heap" ".cat. escapes to heap" "... argument does not escape"
}
type fakeSlice struct {
l int
a *[4]interface{}
}
func FooK(args fakeSlice) *int32 { // ERROR "leaking param: args to result ~r0 level=1"
for i := 0; i < args.l; i++ {
switch x := (*args.a)[i].(type) {
case nil:
println("is nil")
case int32:
println("is int32")
case *int32:
println("is *int32")
return x
case string:
println("is string")
}
}
return nil
}
func TFooK2() {
a := int32(1) // ERROR "moved to heap: a"
b := "cat"
c := &a
cmd/compile/internal/escape: propagate constants to interface conversions to avoid allocs Currently, the integer value in the following interface conversion gets heap allocated: v := 1000 fmt.Println(v) In contrast, this conversion does not currently cause the integer value to be heap allocated: fmt.Println(1000) The second example is able to avoid heap allocation because of an optimization in walk (by Josh in #18704 and related issues) that recognizes a literal is being used. In the first example, that optimization is currently thwarted by the literal getting assigned to a local variable prior to use in the interface conversion. This CL propagates constants to interface conversions like in the first example to avoid heap allocations, instead using a read-only global. The net effect is roughly turning the first example into the second. One place this comes up in practice currently is with logging or debug prints. For example, if we have something like: func conditionalDebugf(format string, args ...interface{}) { if debugEnabled { fmt.Fprintf(io.Discard, format, args...) } } Prior to this CL, this integer is heap allocated, even when the debugEnabled flag is false, and even when the compiler inlines conditionalDebugf: v := 1000 conditionalDebugf("hello %d", v) With this CL, the integer here is no longer heap allocated, even when the debugEnabled flag is enabled, because the compiler can now see that it can use a read-only global. See the writeup in #71359 for more details. CL 649076 (earlier in our stack) added most of the tests along with debug diagnostics in convert.go to make it easier to test this change. Updates #71359 Updates #62653 Updates #53465 Updates #8618 Change-Id: I19a51e74b36576ebb0b9cf599267cbd2bd847ce4 Reviewed-on: https://go-review.googlesource.com/c/go/+/649079 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com>
2025-02-12 18:55:04 -05:00
fs := fakeSlice{3, &[4]interface{}{a, b, c, nil}} // ERROR "a escapes to heap" ".cat. escapes to heap" "&\[4\]interface {}{...} does not escape"
isink = FooK(fs)
}
func FooL(args []interface{}) *int32 { // ERROR "leaking param: args to result ~r0 level=1"
for i := 0; i < len(args); i++ {
switch x := args[i].(type) {
case nil:
println("is nil")
case int32:
println("is int32")
case *int32:
println("is *int32")
return x
case string:
println("is string")
}
}
return nil
}
func TFooL2() {
a := int32(1) // ERROR "moved to heap: a"
b := "cat"
c := &a
cmd/compile/internal/escape: propagate constants to interface conversions to avoid allocs Currently, the integer value in the following interface conversion gets heap allocated: v := 1000 fmt.Println(v) In contrast, this conversion does not currently cause the integer value to be heap allocated: fmt.Println(1000) The second example is able to avoid heap allocation because of an optimization in walk (by Josh in #18704 and related issues) that recognizes a literal is being used. In the first example, that optimization is currently thwarted by the literal getting assigned to a local variable prior to use in the interface conversion. This CL propagates constants to interface conversions like in the first example to avoid heap allocations, instead using a read-only global. The net effect is roughly turning the first example into the second. One place this comes up in practice currently is with logging or debug prints. For example, if we have something like: func conditionalDebugf(format string, args ...interface{}) { if debugEnabled { fmt.Fprintf(io.Discard, format, args...) } } Prior to this CL, this integer is heap allocated, even when the debugEnabled flag is false, and even when the compiler inlines conditionalDebugf: v := 1000 conditionalDebugf("hello %d", v) With this CL, the integer here is no longer heap allocated, even when the debugEnabled flag is enabled, because the compiler can now see that it can use a read-only global. See the writeup in #71359 for more details. CL 649076 (earlier in our stack) added most of the tests along with debug diagnostics in convert.go to make it easier to test this change. Updates #71359 Updates #62653 Updates #53465 Updates #8618 Change-Id: I19a51e74b36576ebb0b9cf599267cbd2bd847ce4 Reviewed-on: https://go-review.googlesource.com/c/go/+/649079 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com>
2025-02-12 18:55:04 -05:00
s := []interface{}{a, b, c} // ERROR "a escapes to heap" ".cat. escapes to heap" "\[\]interface {}{...} does not escape"
isink = FooL(s)
}