The linker's sym.Symbol struct contains two string fields, "Dynimplib"
and "Dynimpvers" that are used only in very specific circumstances
(for many symbols, such as DWARF syms, they are wasted space). Split
these two off into a separate struct, then point to an instance of
that struct when needed. This reduces the size of sym.Symbol so as to
save space in the common case.

Updates #26186

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

The sym.Symbol 'Reachparent' field is used only when field tracking
is enabled. So as to use less memory for the common case where
field tracking is not enabled, remove this field and use a side
table stored in the context to achieve the same functionality.

Updates #26186

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

Fixes #24518.

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

Before CL 116855, Transport would only skip over 100 (expect-continue)
responses automatically and treat all other 1xx responses as if they
were the final status. CL 116855 made the Transport more spec
compliant (ignoring unknown 1xx responses), but broke "101 Switching
Protocols" in the process. Since 101 is already in use and defined to
not have a following message, treat it as terminal.

Note that because the Client/Transport don't support hijacking the
underlying Conn, most clients doing a WebSocket or other protocol
upgrade are probably using net.Dial + http.ReadResponse instead, which
remained unaffected (before & after this CL).

The main affect of this CL is to fix tests that were using the
Client/Transport to test that a server returns 101, presumably without
actually switching to another protocol.

Fixes #26161

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

Fixes #20239

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

The vetx output file is a build output, and as such should be
deterministic. This CL changes it to not depend on map iteration order.

This avoids a pointless GODEBUG=gocacheverify=1 failure.

Updates #25666

Change-Id: Ic132bad134cb10938275f883c2c68432cb7c4409
Reviewed-on: https://go-review.googlesource.com/121941
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Late opt pass may generate dead stores, which messes up store
chain calculation in later passes. Run generic deadcode even
in -N mode to remove them.

Fixes #26163.

Change-Id: I8276101717bb978d5980e6c7998f53fd8d0ae10f
Reviewed-on: https://go-review.googlesource.com/121856
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>

These rules don't even type check.  ADDQconstmodify returns memory,
and it is being rewritten to a value that returns an int64.

There should be a MOVQstore wrapped around the result.
These rules never fire during all.bash, so they aren't even tested.

I'm just going to remove them for now.

Change-Id: I76008eb51ae4e16c707fac73c05a8d67cac149ae
Reviewed-on: https://go-review.googlesource.com/121935
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

If the address of an auto reaches a phi then any further stores to
the pointer represented by the phi probably need to be kept. This
is because stores to the other arguments to the phi may be visible
to the program.

Fixes #26153.

Change-Id: Ic506c6c543bf70d792e5b1a64bdde1e5fdf1126a
Reviewed-on: https://go-review.googlesource.com/121796
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>

Allow static complication of cgo enabled libraries.

Fixes #16651

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

Fixes #26173

Change-Id: I032551f63b359c8cbb7296931e1957d2bff8f328
Reviewed-on: https://go-review.googlesource.com/121819
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

TestUtimesNanoAt in the vendored copy of golang.org/x/sys/unix currently
fails on the linux-arm-arm5spacemonkey builder. Update the vendored copy
to pick up the fix from CL 120816.

Updates #26034

Change-Id: I75c8875089f58a4c32e2e7aa75884b2bcba7bd68
Reviewed-on: https://go-review.googlesource.com/121800
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently, on Windows, the thread stack size is set or assumed in many
different places. In non-cgo binaries, both the Go linker and the
runtime have a copy of the stack size, the Go linker sets the size of
the main thread stack, and the runtime sets the size of other thread
stacks. In cgo binaries, the external linker sets the main thread
stack size, the runtime assumes the size of the main thread stack will
be the same as used by the Go linker, and the cgo entry code assumes
the same.

Furthermore, users can change the main thread stack size using
editbin, so the runtime doesn't even really know what size it is, and
user C code can create threads with unknown thread stack sizes, which
we also assume have the same default stack size.

This is all a mess.

Fix the corner cases of this and the duplication of knowledge between
the linker and the runtime by querying the OS for the stack bounds
during thread setup. Furthermore, we unify all of this into just
runtime.minit for both cgo and non-cgo binaries and for the main
thread, other runtime-created threads, and C-created threads.

Updates #20975.

Change-Id: I45dbee2b5ea2ae721a85a27680737ff046f9d464
Reviewed-on: https://go-review.googlesource.com/120336
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently, we allocate 1MB or 2MB thread stacks on Windows, but in
non-cgo binaries still set the g0 stack bounds assuming only 64k is
available. While this is fine in pure Go binaries, a non-cgo Go binary
on Windows can use the syscall package to call arbitrary DLLs, which
may call back into Go. If a DLL function uses more than 64k of stack
and then calls back into Go, the Go runtime will believe that it's out
of stack space and crash.

Fix this by plumbing the correct stack size into the g0 stacks of
non-cgo binaries. Cgo binaries already use the correct size because
their g0 stack sizes are set by a different code path.

Fixes #20975.

