This avoids a warning from old versions of the GNU linker or glibc.

No test because these old versions are not readily available.
I tested this by hand on CentOS 6.

Fixes #28722

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

CL 122575 and its successors introduced a loop calling loadDWARF,
whereas before we only called it once. Pass a single typeConv to each
call, rather than creating a new one in loadDWARF itself. Change the
maps from dwarf.Type to use string keys rather than dwarf.Type keys,
since when the DWARF is reloaded the dwarf.Type pointers will be
different. These changes permit typeConv.Type to return a consistent
value for a given DWARF type, avoiding spurious type conversion errors
due to typedefs loaded after the first loop iteration.

Fixes #27340

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

Fixes #25065

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

The https scheme is supported, and should be used per best practices.

The previous http link redirected to https:

	$ curl -i 'http://oss-security.openwall.org/wiki/mailing-lists/distros'
	HTTP/1.1 302 Moved Temporarily
	Location: https://oss-security.openwall.org/wiki/mailing-lists/distros

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

When converting a method to a function, like this:

type T ...
func (t T) foo() {
}
var t T
f := t.foo

We need to build a wrapper function for the partially evaluated
method. Currently that wrapper function gets the line number of
the first place where t.foo appears. Instead it should have the
line number of where foo is declared.

Fixes #26839

Change-Id: I7dbe2094e53d5d336f329273f10f8430e0af544e
Reviewed-on: https://go-review.googlesource.com/c/153498
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Without this, each additional C frame found via SetCgoTraceback will
cause a frame to be dropped from the bottom of the traceback stack.

Fixes #29034

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

At the moment, the cover tool does not check that the argument of -var
is a valid identifier. Hence, it could generate a file that fails to
compile afterwards.

Updates #25280

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

Replace the 128-bit multiplication in 4 parts with bits.Mul64
and two single-width multiplications.  This simplifies the code
and increases throughput by ~50% on amd64.

name         old time/op   new time/op   delta
Fnv128KB-4    9.64µs ± 0%   6.09µs ± 0%  -36.89%  (p=0.016 n=4+5)
Fnv128aKB-4   9.11µs ± 0%   6.17µs ± 5%  -32.32%  (p=0.008 n=5+5)

name         old speed     new speed     delta
Fnv128KB-4   106MB/s ± 0%  168MB/s ± 0%  +58.44%  (p=0.016 n=4+5)
Fnv128aKB-4  112MB/s ± 0%  166MB/s ± 5%  +47.85%  (p=0.008 n=5+5)

Change-Id: Id752f2a20ea3de23a41e08db89eecf2bb60b7e6d
Reviewed-on: https://go-review.googlesource.com/c/133936
Run-TryBot: Matt Layher <mdlayher@gmail.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>

I think we ought to make these tests hermetic, but in the meantime we
should at least make them pass.

Fixes #27692
Updates #28856

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

Fixes #26144

Change-Id: Ie69dab1bd819eaf158be11769903b2636bbcf516
Reviewed-on: https://go-review.googlesource.com/c/152165
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Nikhil Benesch <nikhil.benesch@gmail.com>

Since CL 148517, several commands (including list and get) work when
GO111MODULE=on even when no go.mod file is present. This broke an
assumption made by "fix" and "generate" which caused panics when run
with a list of .go files (whether or not the command was run inside a
module).

This change fixes those assumptions and adds test cases for other
commands run outside modules.

Fixes #29097

Change-Id: I7927559769c5d4617d73eb63f3b17e2f26d8c219
Reviewed-on: https://go-review.googlesource.com/c/153158Reviewed-by: Bryan C. Mills <bcmills@google.com>

Fixes #25953

Change-Id: I4f3a64b42fce76cc5ea6cfe2888d103c7423457d
Reviewed-on: https://go-review.googlesource.com/c/126736Reviewed-by: Bryan C. Mills <bcmills@google.com>

This commit moves cmd/internal/xcoff package to internal/xcoff because
it will be needed to add XCOFF support in go/internal/gccgoimporter.

Change-Id: Id12df0c438fb7db4a6a458fc1478480851bf7771
Reviewed-on: https://go-review.googlesource.com/c/152719
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

TrailingZeros16 is the only one of the TrailingZeros functions with a
named return value in the signature. This creates a sligthly
unpleasant effect in the godoc listing:

  func TrailingZeros(x uint) int
  func TrailingZeros16(x uint16) (n int)
  func TrailingZeros32(x uint32) int
  func TrailingZeros64(x uint64) int
  func TrailingZeros8(x uint8) int

Since the named return value is not even used, remove it.

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

Also skip TestNooptCgoBuild in short mode.

Also fix a couple of obscure constants to use values named in
cmd/internal/dwarf.

This brings the time of the cmd/link/internal/ld tests down to about 1
second on my laptop.

Updates #26470

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

IsSliceInBounds(x, y) asserts that y is not negative, but
there were cases where this is not true.  Change code
generation to ensure that this is true when it's not obviously
true.  Prove phase cleans a few of these out.

With this change the compiler text section is 0.06% larger,
that is, not very much.  Benchmarking still TBD, may need
to wait for access to a benchmarking box (next week).

Also corrected run.go to handle '?' in -update_errors output.

Fixes #28797.

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

To prevent confusion, go mod init should not allow version strings in
the module path when provided as an argument. Instead, fail with a
useful error message.

