Fixes #32038

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

Test case for issue 32233.

Updates #32233.

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

Checks if modules are enabled in GOPATH mode for go mod [graph, verify].
Added tests for GO111MODULE=[auto, off].

Fixes: #31237

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

The existing check was introduced to allow tests to pass
on WASM without an environment where the fetch RoundTripper
could run. However, the check now prohibits the use of the
Fetch RoundTripper in all WASM tests, even where the
RoundTripper could run. The new change should only disable
the RoundTripper when used in an environment without fetch.

Fixes #32289

Change-Id: I30d2e0dbcb0e64d4b1a46b583f7e984c2a57d5e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/179118
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

A couple of regexp.MustCompile globals have made their way in since we
introduced this package for cmd/go.

Convert the declarations. It's just two of them, so the cmd/go exec
benchmark isn't affected noticeably.

Change-Id: Ibd0615c99b6a049124a952c59978fd714c1b9615
Reviewed-on: https://go-review.googlesource.com/c/go/+/179358
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Passing test that shows Apple's symbols utility can now read
DWARF data in go.o, after the fix in CL174538

Updates #31022 #22716 #31459

Change-Id: I56c3517ad6d0a9f39537182f63cef56bb198aa83
Reviewed-on: https://go-review.googlesource.com/c/go/+/170451Reviewed-by: Than McIntosh <thanm@google.com>

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

This pulls in CL 179317 which fixes the build on aix/ppc64.

Change-Id: I7d90950800627904503db97cfb0bc670a45b701e
Reviewed-on: https://go-review.googlesource.com/c/go/+/179357
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates #22326.

Change-Id: Ia9173b6eb29b2a4f90f4ba39bf53b6e9b7a6d6bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/179398
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

This CL rewrites cmd/compile's package-level initialization ordering
algorithm to be compliant with the Go spec. See documentation in
initorder.go for details.

Incidentally, this CL also improves fidelity of initialization loop
diagnostics by including referenced functions in the emitted output
like go/types does.

Fixes #22326.

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

Incredibly, the subsystem version numbers in the PE header influence how
win32k handles various syscalls. The first time a win32k syscall is
invoked and the kernel upgrades the thread object to a tagTHREADINFO
with all of the lovely undocumented UI members and such, it sets the
dwExpWinVer member (offset 624 in Windows 10 build 1809) to the result
of RtlGetExpWinVer(PsGetProcessSectionBaseAddress(proc)).
RtlGetExpWinVer, also undocumented, then calls into the undocumented
RtlImageNtHeader function, which returns a fortunately documented
IMAGE_NT_HEADERS structure. It uses the subsystem members in there to
set the dwExpWinVer member of our newly minted tagTHREADINFO object.
Later, functions like SendInput consult this to vary their behaviors and
return values. In fact, littered through out win32k are checks like `if
(gsti->dwExpWinVer >= 0x501) { ... }`.

I don't think Go ever supported NT 4.0. These days the minimum version
is Windows 7, which is 6.1. So, let's set the version numbers in the PE
header at that, which should give us the behavior that MSDN advertises
for various functions, as opposed to bizarre archeological remnants.

Interestingly, I suspect that most people never noticed the brokenness,
because most people trying to do serious Win32 UI stuff wind up linking
in cgo, if not for actually using C, then just to have a larger system
stack so that the stack doesn't get corrupted by various UI functions.
When MingW is used, the PE header gets a later version. But recently
there's been a bug report of some people trying to do more modest UI
manipulation using SendInput in a setting where this cgo hack probably
isn't required, so they ran into the weird historical compatibility
stuff.

Fixes #31685

Change-Id: I54461ce820f6e9df349e37be5ecc5a44c04a3e26
Reviewed-on: https://go-review.googlesource.com/c/go/+/178977
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The default is now "https://proxy.golang.org,direct" not just "https://proxy.golang.org"
(as of CL 178720).

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

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

Fixes #32102

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

