Change-Id: I23bfaa7e03a21aad4e85baa3bf52bb00c09b75d0
Reviewed-on: https://go-review.googlesource.com/44354Reviewed-by: Adam Langley <agl@golang.org>

If we've already imported a named type, then there's no need to
process its associated methods except to validate that the signature
matches the existing known method.

However, the current import code still creates a new function node for
each method, saves its inline body (if any), and adds the node to the
global importlist. Because of this, the duplicate methods are never
garbage collected.

This CL changes the compiler to avoid amassing uncollectable garbage
or performing any unnecessary processing.

This is particularly noticeable for protobuf-heavy code. For the
motivating Go package, this CL reduced compile max-RSS from ~12GB to
~3GB and compile time from ~65s to ~50s.

Passes toolstash -cmp for std, cmd, and k8s.io/kubernetes/cmd/....

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

Currently, the check for `ctx.Done() == context.Background().Done()`
comes before the check to see if we are ignoring any options.  That
check should be done earlier, so that the options are not silently
ignored.

Fixes #21350

Change-Id: I3704e4209854c7d99f3f92498bae831cabc7e419
Reviewed-on: https://go-review.googlesource.com/53970Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The linux getrandom system call returns at most 33554431 = 2^25-1 bytes per
call. The existing behavior for larger reads is to report a failure, because
there appears to have been an unexpected short read. In this case the system
falls back to reading from "/dev/urandom".

This change performs reads of 2^25 bytes or more with multiple calls to
getrandom.

Fixes #20877

Change-Id: I618855bdedafd86cd11219fe453af1d6fa2c88a7
Reviewed-on: https://go-review.googlesource.com/49170Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The current modInverse implementation allocates a big.Int
for the second parameter of GCD, while only the first is needed.
This is unnecessary and can lead to a speed up for optimizations
of GCD where the second parameter is not calculated at all.

Change-Id: I3f042e140ff643311bc3d0b8d192992d4d2c4c70
Reviewed-on: https://go-review.googlesource.com/50531
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filosottile.wiki@gmail.com>
Reviewed-by: Adam Langley <agl@golang.org>

Change-Id: I30563d31f6acea594cc853cc6b672ec664f90d48
Reviewed-on: https://go-review.googlesource.com/53636Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Now that issue #12438 is resolved, this TODO can be completed.
Create a logf helper, which is similar to Server.logf method,
but takes a *Request to infer the *Server and its ErrorLog from.

Update documentation of Server.ErrorLog to mention a new type
of errors that may be logged to it.

Also update a statement in documentation of Server.ErrorLog from:

	// If nil, logging goes to os.Stderr via the log package's
	// standard logger.

To:

	// If nil, logging is done via the log package's standard logger.

The motivation for doing so is to avoid making inaccurate claims.
Logging may not go to os.Stderr if anyone overrides the log package's
default output via https://godoc.org/log#SetOutput. Saying that
the standard logger is used should be sufficient to explain the
behavior, and users can infer that os.Stderr is used by default,
unless it's changed.

Updates #12438.

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

This change enables buildmode c-shared on ppc64le.

A bug was fixed in runtime/rt0_linux_ppc64le.s that was necessary to
make this work.  In _rt0_ppc64le_linux_lib, there is code to store
the value of r2 onto the caller's stack.  However, if this file
is compiled using a build mode that maintains the TOC address in
r2, then instructions will be inserted at the beginning of this
function to generate the r2 value for the callee, not the caller.
That means the r2 value for the callee is stored onto the caller's
stack.  If caller and callee don't have the same r2 values, then
the caller will restore the wrong r2 value after it returns.  This
situation can happen when using dlopen since the caller of this
function will be in ld64.so and will definitely have a different
TOC.

Updates #20756

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

We use lock-free reads from mheap.spans, but the safety of these is
somewhat subtle. Document this.

Change-Id: I928c893232176135308e38bed788d5f84ff11533
Reviewed-on: https://go-review.googlesource.com/54310Reviewed-by: Rick Hudson <rlh@golang.org>

When If-Range does not match and the requested resource is
available, server should return a "200 OK" response to client.
Currently server returns "200 OK" when the request method is
GET, but "206 Partial Content" when method is HEAD.
This change fixed this inconsistency.