Fixes #28803

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

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

Fixes #26917

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

That file is supposed to make unexpected dependencies on the main
module easier to diagnose in 'go test cmd/go', but I accidentally left
off the build constraint, so it was triggering outside of the test.

Updates #29097

Change-Id: I1cde3fe6c1d80add37c98a8c95ce48524ea05024
Reviewed-on: https://go-review.googlesource.com/c/153159
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>

After a recent change to runtime-gdb_test.go the ppc64le builder
has had intermittent failures. The failures occur when trying to
invoke the goroutineCmd function to display the backtrace for
a selected goroutine. There is nothing wrong with the testcase
but it seems to intermittently leave goroutines in a state
where an error can occur.

The error message indicates that the problem occurs when trying
to change the sp back to the original after displaying the
stacktrace for the goroutine.

gdb.error: Attempt to assign to an unmodifiable value.

After some searching I found that this error message can happen
if the sp register is changed when on a frame that is not the
top-most frame. To fix the problem, frame 0 is selected before
changing the value of sp. This fixes the problem in my
reproducer environment, and hopefully will fix the problem on
the builder.

Updates #28679

Change-Id: I329bc95b30f8c95acfb161b0d9cfdcbd917a1954
Reviewed-on: https://go-review.googlesource.com/c/152540
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

A mark worker goroutine may attempt to preempt the mark termination
goroutine to scan its stack while the mark termination goroutine is
trying to preempt that worker to flush its work buffer, in rare
cases.

This change makes it so that, like a worker goroutine, the mark
termination goroutine stack is preemptible while it is on the
system stack, attempting to preempt others.

Fixes #28695.

Change-Id: I23bbb191f4fdad293e8a70befd51c9175f8a1171
Reviewed-on: https://go-review.googlesource.com/c/153077Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Updates #26241

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

Updates #28152

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

I didn't bother with a test as there doesn't seem to be an existing
framework for testing assembler failures, and tests for invalid code
aren't all that interesting.

Fixes #26700

Change-Id: I719410d83527802a09b9d38625954fdb36a3c0f7
Reviewed-on: https://go-review.googlesource.com/c/153177
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #27736.

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

This speeds up the cmd/cover testsuite by about 40% on my laptop.

Updates #26473
Updates #28386

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

After CL 128056 the build fails on darwin/386 with

  src/crypto/x509/root_cgo_darwin.go:218:55: warning: values of type 'SInt32' should not be used as format arguments; add an explicit cast to 'int' instead [-Wformat]
  go build crypto/x509: C compiler warning promoted to error on Go builders

Fix the warning by explicitly casting the argument to an int as
suggested by the warning.

Change-Id: Icb6bd622a543e9bc5f669fd3d7abd418b4a8e579
Reviewed-on: https://go-review.googlesource.com/c/152958
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

If the replacements specify one or more versions, we choose the latest
(for consistency with the QueryPackage path, with resolves the latest
version from upstream).

Otherwise, we synthesize a pseudo-version with a zero timestamp and an
appropriate major version.

Fixes #26241

RELNOTE=yes

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

In order to further diagnose #27993, I need to see exactly what
pointers are being added to the gcWork buffer too late.

Change-Id: I8d92113426ffbc6e55d819c39e7ab5eafa68668d
Reviewed-on: https://go-review.googlesource.com/c/152957
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

Unlike "/v1", "/v" is not likely to be mistaken for a semantic import path.

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

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

This makes a change to disasm.go so it provides consistent output
with the recent updates to arch/ppc64.

Change-Id: I812e5da2423fd1a84406032fd91ddf9cc86b7c69
Reviewed-on: https://go-review.googlesource.com/c/152761Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

- follow wording of cmd/compile more closely
- only print base of a package path to avoid overly long error messages

Fixes #26234.

Change-Id: I47a8c64b3adcf73980cd296a24cf8ac721e5df06
Reviewed-on: https://go-review.googlesource.com/c/152764
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

The source.offs field was intended for computing line offsets which
may allow a tiny optimization (see TODO in source.go). We haven't
done the optimization, so for now just remove the field to avoid
confusion. It's trivially added if needed.

While at it, also:

- Fix comment for ungetr2.
- Make sure sentinel is present even if reading from the io.Reader failed.

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

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

Now that the cgo and no-cgo paths should be correct and equivalent,
re-enable the TestSystemRoots test without any margin of error (which
was tripping anyway when users had too many of a certain edge-case).

As a last quirk, the verify-cert invocation will validate certificates
that aren't roots, but are signed by valid roots. Ignore them.

Fixes #24652

Change-Id: I6a8ff3c2282136d7122a4e7e387eb8014da0d28a
Reviewed-on: https://go-review.googlesource.com/c/128117
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

Certificates without any trust settings might still be in the keychain
(for example if they used to have some, or if they are intermediates for
offline verification), but they are not to be trusted. The only ones we
can trust unconditionally are the ones in the system roots store.

Moreover, the verify-cert invocation was not specifying the ssl policy,
defaulting instead to the basic one. We have no way of communicating
different usages in a CertPool, so stick to the WebPKI use-case as the
primary one for crypto/x509.

Updates #24652

Change-Id: Ife8b3d2f4026daa1223aa81fac44aeeb4f96528a
Reviewed-on: https://go-review.googlesource.com/c/128116Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@golang.org>