One of these tests creates a bunch of connections concurrently, then
discovers it doesn't need them all, which then makes the server log
that the client went away midway through the TLS handshake. Perhaps
the server should recognize that as a case not worthy of logging
about, but this is a safer way to eliminate the stderr spam during go
test for now.

The other test's client gives up on its connection and closes it,
similarly confusing the server.

Change-Id: I49ce442c9a63fc437e58ca79f044aa76e8c317b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/179179
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

The code in #29218 resulted in an If block containing only its control.
That block was then converted by fuseIf into a plain block;
as a result, that control value was dead.
However, the control value was still present in b.Values.
This prevented further fusing of that block.

This change beefs up the check in fuseIf to allow fusing
blocks that contain only dead values (if any).
In the case of #29218, this enables enough extra
fusing that the control value could be eliminated,
allowing all values in turn to be eliminated.

This change also fuses 34 new blocks during make.bash.

It is not clear that this fixes every variant of #29218,
but it is a reasonable standalone change.
And code like #29218 is rare and fundamentally buggy,
so we can handle new instances if/when they actually occur.

Fixes #29218

Negligible toolspeed impact.

name        old time/op       new time/op       delta
Template          213ms ± 3%        213ms ± 2%    ~     (p=0.914 n=97+88)
Unicode          89.8ms ± 2%       89.6ms ± 2%  -0.22%  (p=0.045 n=93+95)
GoTypes           712ms ± 3%        709ms ± 2%  -0.35%  (p=0.023 n=95+95)
Compiler          3.24s ± 2%        3.23s ± 2%  -0.30%  (p=0.020 n=98+97)
SSA               10.0s ± 1%        10.0s ± 1%    ~     (p=0.382 n=98+99)
Flate             135ms ± 3%        135ms ± 2%    ~     (p=0.983 n=98+98)
GoParser          158ms ± 2%        158ms ± 2%    ~     (p=0.170 n=99+99)
Reflect           447ms ± 3%        447ms ± 2%    ~     (p=0.538 n=98+89)
Tar               189ms ± 2%        189ms ± 3%    ~     (p=0.874 n=95+96)
XML               251ms ± 2%        251ms ± 2%    ~     (p=0.434 n=94+96)
[Geo mean]        427ms             426ms       -0.15%

name        old user-time/op  new user-time/op  delta
Template          264ms ± 2%        265ms ± 2%    ~     (p=0.075 n=96+90)
Unicode           119ms ± 6%        119ms ± 7%    ~     (p=0.864 n=99+98)
GoTypes           926ms ± 2%        924ms ± 2%    ~     (p=0.071 n=94+94)
Compiler          4.38s ± 2%        4.37s ± 2%  -0.34%  (p=0.001 n=98+97)
SSA               13.4s ± 1%        13.4s ± 1%    ~     (p=0.693 n=90+93)
Flate             162ms ± 3%        161ms ± 2%    ~     (p=0.163 n=99+99)
GoParser          186ms ± 2%        186ms ± 3%    ~     (p=0.130 n=96+100)
Reflect           572ms ± 3%        572ms ± 2%    ~     (p=0.608 n=97+97)
Tar               239ms ± 2%        239ms ± 3%    ~     (p=0.999 n=93+91)
XML               302ms ± 2%        302ms ± 2%    ~     (p=0.627 n=91+97)
[Geo mean]        540ms             540ms       -0.08%

file    before    after     Δ       %       
asm     4862704   4858608   -4096   -0.084% 
compile 24001568  24001680  +112    +0.000% 
total   132520780 132516796 -3984   -0.003% 

file                       before    after     Δ       %       
cmd/compile/internal/gc.a  8887638   8887596   -42     -0.000% 
cmd/compile/internal/ssa.a 29995056  29998986  +3930   +0.013% 
cmd/internal/obj/wasm.a    209444    203652    -5792   -2.765% 
total                      129471798 129469894 -1904   -0.001% 

Change-Id: I2d18f9278e68b9766058ae8ca621e844f9d89dd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/177140
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>

It was added in CL 83956 but never used.

Updates #23129