Change-Id: Id6fb559cfe1e1ea0dfac56d4654865c20dccf68d
Reviewed-on: https://go-review.googlesource.com/120195
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Executing tests in cmd/go/internal/modfetch/gitrepo/fetch_test.go in enviroment
witout outside connectivity in to the internet results in tests failure:

2018/06/25 12:48:26 git clone --mirror https://vcs-test.golang.org/git/gitrepo1 /tmp/gitrepo-test-221822392/gitrepo2 in : exit status 128:
	Cloning into bare repository '/tmp/gitrepo-test-221822392/gitrepo2'...
	fatal: unable to access 'https://vcs-test.golang.org/git/gitrepo1/': Could not resolve host: vcs-test.golang.org
FAIL	cmd/go/internal/modfetch/gitrepo	0.144s

Call flag.Parse in TestMain to properly initialize test environment variables

Fixes #26007

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

The OpenBSD sysctl code has been copy-pasted three times now. Abstract
it.

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

On the OpenBSD builder this reduces the test time from 213 seconds to
60 seconds, without loss of testing.

Not sure why the test is so much slower on OpenBSD, so not closing the
issues.

Updates #26155
Updates #26174

Change-Id: I13b58bbe3b209e591c308765077d2342943a3d2a
Reviewed-on: https://go-review.googlesource.com/121820
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ralph Corderoy <ralph@inputplus.co.uk>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Idbd8a1b5bfeb1c23c86cef0697cf0380900e95f3
GitHub-Last-Rev: a8c2b27046582c4eef932a8502826a3b23b8dab3
GitHub-Pull-Request: golang/go#26175
Reviewed-on: https://go-review.googlesource.com/121821Reviewed-by: Keith Randall <khr@golang.org>

For each Javascript object that returns to Go as a js.Value, we
associate the ref id to it. But if this ref id is copied or
inherited to other object, it would mess up the ref-object
mapping.

In storeValue, make sure the object is indeed the one we are
storing. Otherwise allocate a new ref id.

Fixes #26143.

Change-Id: Ie60bb2f8d1533da1bbe6f46045866515ec2af5a9
Reviewed-on: https://go-review.googlesource.com/121835
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>

