There are two places where the compiler generates memclrHasPointers
calls. These are effectively write barriers, but the compiler doesn't
currently record them as such in the function. As a result code like

  for i := range a {
    a[i] = nil
  }

inserts a write barrier for the assignment to a[i], but the compiler
doesn't report this. Hence, it's not reported in the -d=wb output, and
it's not checked against //go:nowritebarrier annotations.

Change-Id: I40299ebc9824f05cf516cba494d4c086b80ffb53
Reviewed-on: https://go-review.googlesource.com/c/152722
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

This updates master to fix the ppc64 objdump. There were many cases where
the Go objdump was generating opcodes that didn't exist in the Go assembler,
or generated operands in the wrong order. The goal is to generate a Go
objdump that is acceptable to the Go assembler, or as close as possible.

An additional change will be needed for the Go objdump tool to make
use of this.

Change-Id: Ie8d2d534e13b9a64852c99b4b864a9c08ed7e036
Reviewed-on: https://go-review.googlesource.com/c/152517Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Follow-up on #28450 (golang.org/cl/152417).

Updates #28450.
Fixes #29107.

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

This test is regularly failing on the plan9/386
builder running on GCE, but we haven't figured
out the issue yet.

Updates #26945.

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

Fixes golang/go#28820.

Change-Id: Id931617efcf161ec934eb6d44062ad95e8a6ab8d
Reviewed-on: https://go-review.googlesource.com/c/150277
Run-TryBot: Baokun Lee <nototon@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Fixes #29110

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

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

filelock.Unlock() was called twice for fcntl implementation if an error
occurs during file.{,R}Lock(): once in the error handler, once in
filelock.lock().

Change-Id: I5ad84e8ef6b5e51d79e0a7a0c51f465276cd0c57
Reviewed-on: https://go-review.googlesource.com/c/152717
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Fixes #28721

Change-Id: I00356f3a9b0c2fb21dc9c2237dd5296fcb3b319b
Reviewed-on: https://go-review.googlesource.com/c/152657
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

In the s390x assembly implementation of NIST P-256 curve, utilize faster multiply/square
instructions introduced in the z14. These new instructions are designed for crypto
and are constant time. The algorithm is unchanged except for faster
multiplication when run on a z14 or later. On z13, the original mutiplication
(also constant time) is used.

P-256 performance is critical in many applications, such as Blockchain.

name            old time      new time     delta
BaseMultP256    24396 ns/op   21564 ns/op  1.13x
ScalarMultP256  87546 ns/op   72813 ns/op. 1.20x

Change-Id: I7e6d8b420fac56d5f9cc13c9423e2080df854bac
Reviewed-on: https://go-review.googlesource.com/c/146022Reviewed-by: Michael Munday <mike.munday@ibm.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Michael Munday <mike.munday@ibm.com>

The expression passed into isAbortPC call was written specifically
for windows/amd64 and windows/386 runtime.abort implementation.
Adjust the code, so it also works for windows/arm.

Fixes #29050

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

Previously, when a function signature had defined a non-final variadic
parameter, the error message always referred to the type associated with that
parameter. However, if the offending parameter's name was part of an identifier
list with a variadic type, one could misinterpret the message, thinking the
problem had been with one of the other names in the identifer list.

    func bar(a, b ...int) {}
clear ~~~~~~~^       ^~~~~~~~ confusing

This change updates the error message and sets the column position to that of
the offending parameter's name, if it exists.

Fixes #28450.

Change-Id: I076f560925598ed90e218c25d70f9449ffd9b3ea
Reviewed-on: https://go-review.googlesource.com/c/152417
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>

For recursive functions, the parameters were iterated using
fn.Name.Defn.Func.Dcl, which does not include unnamed/blank
parameters. This results in a mismatch in formal-actual
assignments, for example,

func f(_ T, x T)

f(a, b) should result in { _=a, x=b }, but the escape analysis
currently sees only { x=a } and drops b on the floor. This may
cause b to not escape when it should (or a escape when it should
not).

Fix this by using fntype.Params().FieldSlice() instead, which
does include unnamed parameters.

Also add a sanity check that ensures all the actual parameters
are consumed.

Fixes #29000

Change-Id: Icd86f2b5d71e7ebbab76e375b7702f62efcf59ae
Reviewed-on: https://go-review.googlesource.com/c/152617Reviewed-by: Keith Randall <khr@golang.org>

This partially reverts https://golang.org/cl/135035.

Reason for revert: multiple -ldflags=-foo flags simply override each
other, since that's the logic for per-package flags. The suggested
'GOFLAGS=-ldflags=-s -ldflags=-w' has never worked for 'go build', and
even breaks 'go test' and 'go vet'.

There should be a way to specify -ldflags='-w -s' via GOFLAGS, which is
being tracked in #29096. For now, just remove the incorrect suggestion.

Fixes #29053.

Change-Id: I9203056f7e5191e894bcd16595a92df2fb704ea7
Reviewed-on: https://go-review.googlesource.com/c/152479Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>

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

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

This will produce better error messages (position information)
for errors referring to imported objects.