Change-Id: I70b50e974a56620069a77658386722af314cc857
Reviewed-on: https://go-review.googlesource.com/c/go/+/179138
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Iec4348eb674c8c64497c82e5d7cd656736cfcebd
GitHub-Last-Rev: 462c323960be0ca1c126c051ab97f72949bdc2b6
GitHub-Pull-Request: golang/go#32225
Reviewed-on: https://go-review.googlesource.com/c/go/+/178797Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #32119

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

There was an implicit heuristic before about when to print the
package clause or omit it, but it was undocumented and confusing.
Get rid of it and print it always unless asking for the package
docs for a command, which are more of a usage message than a
programming question. This simplifies the processing.

There are several paths to the output, so to put the fix in one
place we place a wrapper before the output buffer than adds the
clause when Write is first called.

The tests don't verify this behavior, but they didn't before either.
Unsure what the right approach is but this will do for now.

Fixes #31457

Change-Id: Ia6a9e740d556f45265c55f06b5306621c7a40ea9
Reviewed-on: https://go-review.googlesource.com/c/go/+/177797Reviewed-by: Russ Cox <rsc@golang.org>

These tests assume that it is OK to switch between time implementations,
but the clock_gettime call uses CLOCK_MONOTONIC and the fallback call,
gettimeofday, uses CLOCK_REALTIME. Disabling the clock_gettime call means
that calls to nanotime will start returning very different values.
This breaks the new timer code, which assumes that nanotime will return
a consistently increasing value.

This test is not very useful in any case as it doesn't check the results.

Removing this file also removes BenchmarkTimeNow, which is a duplicate
of BenchmarkNow in the time package.

Updates #27707
Fixes #32109

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

Fixes #32044

Change-Id: Ia220dbbe4d6851befe28dd2d4b8a1a7bc2757460
Reviewed-on: https://go-review.googlesource.com/c/go/+/178878
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

The constant defined in macho.go for LC_LOAD_WEAK_DYLIB was
not correct, was 0x18 should have been 0x80000018. Switch
to the correct definition.

Fixes #32233.

Change-Id: I9fb660a3cfd5e8c451a64947258f7ead76d98c79
Reviewed-on: https://go-review.googlesource.com/c/go/+/178723
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>

Getenv("GOPROXY") says what the environment variable is
(including looking in the go env file), but it doesn't include
the default setting. This code needs to use cfg.GOPROXY
to get the actual default. Fix and test that.

Also, we forgot to include the fallback to direct for when
the proxy serves a 404. Add and test that too.

Also add HTTP fetch information to -x build flag output.
(It does not belong in the -v output, despite the GOPATH go get
command doing this.)

Change-Id: Ieab7ef13cda3e1ad041dbe04921af206e2232c9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/178720
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

Since we're mucking with error-propagation in modload.Query* anyway,
simplify the classification logic. Ensure that “module not found”
errors are reported as such in various places, since non-“not found”
errors terminate the module search.

Fixes #31785

Change-Id: Ie3ca5f4eec10a5f2a6037ec7e1c2cf47bd37a232
Reviewed-on: https://go-review.googlesource.com/c/go/+/177958
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Following the previous CL, this removes more global variables on
Wasm.

PC_B is used mostly for intra-function jumps, and for a function
telling its callee where to start or resume. This usage can be
served by a parameter. The top level loop (wasm_pc_f_loop) uses
PC_B for resuming a function. This value is either set by gogo,
or loaded from the Go stack at function return. Instead of
loading PC_B at each function return, we could make gogo stores
PC_B at the same stack location, and let the top level loop do
the load. This way, we don't need to use global PC_B to
communicate with the top level loop, and we can replace global
PC_B with a parameter.

PC_F is similar. It is even more so in that the only reader is
the top level loop. Let the top level loop read it from the stack,
and we can get rid of PC_F entirely.

PC_F and PC_B are used less entensively as SP, so this CL has
smaller performance gain.

Running on Chrome 74.0.3729.108 on Linux/AMD64,

