Update golang.org/x/net to the tip of internal-branch.go1.20-vendor to
include CL 468336.

The contents of that CL were already merged into this branch in CL
468122, so this CL just brings go.mod back in line to matching the
actual vendored content.

For #58356
For #57855

Change-Id: I6ee9483077630c11c725927f38f6b69a784106db
Reviewed-on: https://go-review.googlesource.com/c/go/+/468302
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>

These functions are linked using go:linkname, but do not match the
original declarations. This change brings these in sync.

For #58442.

Change-Id: I16651304c3dba2f9897c2c42e30555d2f7805c2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/466615
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
(cherry picked from commit 8fb9565)
Reviewed-on: https://go-review.googlesource.com/c/go/+/466859
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Austin Clements <austin@google.com>

…ization

There are a plenty of regression in 1.20 with this optimization. This CL
disable inline static init, so it's safer to backport to 1.20 branch.

The optimization will be enabled again during 1.21 cycle.

Fixes #58444

Change-Id: If5916008597b46146b4dc7108c6b389d53f35e95
Reviewed-on: https://go-review.googlesource.com/c/go/+/467015
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/467035
Run-TryBot: Matthew Dempsky <mdempsky@google.com>

…/defer generic calls

For go/defer calls like "defer f(x, y)", the compiler rewrites it to:

	x1, y1 := x, y
	defer func() { f(x1, y1) }()

However, if "f" needs runtime type information, the "RType" field will
refer to the outer ".dict" param, causing wrong liveness analysis.

To fix this, if "f" refers to outer ".dict", the dict param will be
copied to an autotmp, and "f" will refer to this autotmp instead.

Fixes #58467

Change-Id: I238b6e75441442b5540d39bc818205398e80c94d
Reviewed-on: https://go-review.googlesource.com/c/go/+/466035
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/467935
Reviewed-by: Michael Pratt <mpratt@google.com>

The sweep assist computation is intentionally racy for performance,
since the specifics of sweep assist aren't super sensitive to error.
However, if overflow occurs when computing the live heap delta, we can
end up with a massive sweep target that causes the sweep assist to sweep
until sweep termination, causing severe latency issues. In fact, because
heapLive doesn't always increase monotonically then anything that
flushes mcaches will cause _all_ allocating goroutines to inevitably get
stuck in sweeping.

Consider the following scenario:
1. SetGCPercent is called, updating sweepHeapLiveBasis to heapLive.
2. Very shortly after, ReadMemStats is called, flushing mcaches and
   decreasing heapLive below the value sweepHeapLiveBasis was set to.
3. Every allocating goroutine goes to refill its mcache, calls into
   deductSweepCredit for sweep assist, and gets stuck sweeping until
   the sweep phase ends.

Fix this by just checking for overflow in the delta live heap calculation
and if it would overflow, pick a small delta live heap. This probably
means that no sweeping will happen at all, but that's OK. This is a
transient state and the runtime will recover as soon as heapLive
increases again.

Note that deductSweepCredit doesn't check overflow on other operations
but that's OK: those operations are signed and extremely unlikely to
overflow. The subtraction targeted by this CL is only a problem because
it's unsigned. An alternative fix would be to make the operation signed,
but being explicit about the overflow situation seems worthwhile.

For #57523.
Fixes #58536.

Change-Id: Ib18f71f53468e913548aac6e5358830c72ef0215
Reviewed-on: https://go-review.googlesource.com/c/go/+/468375
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>

…in CopyFileRange"

This reverts CL 428555.

Reason for revert: It appears that even a newer kernel can get
ENOSYS from copy_file_range.

For #58592
Fixes #58627

Change-Id: Ib8dd1be61544f54bf652a99dc0b449109f8f50ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/470316
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>

…Read in read helper

Fix a misuse of bufio.Reader.Read in the helper class
cmd/internal/cov.MReader; the MReader method in question should have
been using io.ReadFull (passing the bufio.Reader) instead of directly
calling Read.

Using the Read method instead of io.ReadFull will result in a "short"
read when processing a specific subset of counter data files, e.g.
those that are short enough to not trigger the mmap-based scheme we
use for larger files, but also with a large args section (something
large enough to exceed the default 4k buffer size used by
bufio.Reader).

Along the way, add some additional defered Close() calls for files
opened by the CovDataReader.visitPod, to enure we don't leave any open
file descriptor following a call to CovDataReader.Visit.

Fixes #58427.
Updates #58411.

Change-Id: Iea48dc25c0081be1ade29f3a633df02a681fd941
Reviewed-on: https://go-review.googlesource.com/c/go/+/466677
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit a7fe9ad)
Reviewed-on: https://go-review.googlesource.com/c/go/+/468536
Reviewed-by: Cherry Mui <cherryyz@google.com>