The previous CL (https://go-review.googlesource.com/c/go/+/96756)
added comments that didn't really say much, but there is something
so say: what the units are and that they are indexed starting at 1.

Add a more helpful comment on the type, and also follow proper
style by using initial capitals and a period.

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

This commit adds examples that demonstrate usage in a practical way.

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

Before GCC 8 C code like

const unsigned long long int neg = (const unsigned long long) -1;
void f(void) { static const double x = (neg); }

would get an error "initializer element is not constant". In GCC 8 and
later it does not.

Because a value like neg, above, can not be used as a general integer
constant, this causes cgo to conclude that it is a floating point
constant. The way that cgo handles floating point values then causes
it to get the wrong value for it: 18446744073709551615 rather than -1.
These are of course the same value when converted to int64, but Go
does not permit that kind of conversion for an out-of-range constant.

This CL side-steps the problem by treating floating point constants
with integer type as they would up being treated before GCC 8: as
variables rather than constants.

Fixes #26066

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

Fixes issue #26139

Change-Id: Id9a3e5c443ee175ad9add6296ed45bdf328b15a0
GitHub-Last-Rev: b3f8a8f165d15cfffd4948151eae34f95330748c
GitHub-Pull-Request: golang/go#26146
Reviewed-on: https://go-review.googlesource.com/121696Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #23316

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

Updates http2 to x/net/http2 git rev 97aa3a539 for:

    http2: dynamic table updates must occur first
    https://golang.org/cl/111681

    http2: receiving too much data is a protocol error
    https://golang.org/cl/111679

    http2: correct overflow protection
    https://golang.org/cl/111675

    http2: make Server send GOAWAY if Handler sets "Connection: close" header
    https://golang.org/cl/121415

Fixes #20977

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

If the runtime code panics due to a bad index or slice expression,
then throw instead of panicing. This will skip calls to recover and dump
the entire runtime stack trace. The runtime should never panic due to
an out of bounds index, and this will help with debugging if it does.

For #24991
Updates #25201

Change-Id: I85a9feded8f0de914ee1558425931853223c0514
Reviewed-on: https://go-review.googlesource.com/121515Reviewed-by: Austin Clements <austin@google.com>

OpenBSD 6.4 is going to start requiring that the SP points to memory
that was mapped with MAP_STACK on system call entry, traps, and when
switching to the alternate signal stack [1]. Currently, Go doesn't map
any memory MAP_STACK, so the kernel quickly kills Go processes.

Fix this by remapping the memory that backs stack spans with
MAP_STACK, and re-remapping it without MAP_STACK when it's returned to
the heap.

[1] http://openbsd-archive.7691.n7.nabble.com/stack-register-checking-td338238.html

Fixes #26142.

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

CL 103055 made it so that invalid parameter expansions, like "$|", did
not make the dollar sign silently disappear.

A few edge cases were not taken into account, such as "${}" and "${",
which were now printing just "$". For consistency and to not break
existing programs, go back to eating up the characters when invalid
syntax is encountered.

For completeness, add a "$" test case too, even though its behavior is
unchanged by this CL.

Fixes #26135.

Change-Id: I5d25db9a8356dc6047a8502e318355113a99b247
Reviewed-on: https://go-review.googlesource.com/121636
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The existing implementation of bytes.Compare on s390x doesn't work properly for slices longer
than 256 elements. This change fixes that. Added tests for long strings and slices of bytes.

Fixes #26114

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

This reverts commit 1a27f048.

Reason for revert: Broke the ssacheck and -N-l builders, and the -N-l fix looks like it will take some time and take a different route entirely.

Change-Id: Ie0ac5e86ab7d72a303dfbbc48dfdf1e092d4f61a
Reviewed-on: https://go-review.googlesource.com/121715Reviewed-by: David Chase <drchase@google.com>

Be super explicit that HTTP keep-alives != TCP keep-alives.

Fixes #26128

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

I thought I removed this but failed to amend it to my commit before
submitting.

Change-Id: I2d687d91f4de72251548faa700006af0fea503af
Reviewed-on: https://go-review.googlesource.com/121615
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

If one quickly looks at the strings package godoc, reading the name
TrimLeft, one might think it removes a prefix from the string.

The function's godoc does explain its purpose, but it's apparent that it
is not clear enough, as there have been numerous raised issues about
this confusion: #12771 #14657 #18160 #19371 #20085 #25328 #26119. These
questions are also frequent elsewhere on the internet.

Add a very short paragraph to the godoc, to hopefully point new Go
developers in the right direction faster. Do the same thing for
TrimRight and TrimSuffix.

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

Fill in the missing descriptions for the CoverBlock struct fields

Change-Id: I9257881a19b01e5cfe61cf19a91375b6d7cc68ef
GitHub-Last-Rev: f5b9e1d49d1c00f59ce4d3684915e5e93ec0297a
GitHub-Pull-Request: golang/go#24079
Reviewed-on: https://go-review.googlesource.com/96756Reviewed-by: Andrew Bonventre <andybons@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Given a carefully constructed input, writebarrier would
split a block with the OpAddr in the first half and the
VarDef in the second half which ultimately leads to a
compiler crash because the scheduler is no longer able
to put them in the proper order.

To fix, recognize the implicit dependence of OpAddr on
the VarDef of the same symbol if any exists.

This fix was chosen over making OpAddr take a memory
operand to make the dependence explicit, because this
change is less invasive at this late part of the 1.11
release cycle.

Fixes #26105.

Change-Id: I9b65460673af3af41740ef877d2fca91acd336bc
Reviewed-on: https://go-review.googlesource.com/121436
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

SSA can handle 1-element array, but only when the element type
is SSAable. When building SSA for INDEX of 1-element array, we
did not check the element type is SSAable. And when it's not,
it resulted in an unhandled SSA op.

Fixes #26120.

Change-Id: Id709996b5d9d90212f6c56d3f27eed320a4d8360
Reviewed-on: https://go-review.googlesource.com/121496
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

The check was running in the loop that read source files in, much before
any of the other checks ran. Vetxonly makes vet exit early, but after
all the source files have been read.

To fix this, simply run the buildtag check along with all the other
checks that get run on specific syntax tree nodes.

Add a cmd/go test with go test -a, to ensure that the issue as reported
is fixed.

Fixes #26102.

Change-Id: If6e3b9418ffa8166c0f982668b0d10872283776a
Reviewed-on: https://go-review.googlesource.com/121395
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Before CL 4281055 in 2011, the reflect package was quite different.
rtype, then called commonType, was embedded in exported structs with
names like StructType. In order to avoid accidental conversions
between pointers to these public structs, which sometimes had
identical fields, the embedded commonType fields were tagged.

In CL 4281055 the formerly public structs were unexported, and all
access was done through the Type interface. At that point the field
tags in the reflect structs were no longer useful.

In Go 1.8 the language was changed to ignore struct field tags when
converting between types. This made the field tags in the reflect
structs doubly useless.

This CL simply removes them.

Fixes #20914

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

Fixes #24763.

Change-Id: Ibe534271d75b6961d00ebfd7d42c43a3ac650d79
Reviewed-on: https://go-review.googlesource.com/121335Reviewed-by: Matthew Dempsky <mdempsky@google.com>

The Server distinguishes "new" vs "idle" connections. A TCP connection
from which no bytes have yet been written is "new". A connection that
has previously served a request and is in "keep-alive" state while
waiting for a second or further request is "idle".

The graceful Server.Shutdown historically only shut down "idle"
connections, with the assumption that a "new" connection was about to
read its request and would then shut down on its own afterwards.

But apparently some clients spin up connections and don't end up using
them, so we have something that's "new" to us, but browsers or other
clients are treating as "idle" to them.

This CL tweaks our heuristic to treat a StateNew connection as
StateIdle if it's been stuck in StateNew for over 5 seconds.

Fixes #22682

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