name                   old time/op    new time/op    delta
BinaryTree17              16.6s ± 0%     16.2s ± 1%   -2.59%  (p=0.016 n=4+5)
Fannkuch11                11.1s ± 1%     10.8s ± 0%   -2.65%  (p=0.008 n=5+5)
FmtFprintfEmpty           231ns ± 1%     217ns ± 0%   -6.06%  (p=0.008 n=5+5)
FmtFprintfString          407ns ± 3%     375ns ± 2%   -7.81%  (p=0.008 n=5+5)
FmtFprintfInt             466ns ± 2%     430ns ± 0%   -7.79%  (p=0.016 n=5+4)
FmtFprintfIntInt          719ns ± 2%     673ns ± 2%   -6.37%  (p=0.008 n=5+5)
FmtFprintfPrefixedInt     706ns ± 1%     676ns ± 3%   -4.31%  (p=0.008 n=5+5)
FmtFprintfFloat          1.01µs ± 1%    0.97µs ± 1%   -4.30%  (p=0.008 n=5+5)
FmtManyArgs              2.67µs ± 1%    2.51µs ± 1%   -5.95%  (p=0.008 n=5+5)
GobDecode                30.7ms ± 9%    31.3ms ±34%     ~     (p=0.222 n=5+5)
GobEncode                24.2ms ±23%    20.2ms ± 0%  -16.36%  (p=0.016 n=5+4)
Gzip                      852ms ± 0%     823ms ± 0%   -3.38%  (p=0.016 n=4+5)
Gunzip                    160ms ± 1%     151ms ± 1%   -5.37%  (p=0.008 n=5+5)
JSONEncode               35.7ms ± 1%    34.3ms ± 1%   -3.81%  (p=0.008 n=5+5)
JSONDecode                247ms ± 8%     254ms ± 7%     ~     (p=0.548 n=5+5)
Mandelbrot200            5.39ms ± 0%    5.41ms ± 0%   +0.42%  (p=0.008 n=5+5)
GoParse                  18.5ms ± 1%    18.3ms ± 2%     ~     (p=0.343 n=4+4)
RegexpMatchEasy0_32       424ns ± 2%     397ns ± 0%   -6.23%  (p=0.008 n=5+5)
RegexpMatchEasy0_1K      2.88µs ± 0%    2.86µs ± 1%     ~     (p=0.079 n=5+5)
RegexpMatchEasy1_32       395ns ± 2%     370ns ± 1%   -6.23%  (p=0.008 n=5+5)
RegexpMatchEasy1_1K      3.26µs ± 0%    3.19µs ± 1%   -2.06%  (p=0.008 n=5+5)
RegexpMatchMedium_32      564ns ± 1%     532ns ± 0%   -5.71%  (p=0.008 n=5+5)
RegexpMatchMedium_1K      146µs ± 2%     140µs ± 1%   -4.62%  (p=0.008 n=5+5)
RegexpMatchHard_32       8.47µs ± 1%    7.91µs ± 1%   -6.65%  (p=0.008 n=5+5)
RegexpMatchHard_1K        253µs ± 1%     236µs ± 2%   -6.66%  (p=0.008 n=5+5)
Revcomp                   1.78s ± 4%     1.76s ± 5%     ~     (p=1.000 n=5+5)
Template                  292ms ±29%     269ms ± 5%     ~     (p=0.690 n=5+5)
TimeParse                1.61µs ± 4%    1.54µs ± 1%   -4.42%  (p=0.008 n=5+5)
TimeFormat               1.66µs ± 3%    1.58µs ± 1%   -5.22%  (p=0.008 n=5+5)
[Geo mean]                232µs          221µs        -4.54%