Unlike the rest of nistec, the P-256 assembly doesn't use complete
addition formulas, meaning that p256PointAdd[Affine]Asm won't return the
correct value if the two inputs are equal.

This was (undocumentedly) ignored in the scalar multiplication loops
because as long as the input point is not the identity and the scalar is
lower than the order of the group, the addition inputs can't be the same.

As part of the math/big rewrite, we went however from always reducing
the scalar to only checking its length, under the incorrect assumption
that the scalar multiplication loop didn't require reduction.

Added a reduction, and while at it added it in P256OrdInverse, too, to
enforce a universal reduction invariant on p256OrdElement values.

Note that if the input point is the infinity, the code currently still
relies on undefined behavior, but that's easily tested to behave
acceptably, and will be addressed in a future CL.

Updates #58647
Fixes #58720
Fixes CVE-2023-24532

(Filed with the "safe APIs like complete addition formulas are good" dept.)

Change-Id: I7b2c75238440e6852be2710fad66ff1fdc4e2b24
Reviewed-on: https://go-review.googlesource.com/c/go/+/471255
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit 203e59a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471695
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>

…em with duff routines

This patch provides a fix for a problem linking large arm32 binaries
with external linking, specifically R_CALLARM relocations against
runtime.duff* routines being flagged by the external linker as not
reaching.

What appears to be happening in the bug in question is that the Go
linker and the external linker are using slightly different recipes to
decide whether a given R_CALLARM relocation will "fit" (e.g. will not
require a trampoline). The Go linker is taking into account the addend
on the call reloc (which for calls to runtime.duffcopy or
runtime.duffzero is nonzero), whereas the external linker appears to
be ignoring the addend.

Example to illustrate:

   Addr      Size   Func
   -----     -----  -----
   ...
   XYZ       1024   runtime.duffcopy
   ...
   ABC       ...    mypackge.MyFunc
     + R0: R_CALLARM  o=8 a=848 tgt=runtime.duffcopy<0>

Let's say that the distance between ABC (start address of
runtime.duffcopy) and XYZ (start of MyFunc) is just over the
architected 24-bit maximum displacement for an R_CALLARM (let's say
that ABC-XYZ is just over the architected limit by some small value,
say 36). Because we're calling into runtime.duffcopy at offset 848,
however, the relocation does in fact fit, but if the external linker
isn't taking into account the addend (assuming that all calls target
the first instruction of the called routine), then we'll get a
"doesn't fit" error from the linker.

To work around this problem, revise the ARM trampoline generation code
in the Go linker that computes the trampoline threshold to ignore the
addend on R_CALLARM relocations, so as to harmonize the two linkers.

Fixes #58503.
Updates #58428.
Updates #58425.

Change-Id: I56e580c05b7b47bbe8edf5532a1770bbd700fbe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/469275
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
(cherry picked from commit 0b5affb)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471597

… for synthetic closures

When inlining functions that contain function literals, we need to be
careful about position information. The OCLOSURE node should use the
inline-adjusted position, but the ODCLFUNC and its body should use the
original positions.

However, the same problem can arise with certain generic constructs,
which require the compiler to synthesize function literals to insert
dictionary arguments.

go.dev/cl/425395 fixed the issue with user-written function literals
in a somewhat kludgy way; this CL extends the same solution to
synthetic function literals.

This is all quite subtle and the solutions aren't terribly robust, so
longer term it's probably desirable to revisit how we track inlining
context for positions. But for now, this seems to be the least bad
solution, esp. for backporting to 1.20.

Updates #54625.
Fixes #58531.

Change-Id: Icc43a70dbb11a0e665cbc9e6a64ef274ad8253d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/468415
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit 873c14cec730ee278848f7cc58d2b4d89ab52288)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471677
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

…ves in ECDH

Return an explicit error when PrivateKey.ECDH is called with a PublicKey
which uses a different Curve. Also document this requirement, even
though it is perhaps obvious.

Updates #58131.
Fixes #58498.

Change-Id: I739181a3f1283bed14fb5ee7eb78658b854d28d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/464335
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
(cherry picked from commit 67d8916)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471602
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>

…s noescape

I had forgotten, which caused amd64 allocations to go back up
significantly. Added an allocations test.

