go, branch go1.11.1

[release-branch.go1.11] go1.11.1

2018-10-01T20:59:20Z

Change-Id: I3cf3e57b11ad02b497276bae1864fc5ade8144b9 Reviewed-on: https://go-review.googlesource.com/138860 Run-TryBot: Katie Hockman TryBot-Result: Gobot Gobot Reviewed-by: Dmitri Shuralyov

[release-branch.go1.11] doc: document Go 1.11.1

2018-10-01T20:40:15Z

Updates #27953 Change-Id: I2f1a55e15dc5737a5a06bd894c46b2c4705f338c Reviewed-on: https://go-review.googlesource.com/138858 Reviewed-by: Filippo Valsorda (cherry picked from commit f99fc3a119dbb98fa9dddcb2e31a6c51925fde77) Reviewed-on: https://go-review.googlesource.com/138859 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.11] encoding/json: fix UnmarshalTypeError without field and struct values

2018-10-01T19:38:15Z

Updates #26444 Updates #27275 Fixes #27318 Change-Id: I9e8cbff79f7643ca8964c572c1a98172b6831730 GitHub-Last-Rev: 7eea2158b67ccab34b45a21e8f4289c36de02d93 GitHub-Pull-Request: golang/go#26719 Reviewed-on: https://go-review.googlesource.com/126897 Reviewed-by: Daniel Martí Run-TryBot: Daniel Martí TryBot-Result: Gobot Gobot Reviewed-on: https://go-review.googlesource.com/138178 Run-TryBot: Brad Fitzpatrick

[release-branch.go1.11] net: concatenate multiple TXT strings in single TXT record

2018-10-01T19:37:00Z

When go resolver was changed to use dnsmessage.Parser, LookupTXT returned two strings in one record as two different records. This change reverts back to concatenating multiple strings in a single TXT record. Updates #27763 Fixes #27886 Change-Id: Ice226fcb2be4be58853de34ed35b4627acb429ea Reviewed-on: https://go-review.googlesource.com/136955 Reviewed-by: Ian Gudger Reviewed-by: Brad Fitzpatrick Run-TryBot: Ian Gudger TryBot-Result: Gobot Gobot (cherry picked from commit 7b3b160323b56b357832549fbab7a60d27688ec1) Reviewed-on: https://go-review.googlesource.com/138177 Run-TryBot: Brad Fitzpatrick Reviewed-by: Katie Hockman

[release-branch.go1.11] reflect: fix s390x reflect method calls

2018-10-01T19:18:24Z

R0 isn't the zero register any more. Oops. Update #27867 Change-Id: I46a975ed37d5e570afe2e228d3edf74949e08ad7 Reviewed-on: https://go-review.googlesource.com/138580 Reviewed-by: Michael Munday Reviewed-on: https://go-review.googlesource.com/138583 Run-TryBot: Keith Randall Run-TryBot: Ian Lance Taylor Run-TryBot: Michael Munday TryBot-Result: Gobot Gobot Reviewed-by: Ian Lance Taylor

[release-branch.go1.11] reflect: ensure correct scanning of return values

2018-10-01T19:16:44Z

