This fix is less pervasive than it seems. The only change affecting
formatting is on printer.go:760. The remaining changes have no effect
on formatting since the value of p.level is ignored except on this
specific line.

The remaining changes are:
- renamed adjBlock to funcBody since that's how it is used
- introduced new printer field 'level' tracking the composite
  literal nesting level
- update/restore the composite literal nesting level as needed

Fixes #18782.

Change-Id: Ie833a9b5a559c4ec0f2eef2c5dc97aa263dca53a
Reviewed-on: https://go-review.googlesource.com/35811Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Modules appear in the moduledata linked list in the order they are
loaded by the dynamic loader, with one exception: the
firstmoduledata itself the module that contains the runtime.
This is not always the first module (when using -buildmode=shared,
it is typically libstd.so, the second module).

The order matters for typelinksinit, so we swap the first module
with whatever module contains the main function.

Updates #18729

This fixes the test case extracted with -linkshared, and now

	go test -linkshared encoding/...

passes. However the original issue about a plugin failure is not
yet fixed.

Change-Id: I9f399ecc3518e22e6b0a350358e90b0baa44ac96
Reviewed-on: https://go-review.googlesource.com/35644
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Slower builders were failing TestQueryContext because the cancel
and return to conn pool happens async. TestQueryContext already
uses a wait method for this reason. Use the same method for
other context tests.

Fixes #18759

Change-Id: I84cce697392b867e4ebdfadd38027a06ca14655f
Reviewed-on: https://go-review.googlesource.com/35750Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Update docs on correspondence between Go releases and GCC releases.

Update C type that corresponds to Go type `int`.

Drop out of date comments about Ubuntu and RTEMS.

Change-Id: Ic1b5ce9f242789af23ec3b7e7a64c9d257d6913e
Reviewed-on: https://go-review.googlesource.com/35631
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

You have to actually run make.bash (or make.bat).

Update #18771.

Change-Id: Ie6672a4e4abde0150c1ae57cabb1222de2c78716
Reviewed-on: https://go-review.googlesource.com/35632Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I6341b8cce0b4a9922928f73f8b459cbb9ec25e79
Reviewed-on: https://go-review.googlesource.com/35571Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

The presence of Request.GetBody being set on a request was causing all
redirected requests to have a body, even if the redirect status didn't
warrant one.