name                   old speed      new speed      delta
GobDecode              25.0MB/s ± 8%  25.1MB/s ±27%     ~     (p=0.222 n=5+5)
GobEncode              32.8MB/s ±21%  38.0MB/s ± 0%  +15.84%  (p=0.016 n=5+4)
Gzip                   22.8MB/s ± 0%  23.6MB/s ± 0%   +3.49%  (p=0.016 n=4+5)
Gunzip                  121MB/s ± 1%   128MB/s ± 1%   +5.68%  (p=0.008 n=5+5)
JSONEncode             54.4MB/s ± 1%  56.5MB/s ± 1%   +3.97%  (p=0.008 n=5+5)
JSONDecode             7.88MB/s ± 8%  7.65MB/s ± 8%     ~     (p=0.548 n=5+5)
GoParse                3.07MB/s ± 8%  3.00MB/s ±22%     ~     (p=0.579 n=5+5)
RegexpMatchEasy0_32    75.6MB/s ± 2%  80.5MB/s ± 0%   +6.58%  (p=0.008 n=5+5)
RegexpMatchEasy0_1K     356MB/s ± 0%   358MB/s ± 1%     ~     (p=0.095 n=5+5)
RegexpMatchEasy1_32    81.1MB/s ± 2%  86.5MB/s ± 1%   +6.69%  (p=0.008 n=5+5)
RegexpMatchEasy1_1K     314MB/s ± 0%   320MB/s ± 0%   +2.10%  (p=0.008 n=5+5)
RegexpMatchMedium_32   1.77MB/s ± 1%  1.88MB/s ± 0%   +6.09%  (p=0.016 n=5+4)
RegexpMatchMedium_1K   6.99MB/s ± 2%  7.33MB/s ± 1%   +4.83%  (p=0.008 n=5+5)
RegexpMatchHard_32     3.78MB/s ± 1%  4.04MB/s ± 1%   +7.04%  (p=0.008 n=5+5)
RegexpMatchHard_1K     4.04MB/s ± 1%  4.33MB/s ± 2%   +7.17%  (p=0.008 n=5+5)
Revcomp                 143MB/s ± 4%   145MB/s ± 5%     ~     (p=1.000 n=5+5)
Template               6.77MB/s ±24%  7.22MB/s ± 5%     ~     (p=0.690 n=5+5)
[Geo mean]             24.4MB/s       25.4MB/s        +4.18%

Change-Id: Ib80716e62992aec28b2c4a96af280c278f83aa49
Reviewed-on: https://go-review.googlesource.com/c/go/+/173980
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>

Currently there's an invariant in the runtime wherein the heap lock
can only be acquired on the system stack, otherwise a self-deadlock
could occur if the stack grows while the lock is held.

This invariant is upheld and documented in a number of situations (e.g.
allocManual, freeManual) but there are other places where the invariant
is either not maintained at all which risks self-deadlock (e.g.
setGCPercent, gcResetMarkState, allocmcache) or is maintained but
undocumented (e.g. gcSweep, readGCStats_m).

This change adds go:systemstack to any function that acquires the heap
lock or adds a systemstack(func() { ... }) around the critical section,
where appropriate. It also documents the invariant on (*mheap).lock
directly and updates repetitive documentation to refer to that comment.

Fixes #32105.

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