name                    old time/op    new time/op    delta
DecryptPKCS1v15/2048-8    1.50ms ± 0%    1.48ms ± 0%   -0.95%  (p=0.000 n=9+10)
DecryptPKCS1v15/3072-8    4.64ms ± 1%    4.60ms ± 0%   -0.82%  (p=0.000 n=8+10)
DecryptPKCS1v15/4096-8    10.7ms ± 0%    10.6ms ± 1%   -0.99%  (p=0.000 n=10+10)
EncryptPKCS1v15/2048-8     158µs ± 0%     157µs ± 0%   -0.63%  (p=0.000 n=10+10)
DecryptOAEP/2048-8        1.50ms ± 0%    1.48ms ± 0%   -1.09%  (p=0.000 n=9+10)
EncryptOAEP/2048-8         161µs ± 0%     160µs ± 0%   -0.34%  (p=0.000 n=9+10)
SignPKCS1v15/2048-8       1.55ms ± 0%    1.53ms ± 1%   -1.32%  (p=0.000 n=10+10)
VerifyPKCS1v15/2048-8      157µs ± 0%     157µs ± 0%   -0.33%  (p=0.004 n=9+10)
SignPSS/2048-8            1.55ms ± 0%    1.54ms ± 0%   -1.14%  (p=0.000 n=10+10)
VerifyPSS/2048-8           160µs ± 0%     160µs ± 0%   -0.32%  (p=0.000 n=10+10)

name                    old alloc/op   new alloc/op   delta
DecryptPKCS1v15/2048-8    15.0kB ± 0%     0.6kB ± 0%  -95.74%  (p=0.000 n=10+10)
DecryptPKCS1v15/3072-8    17.9kB ± 0%     3.5kB ± 0%  -80.65%  (p=0.000 n=10+10)
DecryptPKCS1v15/4096-8    19.1kB ± 0%     4.7kB ± 0%  -75.25%  (p=0.000 n=10+10)
EncryptPKCS1v15/2048-8    7.51kB ± 0%    1.17kB ± 0%  -84.39%  (p=0.000 n=10+10)
DecryptOAEP/2048-8        15.3kB ± 0%     0.9kB ± 0%  -94.29%  (p=0.000 n=10+10)
EncryptOAEP/2048-8        7.74kB ± 0%    1.40kB ± 0%  -81.86%  (p=0.000 n=10+10)
SignPKCS1v15/2048-8       21.6kB ± 0%     0.9kB ± 0%  -95.86%  (p=0.000 n=10+10)
VerifyPKCS1v15/2048-8     7.25kB ± 0%    0.91kB ± 0%  -87.42%  (p=0.000 n=10+10)
SignPSS/2048-8            22.0kB ± 0%     1.3kB ± 0%  -94.12%  (p=0.000 n=10+10)
VerifyPSS/2048-8          7.46kB ± 0%    1.12kB ± 0%  -84.98%  (p=0.000 n=10+10)

name                    old allocs/op  new allocs/op  delta
DecryptPKCS1v15/2048-8      54.0 ± 0%       4.0 ± 0%  -92.59%  (p=0.000 n=10+10)
DecryptPKCS1v15/3072-8      60.0 ± 0%      10.0 ± 0%  -83.33%  (p=0.000 n=10+10)
DecryptPKCS1v15/4096-8      60.0 ± 0%      10.0 ± 0%  -83.33%  (p=0.000 n=10+10)
EncryptPKCS1v15/2048-8      29.0 ± 0%       7.0 ± 0%  -75.86%  (p=0.000 n=10+10)
DecryptOAEP/2048-8          60.0 ± 0%      10.0 ± 0%  -83.33%  (p=0.000 n=10+10)
EncryptOAEP/2048-8          35.0 ± 0%      13.0 ± 0%  -62.86%  (p=0.000 n=10+10)
SignPKCS1v15/2048-8         77.0 ± 0%       5.0 ± 0%  -93.51%  (p=0.000 n=10+10)
VerifyPKCS1v15/2048-8       28.0 ± 0%       6.0 ± 0%  -78.57%  (p=0.000 n=10+10)
SignPSS/2048-8              82.0 ± 0%      10.0 ± 0%  -87.80%  (p=0.000 n=10+10)
VerifyPSS/2048-8            33.0 ± 0%      11.0 ± 0%  -66.67%  (p=0.000 n=10+10)

Updates #58501.
Fixes #58505.

Change-Id: I418c5152833787b80220b556336ec284674c2493
Reviewed-on: https://go-review.googlesource.com/c/go/+/460542
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit ed370d8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471855
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

…E on Linux

CL 416115 added using faccessat2(2) from syscall.Faccessat on Linux
(which is the only true way to implement AT_EACCESS flag handing),
if available. If not available, it uses some heuristics to mimic the
kernel behavior, mostly taken from glibc (see CL 126415).

Next, CL 414824 added using the above call (via unix.Eaccess) to
exec.LookPath in order to check if the binary can really be executed.

As a result, in a very specific scenario, described below,
syscall.Faccessat (and thus exec.LookPath) mistakenly tells that the
binary can not be executed, while in reality it can be. This makes
this bug a regression in Go 1.20.

