go, branch go1.12.1

[release-branch.go1.12] go1.12.1

2019-03-14T19:18:42Z

Change-Id: Id5f76204b8cd3fe67c21c5adfd3a4e456a8cad14 Reviewed-on: https://go-review.googlesource.com/c/go/+/167704 Run-TryBot: Andrew Bonventre TryBot-Result: Gobot Gobot Reviewed-by: Katie Hockman Reviewed-by: Dmitri Shuralyov

[release-branch.go1.12] doc: document Go 1.12.1

2019-03-14T18:14:22Z

Change-Id: I6d3a615c5f72e9aa29d23e127af98d6e836da173 Reviewed-on: https://go-review.googlesource.com/c/go/+/167699 Reviewed-by: Brad Fitzpatrick (cherry picked from commit f832a97e454a5e2bed336321965fd2382b2af868) Reviewed-on: https://go-review.googlesource.com/c/go/+/167702 Reviewed-by: Andrew Bonventre

[release-branch.go1.12] doc: document Go 1.11.6

2019-03-14T18:11:22Z

Change-Id: I99832fa4f2c3ec28e2dad46cf7607f3766948031 Reviewed-on: https://go-review.googlesource.com/c/go/+/167698 Reviewed-by: Brad Fitzpatrick (cherry picked from commit d3bb45d9046bb7d12c4fc9cdaf122f36d001fd31) Reviewed-on: https://go-review.googlesource.com/c/go/+/167701

Revert "[release-branch.go1.12] cmd/go: fix the default build output name for versioned binaries"

2019-03-14T16:39:37Z

This reverts commit 746edd459d26f07f69fcb6bddfafaaae7c5a2911 (CL 167384). Reason for revert: Dmitri identified a potential problem in https://go-review.googlesource.com/c/go/+/140863/11#message-db0ff6bb2c7b06161ca47de771c4465afa8b1102, and we'd like more time to investigate without holding up the 1.12 release branch. Updates #27283 Updates #30266 Updates #30821 Change-Id: I49d7bbbe200e80b81899c3bcbf7844717af010aa Reviewed-on: https://go-review.googlesource.com/c/go/+/167617 Reviewed-by: Andrew Bonventre

[release-branch.go1.12] cmd/cgo: use explicit type for arg with bad pointer typedef

2019-03-13T21:25:42Z

Fixes #30816 Updates #30646 Change-Id: I5b7e986b0588e87b9781cce01445e3c55c06b6fc Reviewed-on: https://go-review.googlesource.com/c/go/+/165897 Run-TryBot: Ian Lance Taylor Reviewed-by: Brad Fitzpatrick TryBot-Result: Gobot Gobot (cherry picked from commit a6436a5655f56bb904871fece7db43a3ad3bf415) Reviewed-on: https://go-review.googlesource.com/c/go/+/167497 Run-TryBot: Brad Fitzpatrick

[release-branch.go1.12] cmd/go: fix the default build output name for versioned binaries

2019-03-13T21:18:41Z

`go build` has chosen the last element of the package import path as the default output name when -o option is given. That caused the output of a package build when the module root is the major version component such as 'v2'. A similar issue involving `go install` was fixed in https://golang.org/cl/128900. This CL refactors the logic added with the change and makes it available as internal/load.DefaultExecName. This CL makes 'go test' to choose the right default test binary name when the tested package is in the module root. (E.g., instead of v2.test, choose pkg.test for the test of 'path/pkg/v2') Fixes #27283 Fixes #30266 Change-Id: I6905754f0906db46e3ce069552715f45356913ae Reviewed-on: https://go-review.googlesource.com/c/go/+/140863 Reviewed-by: Bryan C. Mills (cherry picked from commit bf94fc3ae387fc09929443393741919fac6727af) Reviewed-on: https://go-review.googlesource.com/c/go/+/167384 Run-TryBot: Brad Fitzpatrick Reviewed-by: Brad Fitzpatrick TryBot-Result: Gobot Gobot

[release-branch.go1.12] text/template: error on method calls on nil interfaces