I have seen code that literally copied the example like this:

    if strings.ContainsAny(s, "1 & 2 & 3") {

The developer apparently thought that this is the way to
specify multiple characters and I noticed this pattern
being used in the example. Let's update the example so
that it's clear how multiple Unicode code points should
be specified.

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

Change-Id: Ic5b01c0a6912d87e812331d6525939df8f525cca
GitHub-Last-Rev: b6ffefcf8f2ec1ed7ee13f36e8fef6af965ba332
GitHub-Pull-Request: golang/go#29993
Reviewed-on: https://go-review.googlesource.com/c/go/+/160417Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: If001d8f7e657e01711653827a170904932839e34
Reviewed-on: https://go-review.googlesource.com/c/go/+/178721
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Ib7be503a46f3609ea29464569e57e1f620e97a53
GitHub-Last-Rev: a43cffe45f3b9d208028f7682088cbe537d6deca
GitHub-Pull-Request: golang/go#30007
Reviewed-on: https://go-review.googlesource.com/c/go/+/160431
Run-TryBot: Leon Klingele <git@leonklingele.de>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The typed arrays returned by TypedArrayOf were backed by WebAssembly
memory. They became invalid each time we grow the WebAssembly memory.
This made them very error prone and hard to use correctly.

This change removes TypedArrayOf completely and instead introduces
CopyBytesToGo and CopyBytesToJS for copying bytes between a byte
slice and an Uint8Array. This breaking change is still allowed for
the syscall/js package.

Fixes #31980.
Fixes #31812.

Change-Id: I14c76fdd60b48dd517c1593972a56d04965cb272
Reviewed-on: https://go-review.googlesource.com/c/go/+/177537
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Utilize KDSA when available. This guarantees constant time operation on all three curves mentioned,
and is faster than conventional assembly. The IBM Z model(s) that support KDSA as used in this CL
are not yet publicly available, and so we are unable to release performance data at this time.

Change-Id: I85360dcf90fe42d2bf32afe3f638e282de10a518
Reviewed-on: https://go-review.googlesource.com/c/go/+/174437
Run-TryBot: Michael Munday <mike.munday@ibm.com>
Reviewed-by: Michael Munday <mike.munday@ibm.com>

This is now recognized and recommended by GitHub.

Fixes #32201

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

This test was designed for #15609 and didn't consider nacl. It's not
worth adding new +build-guarded assembly files in issue15609.dir for
nacl, especially as nacl is going away.

Fixes #32206

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

Replaces putUint{32,64} functions in crypto/sha* packages with the
equivalent functions encoding/binary.BigEndian.PutUint{32,64}.

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

Change-Id: Ia42a4a658e4207cc1f036f2faeac011e71edad77
GitHub-Last-Rev: b384f81799fcd404f53647d8a3015487ea240c6f
GitHub-Pull-Request: golang/go#30012
Reviewed-on: https://go-review.googlesource.com/c/go/+/160436
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Encodes non-WSP CTL and non-US-ASCII UTF-8 characters using syntax specified in RFC 2231.

Fixes #7668
Fixes #9624

Change-Id: I433f167c5bdd84a7f811ac0410b08b10790e0d9f
GitHub-Last-Rev: 9c77146760341fdb3af35c1b94d4ee00ffb0daae
GitHub-Pull-Request: golang/go#29328
Reviewed-on: https://go-review.googlesource.com/c/go/+/154760Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Float formatting uses a multiprecision fallback path where Grisu3
algorithm fails. This has a bug during the rounding phase: the
difference between the decimal value and the upper bound is examined
byte-by-byte and doesn't properly handle the case where the first
divergence has a difference of 1.

For instance (using an example from #29491), for the number
498484681984085570, roundShortest examines the three decimal values:

lower: 498484681984085536
d:     498484681984085568
upper: 498484681984085600

After examining the 16th digit, we know that rounding d up will fall
within the bounds unless all remaining digits of d are 9 and all
remaining digits of upper are 0:

d:     ...855xx
upper: ...856xx

However, the loop forgets that d and upper have already diverged and
then on the next iteration sees that the 17th digit of d is actually
lower than the 17th digit of upper and decides that we still can't round
up:

d:     ...8556x
upper: ...8560x

Thus the original value is incorrectly rounded down to
498484681984085560 instead of the closer (and equally short)
498484681984085570.

Thanks to Brian Kessler for diagnosing this bug.

Fix it by remembering when we've seen divergence in previous digits.

This CL also fixes another bug in the same loop: for some inputs, the
decimal value d or the lower bound may have fewer digits than the upper
bound, yet the iteration through the digits starts at i=0 for each of
them. For instance, given the float64 value 1e23, we have

d:      99999999999999991611392
upper: 100000000000000000000000

but the loop starts by comparing '9' to '1' rather than '0' to '1'.

I haven't found any cases where this second bug causes incorrect output
because when the digit comparison fails on the first loop iteration the
upper bound always has more nonzero digits (i.e., the expression
'i+1 < upper.nd' is always true).

Fixes #29491

Change-Id: I58856a7a2e47935ec2f233d9f717ef15c78bb2d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/157697
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rémy Oudompheng <remyoudompheng@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>