Change-Id: I5ad979919f4f089baba54a4445b70ca38471a906
Reviewed-on: https://go-review.googlesource.com/54110
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>

Add test cases to verify behavior for Ldexp with exponents outside the
range of Minint32/Maxint32, for a gccgo bug.

Test for issue #21323.

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

The word "of" was removed in https://go-review.googlesource.com/c/36626

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

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

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

SkipNow and FailNow must be called from the goroutine running the
test. This is already documented, but it's easy to call them by
mistake when writing subtests. In the following:

  func TestPanic(t *testing.T) {
    t.Run("", func(t2 *testing.T) {
	  t.FailNow()    // BAD: should be t2.FailNow()
	})
  }

the FailNow call on the outer t *testing.T correctly triggers a panic

  panic: test executed panic(nil) or runtime.Goexit

The error message confuses users (see issues #17421, #21175) because
there is no way to trace back the relevant part of the message ("test
executed ... runtime.Goexit") to a bad FailNow call without checking
the testing package source code and finding out that FailNow calls
runtime.Goexit.

To help users debug the panic message, mention in the SkipNow and
FailNow documentation that they stop execution by calling
runtime.Goexit.

Fixes #21175

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

Updates http2 to x/net/http2 git rev 1c05540f687 for:

  http2: fix format argument warnings in tests
  https://golang.org/cl/48090

  http2: retry requests after receiving REFUSED STREAM
  https://golang.org/cl/50471

  http2: block RoundTrip when the Transport hits MaxConcurrentStreams
  https://golang.org/cl/53250

Fixes #13774
Fixes #20985
Fixes #21229

Change-Id: Ie19b4a7cc395a0b7a25fac55f5051faaf94920bb
Reviewed-on: https://go-review.googlesource.com/54052
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: Ia0f0c8ab4f2f9e96faad6d88775ae19ca7fae53c
Reviewed-on: https://go-review.googlesource.com/53790Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

We initialize fieldStart to 0, then set it to i without ever reading
0, so we might as well just initialize it to i.

Change-Id: I17905b25d54a62b6bc76f915353756ed5eb6972b
Reviewed-on: https://go-review.googlesource.com/52933Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Functions XORKeyStream should panic if len(dst) < len(src), but it
write to dst before bounds checking. In asm routines and fastXORBytes,
this is an out of bounds write.

Fixes #21104

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

Otherwise, vet might have false positives when "C" is a variable and
we're just using a method on it. Or when an import was renamed to "C".

Add test files for both of these cases.

Fixes #20655.

Change-Id: I55fb93119444a67fcf7891ad92653678cbd4670e
Reviewed-on: https://go-review.googlesource.com/45551
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>

These rules trigger a few times during make.bash.
When we eliminate boundedness checks from walk.go
we'll rely on them more heavily.

Updates #19692

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

gc.Sysfunc must not be called concurrently.
We set up runtime routines used by the backend
prior to doing any backend compilation.
I missed the 387 ones; fix that.

Sysfunc should have been unexported during 1.9.
I will rectify that in a subsequent CL.

Fixes #21352

Change-Id: I8386eaa1e05879c25c672b9c9fc693c938e9aeb6
Reviewed-on: https://go-review.googlesource.com/54090
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Iece39e6412c0f6c63f563eed1621b8cca02de835
Reviewed-on: https://go-review.googlesource.com/51890
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The standard deviation of a uniform distribution is size / √12.
The size of the interval [0, 255] is 256, not 255.
While we're here, simplify the expression.

The tests previously passed only because the error margin was large enough.
Sample observed standard deviations while running tests:

73.7893634666819
73.9221651548294
73.8077961697150
73.9084236069471
73.8968446814785
73.8684209136244
73.9774618960282
73.9523483202549

255 / √12 == 73.6121593216772
256 / √12 == 73.9008344562721

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

The compiler is now smart enough not to insert a bounds check.
Not only is this simpler, it eliminates a LEAQ from the
generated code.

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

It appears that this was just missed
by accident in the original implementation.

Change-Id: Id87147bcb7a685d624eac7034342a305ad644e7a
Reviewed-on: https://go-review.googlesource.com/53891
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>

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

ADDSDmem comment said f32 (likely a copy-paste mistake).

Also swap ADDSSmem and ADDSDmem positions in the list to uniform the
list order.

Fixes #21225

Change-Id: I26bb116900c1cf4c4e6faeef613d7318c9c85b98
Reviewed-on: https://go-review.googlesource.com/52071
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Keith Randall <khr@golang.org>

Regular HTTP is insecure, oeis.org supports HTTPS and it is actually
used in some other places in the codebase. This changes these final urls
to use HTTPS.

Change-Id: Ia46410a9c7ce67238a10cb6bfffaceca46112f58
Reviewed-on: https://go-review.googlesource.com/52072Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>

Looking up a nonexistent CNAME record on an existing
domain on Plan 9 can return either a "dns failure"
error or a "resource does not exist" error.

Fixes #21335.

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

According to http://infocenter.arm.com:
* ARM Cortex-A53 (Raspberry Pi 3, Pine A64)
* ARM Cortex-A57 (Opteron A1100, Tegra X1)
* ARM Cortex-A72
all have a cache line size of 64 bytes.

Change-Id: I4b333e930792fb1a221b3ca6f395bfa1b7762afa
Reviewed-on: https://go-review.googlesource.com/43250
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

The only non test user of the assembler prefetch functions is the
heapBits.prefetch function which is itself unused.

The runtime prefetch functions have no functionality on most platforms
and are not inlineable since they are written in assembler. The function
call overhead eliminates the performance gains that could be achieved with
prefetching and would degrade performance for platforms where the functions
are no-ops.

If prefetch functions are needed back again later they can be improved
by avoiding the function call overhead and implementing them as intrinsics.

Change-Id: I52c553cf3607ffe09f0441c6e7a0a818cb21117d
Reviewed-on: https://go-review.googlesource.com/44370
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Setting the Content-Type header explicitly allows browsers to know what
the type of the content is. Otherwise, they have to guess the type from
the content itself, which could lead to unpredictable behavior, and
increases CPU usage.

Not setting the Content-Type despite writing a body may also trigger
unwanted warnings in user middleware, and make it more difficult to
resolve valid issues where the user forgets to set Content-Type in
some situations where it should be set.

There is some precedent for doing this in http.FileServer, which
sets "Content-Type" to "text/html; charset=utf-8" before writing
<pre><a href=...></a></pre> HTML.

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

Fixes #18412

Change-Id: Ib457eeced7820517aa35df9e7dfda1c0de4ac004
Reviewed-on: https://go-review.googlesource.com/52852Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Accidentally omitted from submit of CL 53352.

Updates #21306

Change-Id: I022d89c6417fe9371856d49b646eb6294b91657c
Reviewed-on: https://go-review.googlesource.com/53415Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Avelino <t@avelino.xxx>

This change fixes the remaining examples where the raw strings had
suboptimal indentation (one level too many) when viewed in godoc.

Follows CL 48910.
Fixes #21026.

Change-Id: Ifc0dae3fa899a9fff8b1ff958414e2fe6852321d
Reviewed-on: https://go-review.googlesource.com/50990
Run-TryBot: Dmitri Shuralyov <shurcool@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #21194

Change-Id: Iac5187335df67f90f0f47c7ef6574de147c2ac9b
Reviewed-on: https://go-review.googlesource.com/52970Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Consistent with similar change of style in the crypto repository:
http://golang.org/cl/43511

Change-Id: Ib158c52a2649dcbbe9eb92f2bdb9d289e0dcc7bf
Reviewed-on: https://go-review.googlesource.com/53474Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

CommandLine (exported in Go 1.2) has default output of os.Stderr.

Before it was exported, it made sense to have the global Usage func
(the implicit usage func if CommandLine.Usage is nil) hard-code
os.Stderr has its output. But once CommandLine was exported, Usage
should use it if provided.

Fixes #20998

Change-Id: I9e1c0415a563a982634b9808199c9ee175d72f4c
Reviewed-on: https://go-review.googlesource.com/48390
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

We need to make sure that when the key contains a pointer, we use
a write barrier to update the key.

Also mapdelete_* should use typedmemclr.

Fixes #21297

Change-Id: I63dc90bec1cb909c2c6e08676c9ec853d736cdf8
Reviewed-on: https://go-review.googlesource.com/53414
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>