This bug came from 307/308 support (https://golang.org/cl/29852) which
removed the line that set req.Body to nil after POST/PUT redirects.

Change-Id: I2a4dd5320f810ae25cfd8ea8ca7c9700e5dbd369
Reviewed-on: https://go-review.googlesource.com/35633
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

Change-Id: I31fa5f906ad2e8dc475dbbeb91f568f91e16861b
Reviewed-on: https://go-review.googlesource.com/35514
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Otherwise we don't emit any required ELF relocations when doing an
external link, because elfrelocsect skips unreachable symbols.

Fixes #18745.

Change-Id: Ia3583c41bb6c5ebb7579abd26ed8689370311cd6
Reviewed-on: https://go-review.googlesource.com/35590
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

Fixes #18766

Change-Id: Ic0f72f3b7bbccd0546692993c4ed414f8c88c1c6
Reviewed-on: https://go-review.googlesource.com/35573Reviewed-by: Russ Cox <rsc@golang.org>

memmove used to use 2 2-byte load/store pairs to move 4 bytes.
When the result is loaded with a single 4-byte load, it caused
a store to load fowarding stall.  To avoid the stall,
special case memmove to use 4 byte ops for the 4 byte copy case.

We already have a special case for 8-byte copies.
386 already specializes 4-byte copies.
I'll do 2-byte copies also, but not for 1.8.

benchmark                 old ns/op     new ns/op     delta
BenchmarkIssue18740-8     7567          4799          -36.58%

3-byte copies get a bit slower.  Other copies are unchanged.
name         old time/op   new time/op   delta
Memmove/3-8   4.76ns ± 5%   5.26ns ± 3%  +10.50%  (p=0.000 n=10+10)

Fixes #18740

Change-Id: Iec82cbac0ecfee80fa3c8fc83828f9a1819c3c74
Reviewed-on: https://go-review.googlesource.com/35567
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

The constant propagation rules selected the wrong operand to
propagate. So MOVDNE (move if not equal) propagated operands as if
it were a MOVDEQ (move if equal).

Fixes #18735.

Change-Id: I87ac469172f9df7d5aabaf7106e2936ce54ae202
Reviewed-on: https://go-review.googlesource.com/35498
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This is needed for typical tests with gccgo, as it passes the
LD_LIBRARY_PATH environment variable to the new program.

Change-Id: I9bf4b0dbdff63f5449c7fcb8124eaeab10ed7f34
Reviewed-on: https://go-review.googlesource.com/35481
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

With GCC 7 (not yet released), cgo fails with errors like

./sigaltstack.go:65:8: call of non-function C.restoreSignalStack

I do not know precisely why. Explicitly declaring that there are no
arguments to the static function is a simple fix for the debug info.

Change-Id: Id96e1cb1e55ee37a9f1f5ad243d7ee33e71584ac
Reviewed-on: https://go-review.googlesource.com/35480
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When nilcheck runs, the values in a block are not in any particular
order.  So any facts derived from examining the blocks shouldn't be
used until we reach the next block.

This is suboptimal as it won't eliminate nil checks within a block.
But it's probably a better fix for now as it is a much smaller change
than other strategies for fixing this bug.

nilptr3.go changes are mostly because for this pattern:
  _ = *p
  _ = *p
either nil check is fine to keep, and this CL changes which one
the compiler tends to keep.
There are a few regressions from code like this:
  _ = *p
  f()
  _ = *p
For this pattern, after this CL we issue 2 nil checks instead of one.
(For the curious, this happens because intra-block nil check
 elimination now falls to CSE, not nilcheck proper.  The former
 pattern has two nil checks with the same store argument.  The latter
 pattern has two nil checks with different store arguments.)

Fixes #18725

Change-Id: I3721b494c8bc9ba1142dc5c4361ea55c66920ac8
Reviewed-on: https://go-review.googlesource.com/35485Reviewed-by: Cherry Zhang <cherryyz@google.com>

pprof.WriteHeapProfile is shorthand for
pprof.Lookup("heap").WriteTo(f, 0).
The second parameter is debug.
If it is non-zero, pprof writes legacy-format
pprof output, which compilebench can parse.

Fixes #18641

Change-Id: Ica69adeb9809e9b5933aed943dcf4a07910e43fc
Reviewed-on: https://go-review.googlesource.com/35484
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

fixes #18707.

Change-Id: Ibc4efef01197799f66d10bfead22faf8ac00473c
Reviewed-on: https://go-review.googlesource.com/35452
Run-TryBot: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The doc comment about the Data field of go/ast.Object reflects its old
behavior, from when the go/types typechecker depended on ast.Objects.

Since when the doc was written, the behavior has changed in
https://golang.org/cl/7058060 and https://golang.org/cl/7096048 .

Fixes #18631

Change-Id: I10fc3e31cfbf7b303eec44150df917f6eb285f90
Reviewed-on: https://go-review.googlesource.com/35075Reviewed-by: Robert Griesemer <gri@golang.org>

Currently we check that all roots are marked as soon as gcMarkDone
decides to transition from mark 1 to mark 2. However, issue #16083
indicates that there may be a race where we try to complete mark 1
while a worker is still scanning a stack, causing the root mark check
to fail.

We don't yet understand this race, but as a simple mitigation, move
the root check to after gcMarkDone performs a ragged barrier, which
will force any remaining workers to finish their current job.

Updates #16083. This may "fix" it, but it would be better to
understand and fix the underlying race.

Change-Id: I1af9ce67bd87ade7bc2a067295d79c28cd11abd2
Reviewed-on: https://go-review.googlesource.com/35353
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Fixes #18603.

Change-Id: I5760c0a9f862200b7e943058a672eb559ac1b9d9
Reviewed-on: https://go-review.googlesource.com/35354
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates #18609

Change-Id: I8306135660f52cf625bed4c7f53f632e527617de
Reviewed-on: https://go-review.googlesource.com/35265
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>

Fixes #18610.

Change-Id: I19da4d59a1b6293c9a4722aa696e2cb58d982a15
Reviewed-on: https://go-review.googlesource.com/35333Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

We already do this for shared libraries. Do it for plugins also.
Suggestions on how to test this would be welcome.

I'd like to get this in for 1.8.  It could lead to mysterious
hangs when using plugins.

Fixes #18676

Change-Id: I03209b096149090b9ba171c834c5e59087ed0f92
Reviewed-on: https://go-review.googlesource.com/35117Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

Fixes #18675

Change-Id: I82e63e8ee3fe4a998b01d9397c3045912588e2f5
Reviewed-on: https://go-review.googlesource.com/35183Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The bug subcommand opens up the browser instead of printing information.
Fixes help message to reflect that.

Fixes #18630.

Change-Id: I660c94bc65ef1994292cfd72d08a544699545701
Reviewed-on: https://go-review.googlesource.com/35150Reviewed-by: Russ Cox <rsc@golang.org>

As is, they were fully vulnerable to the Lucky13 attack. The SHA1
variants implement limited countermeasures (see f28cf834) but the
SHA256 ones are apparently used rarely enough (see 87415048) that
it's not worth the extra code.

Instead, disable them by default and update the warning.

Updates #13385
Updates #15487

Change-Id: I45b8b716001e2fa0811b17e25be76e2512e5abb2
Reviewed-on: https://go-review.googlesource.com/35290Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

It looks like it should be there, although I couldn't find a test
case that fails without it. ZeroWB is probably never generated now:
zeroing an initialized heap object is done by making an autotmp on
stack, zeroing it, and copying (typedmemmove) to heap.

Passes "toolstash -cmp" on std.

Change-Id: I702a59759e33fb8cc2a34a3b3029e7540aca080a
Reviewed-on: https://go-review.googlesource.com/35250Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Iac713ae1f322f893c92b3fc47fe9b5719052f9eb
Reviewed-on: https://go-review.googlesource.com/35240Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Symonds <dsymonds@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

Fixes #18661.

Change-Id: I865802a9b88ab22560c9914a70901d1924242bdc
Reviewed-on: https://go-review.googlesource.com/35236
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #18673.

Change-Id: Ic827c16ad414733392c348da1c9ed9b308879fef
Reviewed-on: https://go-review.googlesource.com/35260
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

CL 5232 added TestServerHijackGetsBackgroundByte, which is failing
on Plan 9, because CloseWrite is not implemented on Plan 9 yet.

Updates #17906.
Updates #18657.

Change-Id: I3c2f73760b0f767f3f9ed2698c855372170e0481
Reviewed-on: https://go-review.googlesource.com/35178Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

CL 35234 added TestServerHijackGetsBackgroundByte_big, which is failing
on Plan 9, because CloseWrite is not implemented on Plan 9 yet.

Updates #17906.
Updates #18658.

Change-Id: Icaf3fe3600d586515ecd92aca874104ea81ce6b9
Reviewed-on: https://go-review.googlesource.com/35179
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Follow-up test from Ian's comments in https://golang.org/cl/35232
after submit.

Change-Id: Ifa504bd8d09e555c3c7738376199dfc9b99130cf
Reviewed-on: https://go-review.googlesource.com/35234
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

The working directory is now adjusted to match the typical Go test
working directory in main, as the old trick for adjusting earlier
stopped working with the latest version of LLDB bugs.

That means the small number of places where testdata files are
read before main is called no longer work. This CL adjusts those
reads to happen after main is called. (This has the bonus effect of
not reading some benchmark testdata files in all.bash.)

Fixes compress/bzip2, go/doc, go/parser, os, and time package
tests on the iOS builder.

Change-Id: If60f026aa7848b37511c36ac5e3985469ec25209
Reviewed-on: https://go-review.googlesource.com/35255
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Previously, if the Hijack called stopped the background read call
which read a byte, that byte was sitting in memory, buffered, ready to
be Read by Hijack's returned bufio.Reader, but it wasn't yet in the
bufio.Reader's buffer itself, so bufio.Reader.Buffered() reported 1
byte fewer.

This matters for callers who wanted to stitch together any buffered
data (with bufio.Reader.Peek(bufio.Reader.Buffered())) with Hijack's
returned net.Conn. Otherwise there was no way for callers to know a
byte was read.

Change-Id: Id7cb0a0a33fe2f33d79250e13dbaa9c0f7abba13
Reviewed-on: https://go-review.googlesource.com/35232
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

Another change in behvaior (bug) in LLDB. Despite the fact that
LLDB can dump the symtab of our test binaries and show the function
addresses, it can no longer call the functions. This means the chdir
trick on signal is failing.

This CL uses a new trick. For iOS, the exec script passes the change
in directory as an argument, and it is processed early by the test
harness generated by cmd/go.

For the iOS builders.

Change-Id: I8f5d0f831fe18de99f097761f89c5184d5bf2afb
Reviewed-on: https://go-review.googlesource.com/35152Reviewed-by: Elias Naur <elias.naur@gmail.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

mkpost.go replaces all variables prefixed with 'X_' with '_' on s390x
because most of them do not need to be exposed. X__val is being used
by a third party library so it turns out we do need to expose it on
s390x (it is already exposed on all other Linux architectures).

Fixes #17298 and updates #18632.

Change-Id: Ic03463229a5f75ca41a4a4b50300da4b4d892d45
Reviewed-on: https://go-review.googlesource.com/30130Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Also fix a couple of other errors.

Fixes #6877

Change-Id: I94c81c5847cc7b0adab19418e71687bc2ee7fe94
Reviewed-on: https://go-review.googlesource.com/34960Reviewed-by: Ian Lance Taylor <iant@golang.org>

Make sure that the same type and itab generated in two
different plugins are actually the same thing.

See also CL 35115

Change-Id: I0c1ecb039d7e2bf5a601d58dfa162a435ae4ef76
Reviewed-on: https://go-review.googlesource.com/35116
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

When traceback sees reflect.makeFuncStub (or reflect.methodValueCall)
on the stack, it expects to be able to get the *reflect.makeFuncImpl
(or *reflect.methodValue) for that call from the first outgoing
argument slot of makeFuncStub/methodValueCall.

However, currently this object isn't necessarily kept live across
makeFuncStub. This means it may get garbage collected while in a
reflect call and reused for something else. If we then try to
traceback, the runtime will see a corrupted makeFuncImpl object and
panic. This was not a problem in previous releases because we always
kept arguments live across the whole function. This became a problem
when we stopped doing this.

Fix this by using reflect.KeepAlive to keep the
makeFuncImpl/methodValue live across all of callReflect/callMethod,
which in turn keeps it live as long as makeFuncStub/methodValueCall
are on the stack.

Fixes #18635.

Change-Id: I91853efcf17912390fddedfb0230648391c33936
Reviewed-on: https://go-review.googlesource.com/35151
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>