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>

The cgo path was not taking policies into account, using the last
security setting in the array whatever it was. Also, it was not aware of
the defaults for empty security settings, and for security settings
without a result type. Finally, certificates restricted to a hostname
were considered roots.

The API docs for this code are partial and not very clear, so this is a
best effort, really.

Updates #24652

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

Change-Id: I5f0ceeca2025cf19bcf610e150f7b7067fdd7397
Reviewed-on: https://go-review.googlesource.com/c/152637Reviewed-by: Andrew Bonventre <andybons@golang.org>

Fixes golang/go#27047

Change-Id: I0dd40201fc03e87fbc674b47bdf9315f1783d6c2
GitHub-Last-Rev: f28ab6234ade814c4bc09e26417c424c843ad57b
GitHub-Pull-Request: golang/go#27048
Reviewed-on: https://go-review.googlesource.com/c/129696Reviewed-by: komu wairagu <komuw05@gmail.com>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

Currently,

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

will compile to have write barriers even if a is a slice of pointers
to go:notinheap types. This happens because the optimization that
transforms this into a memclr only asks it a's element type has
pointers, and not if it specifically has heap pointers.

Fix this by changing arrayClear to use HasHeapPointer instead of
types.Haspointers. We probably shouldn't have both of these functions,
since a pointer to a notinheap type is effectively a uintptr, but
that's not going to change in this CL.

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

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>