Lack of a well-defined order between VarDef and related
address operations sometimes causes problems with store order
and write barrier transformations; glitches in the order are
made irreparable (by later optimizations) if the two parts of
the glitch straddle a split in the original block caused by
insertion of a write barrier diamond.

Fix this by creating a LocalAddr for addresses of locals
(what VarDef matters for) that takes a memory input to
help make the order explicit.  Addr is modified to only
be legal for SB operand, so there is no overlap between
Addr and LocalAddr uses (there may be some downstream
cleanup from this).

Changes to generic.rules and rewrite.go ensure that codegen
tests continue to pass; CSE of LocalAddr is impaired, not
quite sure of the cost.

Fixes #26105.

Change-Id: Id4192b4440aa4e9d7ba54a465c456df9b530b515
Reviewed-on: https://go-review.googlesource.com/122483
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>

The behavior of -a no longer changes depending on which kind
of branch of Go you are using (the new build cache fixed all that).
These tests are not doing anything useful (and failing).

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

API compatibility violation, but it wasn't safe before and people
should be using golang.org/x/sys/windows instead.

Fixes #24820

Change-Id: I3b43493f56b3116924b9d848a294899279f314fd
Reviewed-on: https://go-review.googlesource.com/123455
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

The existing example code uses variable name d, but
prints t in its output. It's needlessly confusing.

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

Updates bundled x/net/http2 to git rev cffdcf67 for:

    http2: use GetBody unconditionally on Transport retry, when available
    https://golang.org/cl/123476

    http2: a closed stream cannot receive data
    https://golang.org/cl/111676

Updates #25009
Updates #25023

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

Change-Id: I877c82788f3edbcb0b334b42049c1a06f36a6477
Reviewed-on: https://go-review.googlesource.com/123517Reviewed-by: Rob Pike <r@golang.org>

Updates #26340

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

For #23399

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

Change "have to" to "need to" for clarity and to avoid a
peculiar English idiom.

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

For golang.org/cl/74110, I forgot that you can use range-based for
loops to extract key values from a map value.

This wasn't a problem for the binary format importer, because it was
more tolerant about missing inline function bodies. However, the
indexed importer is more particular about this.

We could potentially just make it more lenient like the binary
importer, but tweaking the logic here is easy enough and seems like
the preferable solution.

Fixes #26341.

Change-Id: I54564dcd0be60ea393f8a0f6954b7d3d61e96ee5
Reviewed-on: https://go-review.googlesource.com/123475
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>

GOCACHE=off is not a reliable signal of user intent.

At startup the go command fills in an empty GOCACHE with the effective setting.
If $HOME is set, then GOCACHE ends up somewhere in $HOME/.cache.
But if $HOME is unset, then the go command sets GOCACHE=off explicitly.

That environment is used for invoking "go tool dist".

So if the machine has no $HOME, then go tool dist ends up with the cache
disabled even though the user was not trying to disable the cache.
This affects the linux-ppc64le builder, which appears to be unique
among builders in not having $HOME set. So that builder is running
with no build cache.

Now that there is a cmd/go test that needs the cache to be on,
the linux-ppc64le builder is failing.

In the next release we intend to force the use of the build cache
always. This CL is not doing that: it's only forcing the use of the
build cache during all.bash, which won't affect the majority of
our users (they run pre-build binary releases).

If this is a problem we can roll it back and fix the linux-ppc64le
builders some other way.

While we're here, print a few more useful variables in 'go tool dist env'
and sort the output.

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

Fixes #26329

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

Fixes #26220

Change-Id: I05703912be594d985ad3ccb3a9757ae21ec738ab
GitHub-Last-Rev: e4649847e015e573ee169c7d6db29b9437841afd
GitHub-Pull-Request: golang/go#26293
Reviewed-on: https://go-review.googlesource.com/122715Reviewed-by: Ian Lance Taylor <iant@golang.org>

Also, remove some test code that was trying to work on XP and fix up
some comments referencing XP.

Fixes #26191
Updates #23380

Change-Id: I0b7319fe1954afddb22d396e5ec91d8c960268d8
Reviewed-on: https://go-review.googlesource.com/123415
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fix the panic message produced for an interface conversion error to
only say "types from different packages" if they are definitely from
different packges. If they may be from the same package, say "types
from different scopes."

Updates #18911
Fixes #26094

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

DWARF compression accounts for roughly 30% of the linker's time. This
CL switches from DefaultCompression to BestSpeed, which virtually
eliminates this time. This roughly halves the overhead of handling
DWARF in the linker:

name \ time/op         nodwarf     dwarf        dwarf-speed
BuildCmdGoAll          10.0s ±11%   10.6s ± 5%   10.8s ± 5%
             nodwarf                  +6.41%       +8.03%
               dwarf                                 ~
LinkCmdGo              626ms ± 5%  1096ms ± 2%   860ms ± 2%
             nodwarf                 +75.17%      +37.36%
               dwarf                              -21.59%

Previously, enabling DWARF had a 75% overhead in link time for cmd/go.
This change reduces this overhead to 37% (a 22% reduction).

The effect on binary size is minimal compared to DefaultCompression,
and still substantially better than no compression:

             cmd/go bytes
nodwarf      10106953
dwarf        12159049 nodwarf+20%
dwarf-speed  12408905 nodwarf+23%
dwarf-nozlib 17766473 nodwarf+76%

Updates #26318.

Change-Id: I33bb7caa038a2753c29104501663daf4839e7054
Reviewed-on: https://go-review.googlesource.com/123356
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>

Based on Dmitry Vyukov's comments in CL 65210.

Change-Id: I5dce7286b0d180cd43cad3aaf70f537fafcda588
Reviewed-on: https://go-review.googlesource.com/123275Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Remove some incorrect code that was present after since I added
support for idle timeouts in CL 22670.

This code actually caused a bug (a rare goroutine leak) rather than
prevent a bogus connection reuse.

