1
0
mirror of https://github.com/golang/go synced 2024-09-29 12:14:28 -06:00
go/test/fixedbugs/issue31573.go

50 lines
2.4 KiB
Go
Raw Normal View History

// errorcheck -0 -m
// Copyright 2019 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.
package p
func f(...*int) {} // ERROR "can inline f$"
func g() {
cmd/compile: use fixVariadicCall in escape analysis This CL uses fixVariadicCall before escape analyzing function calls. This has a number of benefits, though also some minor obstacles: Most notably, it allows us to remove ODDDARG along with the logic involved in setting it up, manipulating EscHoles, and later copying its escape analysis flags to the actual slice argument. Instead, we uniformly handle all variadic calls the same way. (E.g., issue31573.go is updated because now f() and f(nil...) are handled identically.) It also allows us to simplify handling of builtins and generic function calls. Previously handling of calls was hairy enough to require multiple dispatches on n.Op, whereas now the logic is uniform enough that we can easily handle it with a single dispatch. The downside is handling //go:uintptrescapes is now somewhat clumsy. (It used to be clumsy, but it still is, too.) The proper fix here is probably to stop using escape analysis tags for //go:uintptrescapes and unsafe-uintptr, and have an earlier pass responsible for them. Finally, note that while we now call fixVariadicCall in Escape, we still have to call it in Order, because we don't (yet) run Escape on all compiler-generated functions. In particular, the generated "init" function for initializing package-level variables can contain calls to variadic functions and isn't escape analyzed. Passes toolstash-check -race. Change-Id: I4cdb92a393ac487910aeee58a5cb8c1500eef881 Reviewed-on: https://go-review.googlesource.com/c/go/+/229759 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2020-04-21 20:48:02 -06:00
defer f()
defer f(new(int)) // ERROR "... argument does not escape$" "new\(int\) does not escape$"
defer f(new(int), new(int)) // ERROR "... argument does not escape$" "new\(int\) does not escape$"
defer f(nil...)
defer f([]*int{}...) // ERROR "\[\]\*int literal does not escape$"
defer f([]*int{new(int)}...) // ERROR "\[\]\*int literal does not escape$" "new\(int\) does not escape$"
defer f([]*int{new(int), new(int)}...) // ERROR "\[\]\*int literal does not escape$" "new\(int\) does not escape$"
cmd/compile: use fixVariadicCall in escape analysis This CL uses fixVariadicCall before escape analyzing function calls. This has a number of benefits, though also some minor obstacles: Most notably, it allows us to remove ODDDARG along with the logic involved in setting it up, manipulating EscHoles, and later copying its escape analysis flags to the actual slice argument. Instead, we uniformly handle all variadic calls the same way. (E.g., issue31573.go is updated because now f() and f(nil...) are handled identically.) It also allows us to simplify handling of builtins and generic function calls. Previously handling of calls was hairy enough to require multiple dispatches on n.Op, whereas now the logic is uniform enough that we can easily handle it with a single dispatch. The downside is handling //go:uintptrescapes is now somewhat clumsy. (It used to be clumsy, but it still is, too.) The proper fix here is probably to stop using escape analysis tags for //go:uintptrescapes and unsafe-uintptr, and have an earlier pass responsible for them. Finally, note that while we now call fixVariadicCall in Escape, we still have to call it in Order, because we don't (yet) run Escape on all compiler-generated functions. In particular, the generated "init" function for initializing package-level variables can contain calls to variadic functions and isn't escape analyzed. Passes toolstash-check -race. Change-Id: I4cdb92a393ac487910aeee58a5cb8c1500eef881 Reviewed-on: https://go-review.googlesource.com/c/go/+/229759 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2020-04-21 20:48:02 -06:00
go f()
go f(new(int)) // ERROR "... argument escapes to heap$" "new\(int\) escapes to heap$"
go f(new(int), new(int)) // ERROR "... argument escapes to heap$" "new\(int\) escapes to heap$"
go f(nil...)
go f([]*int{}...) // ERROR "\[\]\*int literal escapes to heap$"
go f([]*int{new(int)}...) // ERROR "\[\]\*int literal escapes to heap$" "new\(int\) escapes to heap$"
go f([]*int{new(int), new(int)}...) // ERROR "\[\]\*int literal escapes to heap$" "new\(int\) escapes to heap$"
for {
cmd/compile: use fixVariadicCall in escape analysis This CL uses fixVariadicCall before escape analyzing function calls. This has a number of benefits, though also some minor obstacles: Most notably, it allows us to remove ODDDARG along with the logic involved in setting it up, manipulating EscHoles, and later copying its escape analysis flags to the actual slice argument. Instead, we uniformly handle all variadic calls the same way. (E.g., issue31573.go is updated because now f() and f(nil...) are handled identically.) It also allows us to simplify handling of builtins and generic function calls. Previously handling of calls was hairy enough to require multiple dispatches on n.Op, whereas now the logic is uniform enough that we can easily handle it with a single dispatch. The downside is handling //go:uintptrescapes is now somewhat clumsy. (It used to be clumsy, but it still is, too.) The proper fix here is probably to stop using escape analysis tags for //go:uintptrescapes and unsafe-uintptr, and have an earlier pass responsible for them. Finally, note that while we now call fixVariadicCall in Escape, we still have to call it in Order, because we don't (yet) run Escape on all compiler-generated functions. In particular, the generated "init" function for initializing package-level variables can contain calls to variadic functions and isn't escape analyzed. Passes toolstash-check -race. Change-Id: I4cdb92a393ac487910aeee58a5cb8c1500eef881 Reviewed-on: https://go-review.googlesource.com/c/go/+/229759 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2020-04-21 20:48:02 -06:00
defer f()
defer f(new(int)) // ERROR "... argument escapes to heap$" "new\(int\) escapes to heap$"
defer f(new(int), new(int)) // ERROR "... argument escapes to heap$" "new\(int\) escapes to heap$"
defer f(nil...)
defer f([]*int{}...) // ERROR "\[\]\*int literal escapes to heap$"
defer f([]*int{new(int)}...) // ERROR "\[\]\*int literal escapes to heap$" "new\(int\) escapes to heap$"
defer f([]*int{new(int), new(int)}...) // ERROR "\[\]\*int literal escapes to heap$" "new\(int\) escapes to heap$"
cmd/compile: use fixVariadicCall in escape analysis This CL uses fixVariadicCall before escape analyzing function calls. This has a number of benefits, though also some minor obstacles: Most notably, it allows us to remove ODDDARG along with the logic involved in setting it up, manipulating EscHoles, and later copying its escape analysis flags to the actual slice argument. Instead, we uniformly handle all variadic calls the same way. (E.g., issue31573.go is updated because now f() and f(nil...) are handled identically.) It also allows us to simplify handling of builtins and generic function calls. Previously handling of calls was hairy enough to require multiple dispatches on n.Op, whereas now the logic is uniform enough that we can easily handle it with a single dispatch. The downside is handling //go:uintptrescapes is now somewhat clumsy. (It used to be clumsy, but it still is, too.) The proper fix here is probably to stop using escape analysis tags for //go:uintptrescapes and unsafe-uintptr, and have an earlier pass responsible for them. Finally, note that while we now call fixVariadicCall in Escape, we still have to call it in Order, because we don't (yet) run Escape on all compiler-generated functions. In particular, the generated "init" function for initializing package-level variables can contain calls to variadic functions and isn't escape analyzed. Passes toolstash-check -race. Change-Id: I4cdb92a393ac487910aeee58a5cb8c1500eef881 Reviewed-on: https://go-review.googlesource.com/c/go/+/229759 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2020-04-21 20:48:02 -06:00
go f()
go f(new(int)) // ERROR "... argument escapes to heap$" "new\(int\) escapes to heap$"
go f(new(int), new(int)) // ERROR "... argument escapes to heap$" "new\(int\) escapes to heap$"
go f(nil...)
go f([]*int{}...) // ERROR "\[\]\*int literal escapes to heap$"
go f([]*int{new(int)}...) // ERROR "\[\]\*int literal escapes to heap$" "new\(int\) escapes to heap$"
go f([]*int{new(int), new(int)}...) // ERROR "\[\]\*int literal escapes to heap$" "new\(int\) escapes to heap$"
}
}