Change-Id: I24646ae803e6b8f78e9240310a858d4095e9463d
Reviewed-on: https://go-review.googlesource.com/c/152538Reviewed-by: Alan Donovan <adonovan@google.com>

The importer.For function logically requires a FileSet, but did not
when it was first created because export data did not then record
position information. This change adds a new function, ForCompiler,
that has an additional FileSet parameter, and deprecates the For
function.

Before this change, cmd/vet would report confusing spurious
positions for token.Pos values produced by the importer.
The bug is essentially unfixable in cmd/vet.

This CL includes a test that the FileSet is correctly populated.

The changes to cmd/vendor will be applied upstream in a follow-up.

Fixes #28995

Change-Id: I9271bcb1f28e96845c913e15f0304bac93d4d4c4
Reviewed-on: https://go-review.googlesource.com/c/152258
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Robert Griesemer <gri@golang.org>

Ignore predeclared types (such as error) in result parameter lists when determining
with which result type a method should be associated with. This change will again
associate common factory functions with the first result type even if there are more
than one result, as long as the others are predeclared types.

Fixes #27928

Change-Id: Ia2aeaed15fc4c8debdeeaf729cc7fbba1612cafb
Reviewed-on: https://go-review.googlesource.com/c/141617
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Support for methods marked with "//go:nointerface" was broken by CL
151557, based on CL 150061, which changed the scanner to stop skipping
comments.

Change-Id: I43d5e2cf51bed2dc4ed9d6136ca21aa1223e8df1
Reviewed-on: https://go-review.googlesource.com/c/152378
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

AIX doesn't provide flock() syscall, it was previously emulated by fcntl
calls. However, there are some differences between a flock() syscall and
a flock() using fcntl. Therefore, it's safer to remove it and just
provide FcntlFlock.

Thus, lockedfile implementation must be moved to use FcntlFlock on aix/ppc64.

Updates #29065.
Fixes #29084.

Change-Id: Ic48fd9f315f24c2acdf09b91d917da131a1f2dd5
Reviewed-on: https://go-review.googlesource.com/c/152397Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Some recent failures in gccgo on linux/ppc64 identified
an error in buildmodeInit when buildmode=c-archive.
A fix went into gofrontend, and this is the
corresponding change for master. This change also includes
two other updates related to gccgo in this function that
were in the file from gofrontend but missing from master.

Updates #29046

Change-Id: I9a894e7d728e31fb9e9344cd61d50408df7faf4a
Reviewed-on: https://go-review.googlesource.com/c/152160
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

These changes add tests for the unexported function singleJoiningSlash.

Change-Id: I107905aac4a3c2544be309098b67e970ea5b542c
GitHub-Last-Rev: ed6f86f619549f46ef53316b7febaac781b64e4b
GitHub-Pull-Request: golang/go#29088
Reviewed-on: https://go-review.googlesource.com/c/152337Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #28869

Change-Id: Ie152bf959af2e9cd32b1ccc031e8208e64fbe3ce
Reviewed-on: https://go-review.googlesource.com/c/152161Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

The original value of 65537 consistently caused the test to fail on
Solaris. The new value of 131073 consistently lets the test pass.

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

In CL 129061, a check was added for patterns that reference
nonexistent local directories. While this prevented unnecessary
network lookups (fixing #26874), it caused "go list -e" to exit with
an error instead of listing packages with error messages.

This change avoids the network lookup and does not exit for these
kinds of packages. Errors are still reported by
internal/load.LoadImport for packages that don't exist.

Fixes #28023

Change-Id: I0a648269e437aed3a95bfb05461a397264f3793f
Reviewed-on: https://go-review.googlesource.com/c/151800
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Updates #29087

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

The type checker may be called incrementally (by repeatedly calling
Checker.Files), for instance when adding _test.go files to a set of
already checked files.

The existing code reset a cache of (already computed) interface
information with each Checker.Files call, causing interfaces to be
recomputed in some cases, albeit with different receiver information
(see comments in this CL for details).

Don't reset the interface cache to avoid this problem.

While adding a test case, also factor out some common testing logic.

Fixes #29029.

Change-Id: I2e2d6d6bb839b3a76522fbc4ba7355c71d3bb80b
Reviewed-on: https://go-review.googlesource.com/c/152259Reviewed-by: Alan Donovan <adonovan@google.com>

Fix unannounced trailers when body is empty and without announced trailers.

Fixes #29031

Change-Id: If49951a42fe56d4be4436a999627db4c2678659d
GitHub-Last-Rev: 3469adc8f5fd977438350274134950687853a468
GitHub-Pull-Request: golang/go#29032
Reviewed-on: https://go-review.googlesource.com/c/151898
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

To pull in the fix for #28858, which we want to include for Go 1.12.

Fixes #28858.

Change-Id: Id4964cfd38e3d44d6317a2ee124fe2d35038b5fd
Reviewed-on: https://go-review.googlesource.com/c/152277
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

Fixes #28069

Change-Id: I7e0f96b8b6d123de283325fcb78ec76455050f6d
Reviewed-on: https://go-review.googlesource.com/c/152158
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

And remove some unnecessary textproto references. (The net/http
package's CanonicalHeaderKey just calls textproto's
CanonicalMIMEHeaderKey)

Fixes #28894

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

Darwin doesn't support the multiple copies of the runtime package
implied by linking a c-shared library into a Go program.

Updates #29061

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

staticcopy of a struct or array should recursively call itself, not
staticassign.

This fixes an issue where a struct with a slice in it is copied during
static initialization. In this case, the backing array for the slice
is duplicated, and each copy of the slice refers to a different
backing array, which is incorrect.  That issue has existed since at
least Go 1.2.

I'm not sure why this was never noticed. It seems like a pretty
obvious bug if anyone modifies the resulting slice.

In any case, we started to notice when the optimization in CL 140301
landed.  Here is basically what happens in issue29013b.go:
1) The error above happens, so we get two backing stores for what
   should be the same slice.
