go, branch go1.15.3

[release-branch.go1.15] go1.15.3

2020-10-14T19:10:41Z

Change-Id: I8a45870039d0d3f210d883c464a7fed2abd9e28b Reviewed-on: https://go-review.googlesource.com/c/go/+/262337 Run-TryBot: Alexander Rakoczy Reviewed-by: Dmitri Shuralyov TryBot-Result: Go Bot Trust: Alexander Rakoczy

[release-branch.go1.15] cmd/compile: fix left shift constant folding rule

2020-10-14T15:13:22Z

The 32-bit left shift constant folding rule should keep its result properly sign extended. Fixes #41720 Fixes #41711 Change-Id: I0fc74444d444274e911952e1725dab0b7737a846 Reviewed-on: https://go-review.googlesource.com/c/go/+/258817 Trust: Keith Randall Run-TryBot: Keith Randall Reviewed-by: David Chase TryBot-Result: Go Bot

[release-branch.go1.15] runtime: correct signature of call16

2020-10-14T15:11:41Z

The signature of call16 is currently missing the "typ" parameter. This CL fixes this. This wasn't caught by vet because call16 is defined by macro expansion (see #17544), and we didn't notice the mismatch with the other call* functions because call16 is defined only on 32-bit architectures and lives alone in stubs32.go. Unfortunately, this means its GC signature is also wrong: the "arg" parameter is treated as a scalar rather than a pointer, so GC won't trace it and stack copying won't adjust it. This turns out to matter in exactly one case right now: on 32-bit architectures (which are the only architectures where call16 is defined), a stack-allocated defer of a function with a 16-byte or smaller argument frame including a non-empty result area can corrupt memory if the deferred function grows the stack and is invoked during a panic. Whew. All other current uses of reflectcall pass a heap-allocated "arg" frame (which happens to be reachable from other stack roots, so tracing isn't a problem). Curiously, in 2016, the signatures of all call* functions were wrong in exactly this way. CL 31654 fixed all of them in stubs.go, but missed the one in stubs32.go. Updates #41795. Fixes #41797. Change-Id: I31e3c0df201f79ee5707eeb8dc4ff0d13fc10ada Reviewed-on: https://go-review.googlesource.com/c/go/+/259338 Trust: Austin Clements Run-TryBot: Austin Clements TryBot-Result: Go Bot Reviewed-by: Cherry Zhang Reviewed-on: https://go-review.googlesource.com/c/go/+/259598

[release-branch.go1.15] cmd/compile: export notinheap annotation to object file

2020-10-12T15:15:57Z

In the rare case when a cgo type makes it into an object file, we need the go:notinheap annotation to go with it. Fixes #41432. Change-Id: Ie2ef241ee49661792e0d8c8c46c51b2fe5c6fa7c Reviewed-on: https://go-review.googlesource.com/c/go/+/259300 Trust: Keith Randall Reviewed-by: Ian Lance Taylor Reviewed-by: Cherry Zhang

[release-branch.go1.15] cmd/compile: propagate go:notinheap implicitly

2020-10-09T17:25:48Z

//go:notinheap type T int type U T We already correctly propagate the notinheap-ness of T to U. But we have an assertion in the typechecker that if there's no explicit //go:notinheap associated with U, then report an error. Get rid of that error so that implicit propagation is allowed. Adjust the tests so that we make sure that uses of types like U do correctly report an error when U is used in a context that might cause a Go heap allocation. Update #41432 Change-Id: I1692bc7cceff21ebb3f557f3748812a40887118d Reviewed-on: https://go-review.googlesource.com/c/go/+/255637 Run-TryBot: Keith Randall Reviewed-by: Cuong Manh Le Reviewed-by: Ian Lance Taylor Trust: Cuong Manh Le TryBot-Result: Go Bot (cherry picked from commit 22053790fa2c0944df53ea95df476ad2f855424f) Reviewed-on: https://go-review.googlesource.com/c/go/+/255697 Trust: Keith Randall Reviewed-by: Austin Clements

[release-branch.go1.15] cmd/compile: make go:notinheap error message friendlier for cgo

2020-10-09T17:25:25Z

Update #40954 Change-Id: Ifaab7349631ccb12fc892882bbdf7f0ebf3d845f Reviewed-on: https://go-review.googlesource.com/c/go/+/251158 Run-TryBot: Keith Randall Reviewed-by: Ian Lance Taylor TryBot-Result: Go Bot Trust: Keith Randall Reviewed-on: https://go-review.googlesource.com/c/go/+/255338 Reviewed-by: Austin Clements

[release-branch.go1.15] cmd/cgo: use go:notinheap for anonymous structs

2020-10-09T17:25:11Z

They can't reasonably be allocated on the heap. Not a huge deal, but it has an interesting and useful side effect. After CL 249917, the compiler and runtime treat pointers to go:notinheap types as uintptrs instead of real pointers (no write barrier, not processed during stack scanning, ...). That feature is exactly what we want for cgo to fix #40954. All the cases we have of pointers declared in C, but which might actually be filled with non-pointer data, are of this form (JNI's jobject heirarch, Darwin's CFType heirarchy, ...). Fixes #40954 Change-Id: I44a3b9bc2513d4287107e39d0cbbd0efd46a3aae Reviewed-on: https://go-review.googlesource.com/c/go/+/250940 Run-TryBot: Emmanuel Odeke TryBot-Result: Go Bot Trust: Keith Randall Reviewed-by: Ian Lance Taylor Reviewed-on: https://go-review.googlesource.com/c/go/+/255321

[release-branch.go1.15] cmd/compile: allow aliases to go:notinheap types

2020-10-09T17:24:56Z

The alias doesn't need to be marked go:notinheap. It gets its notinheap-ness from the target type. Without this change, the type alias test in the notinheap.go file generates these two errors: notinheap.go:62: misplaced compiler directive notinheap.go:63: type nih must be go:notinheap The first is a result of go:notinheap pragmas not applying to type alias declarations. The second is the result of then trying to match the notinheap-ness of the alias and the target type. Add a few more go:notinheap tests while we are here. Update #40954 Change-Id: I067ec47698df6e9e593e080d67796fd05a1d480f Reviewed-on: https://go-review.googlesource.com/c/go/+/250939 Run-TryBot: Keith Randall TryBot-Result: Go Bot Reviewed-by: Emmanuel Odeke Trust: Keith Randall Reviewed-on: https://go-review.googlesource.com/c/go/+/255337 Trust: Emmanuel Odeke Reviewed-by: Austin Clements

[release-branch.go1.15] cmd/compile: don't allow go:notinheap on the heap or stack

2020-10-09T17:24:33Z

Right now we just prevent such types from being on the heap. This CL makes it so they cannot appear on the stack either. The distinction between heap and stack is pretty vague at the language level (e.g. it is affected by -N), and we don't need the flexibility anyway. Once go:notinheap types cannot be in either place, we don't need to consider pointers to such types to be pointers, at least according to the garbage collector and stack copying. (This is the big win of this CL, in my opinion.) The distinction between HasPointers and HasHeapPointer no longer exists. There is only HasPointers. This CL is cleanup before possible use of go:notinheap to fix #40954. Update #13386 Change-Id: Ibd895aadf001c0385078a6d4809c3f374991231a Reviewed-on: https://go-review.googlesource.com/c/go/+/255320 Trust: Keith Randall Reviewed-by: Austin Clements Reviewed-by: Matthew Dempsky

[release-branch.go1.15] cmd/compile: make Haspointers a method instead of a function

2020-10-09T17:24:07Z

More ergonomic that way. Also change Haspointers to HasPointers while we are here. Change-Id: I45bedc294c1a8c2bd01dc14bd04615ae77555375 Reviewed-on: https://go-review.googlesource.com/c/go/+/249959 Run-TryBot: Keith Randall TryBot-Result: Gobot Gobot Reviewed-by: Emmanuel Odeke Reviewed-by: Matthew Dempsky Reviewed-on: https://go-review.googlesource.com/c/go/+/255318 Trust: Keith Randall Reviewed-by: Austin Clements