This scenario involves all these conditions:
 - no faccessat2 support available (i.e. either Linux kernel < 5.8,
   or a seccomp set up to disable faccessat2);
 - the current user is not root (i.e. geteuid() != 0);
 - CAP_DAC_OVERRIDE capability is set for the current process;
 - the file to be executed does not have executable permission
   bit set for either the current EUID or EGID;
 - the file to be executed have at least one executable bit set.

Unfortunately, this set of conditions was observed in the wild -- a
container run as a non-root user with the binary file owned by root with
executable permission set for a user only [1]. Essentially it means it
is not as rare as it may seem.

Now, CAP_DAC_OVERRIDE essentially makes the kernel bypass most of the
checks, so execve(2) and friends work the same was as for root user,
i.e. if at least one executable bit it set, the permission to execute
is granted (see generic_permission() function in the Linux kernel).

Modify the code to check for CAP_DAC_OVERRIDE and mimic the kernel
behavior for permission checks.

[1] opencontainers/runc#3715

For #58552.
Fixes #58624.

Change-Id: I82a7e757ab3fd3d0193690a65c3b48fee46ff067
Reviewed-on: https://go-review.googlesource.com/c/go/+/468735
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
(cherry picked from commit 031401a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/469956
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

Updates #58789.
Fixes #58793.

Change-Id: I91cdd20c6d4f05baaacd6a38717aa7bed6682573
Reviewed-on: https://go-review.googlesource.com/c/go/+/472155
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
(cherry picked from commit ec26277)
Reviewed-on: https://go-review.googlesource.com/c/go/+/472415
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

This test is flaky, apparently due to a typo'd operator in CL 21447
that causes it to compare “same port OR IP” instead of
“same port AND IP”.

If we merely fixed the comparison, the test would hopefully stop being
flaky itself, but we would still be left with another problem:
repeatedly dialing a port that we believe to be unused can interfere
with other tests, which may open the previously-unused port and then
attempt a single Dial and expect it to succeed. Arbitrary other Dial
calls for that port may cause the wrong connection to be accepted,
leading to spurious test failures.

Moreover, the test can be extremely expensive for the amount of data
we hope to get from it, depending on the system's port-reuse
algorithms and dial implementations. It is already scaled back by up
to 1000x on a huge number of platforms due to latency, and may even be
ineffective on those platforms because of the arbitrary 1ms Dial
timeout. And the incremental value from it is quite low, too: it tests
the workaround for what is arguably a bug in the Linux kernel, which
ought to be fixed (and tested) upstream instead of worked around in
every open-source project that dials local ports.

Instead of trying to deflake this test, let's just get rid of it.

Updates #18290.
Fixes #58717.

Change-Id: I8a58b93d67916a33741c9ab29ef99c49c46b32c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/460657
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
(cherry picked from commit e08642c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471155
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>

…n on Windows

Updates #58714
Fixes #58774

Change-Id: Ifa5c059ed5e358ed98aee7e83b95dd1806b535f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/471335
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
(cherry picked from commit de8c999)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471599
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>

…ntermediate handling

On Windows, replace tests which rely on a root that expired last year.
On Darwin fix an test which wasn't testing the expected behavior, and
fix the behavior which was broken.

Updates #58791
Fixes #58811

Change-Id: I771175b9e123b8bb0e4efdf58cc2bb93aa94fbae
Reviewed-on: https://go-review.googlesource.com/c/go/+/472295
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
(cherry picked from commit bb8f9a6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/472616
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

Convert TestUnknownAuthorityError to use subtests, avoiding continuing
the test after an unrecoverable failure.

Skip TestIssue51759 on pre-macOS 11 builders, which don't enforce the
behavior we were testing for. Also only enable the test on builders.

Updates #58791
Updates #58812
Fixes #58811

Change-Id: I4e3e5bc371aa139d38052184c8232f8cb564138f
Reviewed-on: https://go-review.googlesource.com/c/go/+/472496
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
(cherry picked from commit cf3d065)
Reviewed-on: https://go-review.googlesource.com/c/go/+/472618
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>

The assertion here was to make sure the newly constructed and
typechecked expression selected the same receiver-qualified method,
but in the case of anonymous receiver types we can actually end up
with separate types.Field instances corresponding to each types.Type
instance. In that case, the assertion spuriously failed.

The fix here is to relax and assertion and just compare the method's
name and type (including receiver type).

Fixes #58776.

Change-Id: I67d51ddb020e6ed52671473c93fc08f283a40886
Reviewed-on: https://go-review.googlesource.com/c/go/+/471676
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 37a2004)
Reviewed-on: https://go-review.googlesource.com/c/go/+/472620
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>

Change-Id: Ib993bfea994a3e885a6068860d2e1f6705f8cf40
Reviewed-on: https://go-review.googlesource.com/c/go/+/474037
Auto-Submit: Gopher Robot <gobot@golang.org>
Run-TryBot: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>