2019-03-13T21:00:26Z

Trying to call a method on a nil interface is a panic in Go. For example: var stringer fmt.Stringer println(stringer.String()) // nil pointer dereference In https://golang.org/cl/143097 we started recovering panics encountered during function and method calls. However, we didn't handle this case, as text/template panics before evalCall is ever run. In particular, reflect's MethodByName will panic if the receiver is of interface kind and nil: panic: reflect: Method on nil interface value Simply add a check for that edge case, and have Template.Execute return a helpful error. Note that Execute shouldn't just error if the interface contains a typed nil, since we're able to find a method to call in that case. Finally, add regression tests for both the nil and typed nil interface cases. Fixes #30464. Change-Id: Iffb21b40e14ba5fea0fcdd179cd80d1f23cabbab Reviewed-on: https://go-review.googlesource.com/c/161761 Run-TryBot: Daniel Martí TryBot-Result: Gobot Gobot Reviewed-by: Emmanuel Odeke (cherry picked from commit 15b4c71a912846530315c3e854feaaa9d0d54220) Reviewed-on: https://go-review.googlesource.com/c/go/+/164457 Reviewed-by: Brad Fitzpatrick

[release-branch.go1.12] cmd/compile: make KeepAlive work on stack object

2019-03-13T20:59:47Z

Currently, runtime.KeepAlive applied on a stack object doesn't actually keeps the stack object alive, and the heap object referenced from it could be collected. This is because the address of the stack object is rematerializeable, and we just ignored KeepAlive on rematerializeable values. This CL fixes it. Updates #30476. Fixes #30478. Change-Id: Ic1f75ee54ed94ea79bd46a8ddcd9e81d01556d1d Reviewed-on: https://go-review.googlesource.com/c/164537 Run-TryBot: Cherry Zhang TryBot-Result: Gobot Gobot Reviewed-by: Keith Randall (cherry picked from commit 40df9cc6062492cd323f2251dd1583d200d1207e) Reviewed-on: https://go-review.googlesource.com/c/go/+/164627

[release-branch.go1.12] cmd/cgo: simplify and fix handling of untyped constants

2019-03-13T20:57:52Z

Instead of trying to guess type of constants in the AST, which is hard, use the "var cgo%d Type = Constant" so that typechecking is left to the Go compiler. The previous code could still fail in some cases for constants imported from other modules or defined in other, non-cgo files. Fixes #30527 Change-Id: I2120cd90e90a74b9d765eeec53f6a3d2cfc1b642 Reviewed-on: https://go-review.googlesource.com/c/go/+/164897 Run-TryBot: Emmanuel Odeke TryBot-Result: Gobot Gobot Reviewed-by: Ian Lance Taylor (cherry picked from commit 711ea1e716b0c620cd9bcdd405eccae230d6dcbb) Reviewed-on: https://go-review.googlesource.com/c/go/+/165748 Run-TryBot: Ian Lance Taylor Reviewed-by: Emmanuel Odeke Reviewed-by: Brad Fitzpatrick

[release-branch.go1.12] fmtsort: sort interfaces deterministically

2019-03-13T20:16:13Z

Previously, the result of sorting a map[interface{}] containing multiple concrete types was non-deterministic. To ensure consistent results, sort first by type name, then by concrete value. Fixes #30484 Change-Id: I10fd4b6a74eefbc87136853af6b2e689bc76ae9d GitHub-Last-Rev: 1b07f0c275716e1b2834f74f9c67f897bae82882 GitHub-Pull-Request: golang/go#30406 Reviewed-on: https://go-review.googlesource.com/c/163745 Reviewed-by: Rob Pike Reviewed-by: Keith Randall Run-TryBot: Keith Randall TryBot-Result: Gobot Gobot (cherry picked from commit 9d40fadb1c3245a318b155ee3e19a4de139401dc) Reviewed-on: https://go-review.googlesource.com/c/go/+/164617 Run-TryBot: Brad Fitzpatrick Reviewed-by: Brad Fitzpatrick