The t.idleMu mutex already protects most the invariants, including an
explicit Stop call. There's only one Stop call on that timer, and it's
guarded by t.idleMu. What idleMu doesn't protect against is the timer
firing on its own. But we don't need code to protect against that case
because the goroutine that is created via AfterFunc when the timer
fires already checks the invariants:

  // closeConnIfStillIdle closes the connection if it's still sitting idle.
  // This is what's called by the persistConn's idleTimer, and is run in its
  // own goroutine.
  func (pc *persistConn) closeConnIfStillIdle() {
     t := pc.t
     t.idleMu.Lock()
     defer t.idleMu.Unlock()
     if _, ok := t.idleLRU.m[pc]; !ok {
       // Not idle.
       return
     }

(note the "Not idle." part).

Tested by hand with the repro code from #25621. No more leaks.

Fixes #25621

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

Updates #26335

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

OpenBSD 6.4 will require the stack pointer to be pointing at an area that is
marked as MAP_STACK when entering and exiting syscalls. Adjust the stack pointer
used for a new thread such that it points within the stack, not at the top of
it (i.e. outside).

Fixes #26142

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

Private fields of the Go class are not used any more after the program
has exited. Delete them to allow JavaScript's garbage collection to
clean up the WebAssembly instance.

Updates #26193.

Change-Id: I349784a49eaad0c22ceedd4f859df97132775537
Reviewed-on: https://go-review.googlesource.com/122296
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

In general, dumb terminal indicates terminal with limited capability.
It may provide no support for special character sequences, e.g., no
handling of ANSI escape sequences. Its input/output handling behavior
may deviate from what's described in termios or terminfo. E.g., in
the shell in emacs, even after successfully setting the terminal to
raw mode, the terminal behaves as if it's still operating in canonical
mode since emacs is doing input processing first.

Readline support can be broken in various ways in dumb terminal mode,
so we want to disable readline or advanced UI features. The easiest
way to detect dumb terminal is to check the environment variable "TERM".

Fixes #26254

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

Taking a read lock in SetBlocking could cause SetBlocking to block
waiting for a Read in another goroutine to complete. Since SetBlocking
is called by os.(*File).Fd, that could lead to deadlock if the
goroutine calling Fd is going to use it to unblock the Read.
Use an atomic store instead.

Updates #24481

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

Change-Id: I6be6818d951a999f916c2266a6753a5ce5144ee7
Reviewed-on: https://go-review.googlesource.com/122955Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Recognize NetBSD in:
 - go/internal/work/init.go
 - race.bash
 - runtime/race/race.go

Add __ps_strings symbol in runtime/cgo/netbsd.go as this is
used internally in the TSan library for NetBSD and used for
ReExec().

Tested on NetBSD/amd64 v. 8.99.12.

Around 98% tests are passing for the ./race.bash target.

Updates #19273

Change-Id: Ic0e48d2fb159a7868aab5e17156eeaca1225e513
GitHub-Last-Rev: d6e082707b9b18df1fe63f723666f4d2eb5e6cfe
GitHub-Pull-Request: golang/go#24322
Reviewed-on: https://go-review.googlesource.com/99835Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #21780

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

Updates #23188

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

Change-Id: I18a6915614a317adb4da710a01268b574300f0e0
Reviewed-on: https://go-review.googlesource.com/123096
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

When generating an abstract function DIE, call objabi.PathToPrefix on
the import path so as to be consistent with how the linker handles
import paths. This is intended to resolve another problem with DWARF
inline info generation in which there are multiple inconsistent
versions of an abstract function DIE for a function whose package path
is rewritten/canonicalized by objabi.PathToPrefix.

Fixes #26237

Change-Id: I4b64c090ae43a1ad87f47587a1a71f19bc5fc8e8
Reviewed-on: https://go-review.googlesource.com/123036
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Functions exported on behalf of other packages need to have their
argument stack maps specified explicitly.  They don't get an implicit
map because they are not in the local package, and if they get defer'd
they need argument maps.

Fixes #24419

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

At the moment, method declarations are type-checked together with
they receiver base types. This is a known problem (to be fixed early
for Go 1.12) but with the new cycle detection algorithm now also
introduced artifical type cycles.

This change pushes a special marker on the cycle path in those cases
so that these cycles can be ignored.

Fixes #26124.

Change-Id: I64da4ccc32d4ae293da48880c892154a1c6ac3fe
Reviewed-on: https://go-review.googlesource.com/121757
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

The clang compiler on some terminals will issue colored error
messages, which can confuse tools like cgo. To avoid this we used to
set TERM=dumb for all programs started by the go tool. However, that
confuses the pprof tool, which doesn't know whether to support fancy
editing and colors itself.

Instead, change the go tool and the cgo tool to set TERM=dumb where it
matters--when invoking the C compiler--rather than in all cases.

Updates #26254

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

More test cases of combined load for arm64.

Change-Id: I7a9f4dcec6930f161cbded1f47dbf7fcef1db4f1
Reviewed-on: https://go-review.googlesource.com/122582
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Also populate Imports for test main with go list -test.

Update comment in internal/load/test.go about
p.Imports, p.Internal.RawImports, and p.Imports
being perfectly aligned. The first two are,
but the third is not, as evidenced by CL 111175.

Since p.Imports is not aligned, don't assume that anymore.

Fixes #25949.

Change-Id: Icbfbc881bc01d1e195a759648fbd1c978ddbc161
Reviewed-on: https://go-review.googlesource.com/122878
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

The existing algorithm assumed that the length of a cycle was simply
the number of elements in the cycle slice starting at the start object.
However, we use a special "indir" indirection object to indicate
pointer and other indirections that break the inline placement of
types in composite types. These indirection objects don't exist as
true named type objects, so don't count them anymore.

This removes an unnecessary cycle error in one of the existing tests
(testdata/issues.src:100).

Also:
- added more tracing support (only active if tracing is enabled)
- better documentation in parts
- r/check.typ/check.typExpr/ in a few of places where we don't
  need to record a type indirection

Found while investigating #26124.

Change-Id: I45341743225d979a72af3fbecfa05012b32fab67
Reviewed-on: https://go-review.googlesource.com/121755
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

Fixes #26309

Change-Id: I0e0b61b885817e514aa46e299b00833f16e98b2a
Reviewed-on: https://go-review.googlesource.com/122898Reviewed-by: Айнар Гарипов <gugl.zadolbal@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Updates http2 to x/net/http2 git rev 292b43b for:

    http2: reject incoming HEADERS in Server on half-closed streams
    https://golang.org/cl/111677

Updates #25023

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

cmd/cover has always assumed that package x/y/z can be
found in $GOPATH/src/x/y/z (roughly; by using go/build).
That won't be true for too much longer. Instead, run the
go command to find out where packages are.

This will make 'go tool cover' safe for use with Go modules
when they are in use in Go 1.11, and it continues to work
with the existing Go toolchains too.

An alternative would be to modify the cover profile format
to record file names directly, but that would require also
updating golang.org/x/tools/cover/profile and any tools
that use it, which seems not worth the trouble.
(That fork of the code does not contain any code to resolve
package names to directory locations, so it's unaffected.)

No new test here: cmd/go's TestCoverageFunc tests this code.

Fixes #25318 (when people use Go 1.11 instead of vgo).

Change-Id: I8769b15107aecf25f7aaf8692b724cf7d0f073d0
Reviewed-on: https://go-review.googlesource.com/122478
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

CL 122518 rolled back an earlier CL that made "go test"
start running test binaries for packages with no *_test.go files.
Add a test as another roadblock to reintroducing that behavior
in the future.

For #26462.

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