2) The code for initializing those backing stores is reused.
   But not duplicated: they are the same Node structure.
3) The order pass allocates temporaries for the map operations.
   For the first instance, things work fine and two temporaries are
   allocated and stored in the OKEY nodes. For the second instance,
   the order pass decides new temporaries aren't needed, because
   the OKEY nodes already have temporaries in them.
   But the order pass also puts a VARKILL of the temporaries between
   the two instance initializations.
4) In this state, the code is technically incorrect. But before
   CL 140301 it happens to work because the temporaries are still
   correctly initialized when they are used for the second time. But then...
5) The new CL 140301 sees the VARKILLs and decides to reuse the
   temporary for instance 1 map 2 to initialize the instance 2 map 1
   map. Because the keys aren't re-initialized, instance 2 map 1
   gets the wrong key inserted into it.

Fixes #29013

Change-Id: I840ce1b297d119caa706acd90e1517a5e47e9848
Reviewed-on: https://go-review.googlesource.com/c/152081
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

This is just the first step in attempting to make all network connection have
timeouts as a "safe default". TCP keepalives only protect against certain
classes of network and host issues (e.g. server/OS crash), but do nothing
against application-level issues (e.g. an application that accepts connections
but then fails to serve requests).

The actual keep-alive duration (15s) is chosen to cause broken connections
to be closed after 2~3 minutes (depending on the OS, see #23549 for details).
We don't make the actual default value part of the public API for a number of
reasons:
- because it's not very useful by itself: as discussed in #23549 the actual
  "timeout" after which the connection is torn down is duration*(KEEPCNT+1),
  and we use the OS-wide value for KEEPCNT because there's currently no way
  to set it from Go.
- because it may change in the future: if users need to rely on a specific
  value they should explicitly set this value instead of relying on the default.

Fixes #23459

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

StatusTooEarly can be returned to indicate that a server is unwilling
to accept early data as introduced in TLS 1.3.
The status code was specified in RFC 8470, section 5.2.

Major supported browsers are:
- Firefox as of version 58
  https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/425#Browser_compatibility
- Chromium as of version 73.0.3628.1
  https://chromium.googlesource.com/chromium/src/+/58097ec3823e0f340ab5abfcaec1306e1d954c5a

Change-Id: I3f62f4193bae198994d08fde7e92e0ccd080e59a
GitHub-Last-Rev: fa885040eaf80e0e33b571567108d8a9ded67801
GitHub-Pull-Request: golang/go#29073
Reviewed-on: https://go-review.googlesource.com/c/152118Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Before this change, location list construction would extend
from the previous (in linear order) block, even if was not a
flow predecessor.  This can cause a debugger to tell lies.

Fix accounts for this in block merging code by (crudely)
"changing" all variables live from a previous block if it
is not also a predecessor.

Fixes #28486.

Change-Id: I11336b0b969f0cd09f40f4e5f2bdfdeb02f377a4
Reviewed-on: https://go-review.googlesource.com/c/146718
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>

Follow-up for CL 147037 and after Brad noticed the "returns whether"
pattern during the review of CL 150621.

Go documentation style for boolean funcs is to say:

    // Foo reports whether ...
    func Foo() bool

(rather than "returns whether")

Created with:

    $ perl -i -npe 's/returns whether/reports whether/' $(git grep -l "returns whether" | grep -v vendor)

Change-Id: I15fe9ff99180ad97750cd05a10eceafdb12dc0b4
Reviewed-on: https://go-review.googlesource.com/c/150918
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

golang.org/cl/151977 slightly decreased the cost of inlining an extra
call from 60 to 57, since it was a safe change that could help in some
scenarios.

One notable change spotted in that CL is that bytes.Buffer.Grow is now
inlinable, meaning that a fixedbugs test needed updating.

For consistency, add the test case to TestIntendedInlining too,
alongside other commonly used bytes.Buffer methods.

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

A Go user made a well-documented request for a slightly
lower threshold.  I tested against a selection of other
people's benchmarks, and saw a tiny benefit (possibly noise)
at equally tiny cost, and no unpleasant surprises observed
in benchmarking.

I.e., might help, doesn't hurt, low risk, request was
delivered on a silver platter.

It did, however, change the behavior of one test because
now bytes.Buffer.Grow is eligible for inlining.

Updates #19348.

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