During a call to a reflect-generated function or method (via makeFuncStub or methodValueCall), when should we scan the return values? When we're starting a reflect call, the space on the stack for the return values is not initialized yet, as it contains whatever junk was on the stack of the caller at the time. The return space must not be scanned during a GC. When we're finishing a reflect call, the return values are initialized, and must be scanned during a GC to make sure that any pointers in the return values are found and their referents retained. When the GC stack walk comes across a reflect call in progress on the stack, it needs to know whether to scan the results or not. It doesn't know the progress of the reflect call, so it can't decide by itself. The reflect package needs to tell it. This CL adds another slot in the frame of makeFuncStub and methodValueCall so we can put a boolean in there which tells the runtime whether to scan the results or not. This CL also adds the args length to reflectMethodValue so the runtime can restrict its scanning to only the args section (not the results) if the reflect package says the results aren't ready yet. Do a delicate dance in the reflect package to set the "results are valid" bit. We need to make sure we set the bit only after we've copied the results back to the stack. But we must set the bit before we drop reflect's copy of the results. Otherwise, we might have a state where (temporarily) no one has a live copy of the results. That's the state we were observing in issue #27695 before this CL. The bitmap used by the runtime currently contains only the args. (Actually, it contains all the bits, but the size is set so we use only the args portion.) This is safe for early in a reflect call, but unsafe late in a reflect call. The test issue27695.go demonstrates this unsafety. We change the bitmap to always include both args and results, and decide at runtime which portion to use. issue27695.go only has a test for method calls. Function calls were ok because there wasn't a safepoint between when reflect dropped its copy of the return values and when the caller is resumed. This may change when we introduce safepoints everywhere. This truncate-to-only-the-args was part of CL 9888 (in 2015). That part of the CL fixed the problem demonstrated in issue27695b.go but introduced the problem demonstrated in issue27695.go. TODO, in another CL: simplify FuncLayout and its test. stack return value is now identical to frametype.ptrdata + frametype.gcdata. Update #27867 Change-Id: I2d49b34e34a82c6328b34f02610587a291b25c5f Reviewed-on: https://go-review.googlesource.com/137440 Run-TryBot: Keith Randall TryBot-Result: Gobot Gobot Reviewed-by: Austin Clements Reviewed-on: https://go-review.googlesource.com/138582 Run-TryBot: Ian Lance Taylor Reviewed-by: Ian Lance Taylor

[release-branch.go1.11] reflect: use correct write barrier operations for method funcs

2018-10-01T19:16:37Z

Fix the code to use write barriers on heap memory, and no write barriers on stack memory. These errors were discovered as part of fixing #27695. They may have something to do with that issue, but hard to be sure. The core cause is different, so this fix is a separate CL. Update #27867 Change-Id: Ib005f6b3308de340be83c3d07d049d5e316b1e3c Reviewed-on: https://go-review.googlesource.com/137438 Reviewed-by: Austin Clements (cherry picked from commit e35a41261b19589f40d32bd66274c23ab4b9b32e) Reviewed-on: https://go-review.googlesource.com/138581 Run-TryBot: Ian Lance Taylor TryBot-Result: Gobot Gobot Reviewed-by: Ian Lance Taylor

[release-branch.go1.11] doc: add go1.11 to contrib.html

2018-09-28T13:23:38Z

Missing from https://golang.org/project Change-Id: I6cb769ae861a81f0264bae624b5fe8d70aa92497 Reviewed-on: https://go-review.googlesource.com/138356 Reviewed-by: Chris Broadfoot

[release-branch.go1.11] cmd/go: add GOMIPS value to build id for mipsle

2018-09-27T22:04:44Z

Strip a trailing "le" from the GOARCH value when calculating the GOxxx environment variable that affects it. Updates #27260 Fixes #27420 Change-Id: I081f30d5dc19281901551823f4f56be028b5f71a Reviewed-on: https://go-review.googlesource.com/131379 Reviewed-by: Brad Fitzpatrick (cherry picked from commit 61318d7ffe8a49e9dedc5aa8195a164a3821465c) Reviewed-on: https://go-review.googlesource.com/138176 Run-TryBot: Brad Fitzpatrick TryBot-Result: Gobot Gobot Reviewed-by: Ian Lance Taylor

[release-branch.go1.11] net: fail fast for DNS rcode success with no answers of requested type

2018-09-27T21:41:40Z

DNS responses which do not contain answers of the requested type return errNoSuchHost, the same error as rcode name error. Prior to golang.org/cl/37879, both cases resulted in no additional name servers being consulted for the question. That CL changed the behavior for both cases. Issue #25336 was filed about the rcode name error case and golang.org/cl/113815 fixed it. This CL fixes the no answers of requested type case as well. Updates #27525 Fixes #27537 Change-Id: I52fadedcd195f16adf62646b76bea2ab3b15d117 Reviewed-on: https://go-review.googlesource.com/133675 Run-TryBot: Ian Gudger TryBot-Result: Gobot Gobot Reviewed-by: Brad Fitzpatrick (cherry picked from commit 94f48ddb96c4dfc919ae024f64df19d764f5fb5b) Reviewed-on: https://go-review.googlesource.com/138175 Run-TryBot: Brad Fitzpatrick Reviewed-by: Ian Lance Taylor