With the introduction of stack objects, VARKILL information is
no longer needed.
With stack objects, an object is dead when there are no more static
references to it, and the stack scanner can't find any live pointers
to it. VARKILL information isn't used to establish live ranges for
address-taken variables any more. In effect, the last static reference
*is* the VARKILL, and there's an additional dynamic liveness check
during stack scanning.
Next CL will actually rip out the VARKILL opcodes.
Change-Id: I030a2ab867445cf4e0e69397911f8a2e2f0ed07b
Reviewed-on: https://go-review.googlesource.com/c/go/+/419234
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
We don't need this special loop construct anymore now that we do
conservative GC scanning of the top of stack. Rewrite instead to a simple
pointer increment on every iteration. This leads to having a potential
past-the-end pointer at the end of the last iteration, but that value
immediately goes dead after the loop condition fails, and the past-the-end
pointer is never live across any call.
This simplifies and speeds up loops.
R=go1.20
TODO: actually delete all support for OFORUNTIL. It is now never generated,
but code to handle it (e.g. in ssagen) is still around.
TODO: in "for _, x := range" loops, we could get rid of the index
altogether and use a "pointer to the last element" reference to determine
when the loop is complete.
Fixes#53409
Change-Id: Ifc141600ff898a8bc6a75f793e575f8862679ba1
Reviewed-on: https://go-review.googlesource.com/c/go/+/414876
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The non-unified frontend had repeated issues with inlining and
generics (#49309, #51909, #52907), which led us to substantially
restrict inlining when shape types were present.
However, these issues are evidently not present in unified IR's
inliner, and the safety restrictions added for the non-unified
frontend can simply be disabled in unified mode.
Fixes#54497.
Change-Id: I8e6ac9f3393c588bfaf14c6452891b9640a9d1bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/424775
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
As a consistency check in devirtualization, when we determine `i` (of
interface type `I`) always has dynamic type `T`, we insert a type
assertion `i.(T)`. This emits an itab check for `go:itab.T,I`, but
it's always true (and so SSA optimizes it away).
However, if `I` is instead the generic interface type `I[T]`, then
`go:itab.T,I[int]` and `go:itab.T,I[go.shape.int]` are equivalent but
distinct itabs. And notably, we'll have originally created the
interface value using the former; but the (non-dynamic) TypeAssertExpr
created by devirtualization would ultimately emit a comparison against
the latter. This comparison would then evaluate false, leading to a
spurious type assertion panic at runtime.
The comparison is just meant as an extra safety check, so it should be
safe to just disable. But for now, it's simpler/safer to just punt on
devirtualization in this case. (The non-unified frontend doesn't
devirtualize this either.)
Change-Id: I6a8809bcfebc9571f32e289fa4bc6a8b0d21ca46
Reviewed-on: https://go-review.googlesource.com/c/go/+/424774
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For local variables of derived type, Delve relies on ir.Name.DictIndex
being set to the type's rtype index within the function's dictionary.
This CL implements that functionality within unified IR.
Manually double checked that Delve behaves correctly, at least as far
as I can tell from casual use. Specifically, I confirmed that running
the test program from TestDictIndex, stepping into testfn, and then
running `print mapvar` prints `map[int]main.CustomInt []`, which
matches the behavior under GOEXPERIMENT=nounified. (Also compare that
when ir.Name.DictIndex is *not* set by unified IR, `print mapvar`
instead prints `map[int]go.shape.int []`.)
Fixes#54514.
Change-Id: I90d443945895abfba04dc018f15e00217930091c
Reviewed-on: https://go-review.googlesource.com/c/go/+/424735
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL implements pointer shaping in unified IR, corresponding to the
existing pointer shaping implemented in the non-unified frontend.
For example, if `func F[T any]` is instantiated as both `F[*int]` and
`F[*string]`, we'll now generate a single `F[go.shape.*uint8]` shaped
function that can be used by both.
Fixes#54513.
Change-Id: I2cef5ae411919e6dc5bcb3cac912abecb4cd5218
Reviewed-on: https://go-review.googlesource.com/c/go/+/424734
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
So they match with when/nextwhen fields of timer struct.
Updates #53821
Change-Id: Iad0cceb129796745774facfbbfe5756df3a320b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/423117
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Even though the -race option works for ppc64le, some of the
testsanitizer test have failed in the past on our builders. These
same failures can't be reproduced on other systems.
This is an experiment to re-enable this test on ppc64le to see if
it still fails on the builders.
Updates #45040
Change-Id: I0729bec5864e6c4cc752968485e89179df027063
Reviewed-on: https://go-review.googlesource.com/c/go/+/424534
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
printer.print is an overloaded method for multiple purposes.
When fed a position, it updates the current position.
When fed a string, it prints the string.
When fed a token, it prints the token. And so on.
However, this overloading comes at a significant cost.
Because the parameters are a list of the `any` interface type,
any type which is not of pointer or interface kind will allocate when
passed as an argument, as interfaces can only contain pointers.
A large portion of the arguments passed to the print method are of type
token.Pos, whose underlying type is int - so it allocates.
Removing those allocations has a significant benefit,
at the cost of some verbosity in the code:
name old time/op new time/op delta
Print-16 6.10ms ± 2% 5.39ms ± 2% -11.72% (p=0.000 n=10+10)
name old speed new speed delta
Print-16 8.50MB/s ± 2% 9.63MB/s ± 2% +13.28% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
Print-16 443kB ± 0% 332kB ± 0% -25.10% (p=0.000 n=10+9)
name old allocs/op new allocs/op delta
Print-16 17.3k ± 0% 3.5k ± 0% -80.10% (p=0.000 n=10+10)
There should be more significant speed-ups left, particularly for the
token.Token, string, and whiteSpace types fed to the same method.
They are left for a future CL, in case this kind of optimization is not
a path we want to take.
Change-Id: I3ff8387242c5a935bb003e60e0813b7b9c65402e
Reviewed-on: https://go-review.googlesource.com/c/go/+/412557
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: hopehook <hopehook@qq.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
These are only used once right after being set in castagnoliInit and
ieeeInit, respectively.
Change-Id: Ifc5df1fe3040b97b1d252cc6d6d28d8fbc132fa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/423854
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
The golang.org/x/sys/unix package is already imported for Utsname and
Uname. Use ByteSliceToString from that package as well to replace the
locally defined utsString helper which serves the same purpose and
matches ByteSliceToString's implementation.
Change-Id: I5d9de186a5aeb1feed1387beedefbcd260fe22ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/415654
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
No test case because the problem can only happen for invalid data.
Let the fuzzer find cases like this.
For #47653Fixes#53530
Change-Id: If1cebbbcabb188fec8be30ef043c8c4c935a9564
Reviewed-on: https://go-review.googlesource.com/c/go/+/413995
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
The documentation for LoadLocation contains an enumerated list,
but does not render as such because it's missing leading spaces.
Output verified with the go doc command and godoc server.
Change-Id: I88b61d34048b7d01ee5cd77c32849af266e2f4c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/423297
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Support for operating system versions requiring the fallback to
CloseOnExec/SetNonblock was dropped from recent Go versions. The minimum
Linux kernel version is 2.6.32 as of Go 1.18. FreeBSD 10 is no longer
supported as of Go 1.13.
Follows a similar change for net.sysSocket in CL 403634 and
syscall.Socket in CL 422374.
For #45964
Change-Id: I60848415742a1d8204e1fda585462ff35ad6722f
Reviewed-on: https://go-review.googlesource.com/c/go/+/422375
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Most newer architectures (e.g. arm64, riscv64, loong64) don't provide the
epoll_create syscall. Some systems (e.g. Android) block it even if it
were available. In the kernel, the epoll_create syscall is implemented
[1] the same way EpollCreate is implemented in this package for
platforms without the epoll_create syscall. The epoll_create1 syscall is
available since Linux kernel 2.6.27 and the minimum required kernel
version is 2.6.32 since Go 1.18 (see #45964). Thus, avoid the separate
wrapper and consistently implement EpollCreate using EpollCreate1.
[1] https://elixir.bootlin.com/linux/v5.15-rc1/source/fs/eventpoll.c#L2006
The same change was already done in CL 349809 for golang.org/x/sys/unix.
For #45964
Change-Id: I5463b208aa7ae236fa2c175d6d3ec6568f1840b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/411594
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
The previous implementation of isCaseSensitive called t.Fatalf in the
wrong place, causing tests after the first to proceed past an error
determining case-sensitivity. That could lead to confusing errors.
(Moreover, I would like to try to disentangle the script engine from
testing.T so that I can also use it to generate serving contents in
the replacement for vcs-test.golang.org.)
The implementation of goVersion called ts.fatalf, which is probably
fine but prevents the script environment from being computed outside
of a test, as we might want to do for debugging and other scripting.
For #27494.
Change-Id: Ibfee0704523fdcd6174b544ff84267216435025b
Reviewed-on: https://go-review.googlesource.com/c/go/+/419874
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
When the GOOS or GOARCH of the cmd/go test binary does not match the
GOOS or GOARCH of the installed 'go' binary itself, the test currently
attempts to trick 'go test' into thinking that there were no test
functions to run.
That makes it very difficult to discover how to actually run the
tests, which in turn makes it difficult to diagnose and fix
regressions in, say, the linux-386-longtest builders. (We have had a
few of those lately, and they shouldn't be as much of an ordeal to fix
as they currently are.)
There are three underlying problems:
1. cmd/go uses its own GOOS and GOARCH to figure out which variant of
other tools to use, and the cache keys for all installed tools and
libraries include the IDs of the tools used to build them. So when
cmd/go's GOARCH changes, all installed tools and binaries appear
stale *even if* they were just installed by invoking the native
cmd/go with the appropriate GOARCH value set.
2. The "go/build" library used by cmd/go toggles its default
CGO_ENABLED behavior depending on whether the GOOS and GOARCH being
imported match runtime.GOOS and runtime.GOARCH.
3. A handful of cmd/go tests explicitly use gccgo, but the user's
installed gccgo binary cannot necessarily cross-compile to the same
platforms as cmd/go.
To address the cache-invalidation problem, we modify the test variant
of cmd/go to use the host's native toolchain (as indicated by the new
TESTGO_GOHOSTOS and TESTGO_GOHOSTARCH environment variables) instead
of the toolchain matching the test binary itself. That allows a test
cmd/go binary compiled with GOARCH=386 to use libraries and tools
cross-compiled by the native toolchain, so that
$ GOARCH=386 go install std cmd
suffices to make the packages in std and cmd non-stale in the
tests.
To address the CGO_ENABLED mismatch, we set CGO_ENABLED explicitly in
the test's environment whenever it may differ from the default. Since
script tests that use cgo are already expected to use a [cgo]
condition, setting the environment to match that condition fixes the
cgo-specific tests.
To address the gccgo-specific cross-compilation failures, we add a new
script condition, [cross], which evaluates to true whenever the
platform of the test binary differs from that of the native toolchain.
We can then use that condition to explicitly skip the handful of gccgo
tests that fail under cross-compilation.
Fixes#53936.
Change-Id: I8633944f674eb5941ccc95df928991660e7e8137
Reviewed-on: https://go-review.googlesource.com/c/go/+/356611
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
This CL switches unified IR to use shape-based stenciling with runtime
dictionaries, like the existing non-unified frontend. Specifically,
when instantiating generic functions and types `X[T]`, we now also
instantiated shaped variants `X[shapify(T)]` that can be shared by
`T`'s with common underlying types.
For example, for generic function `F`, `F[int](args...)` will be
rewritten to `F[go.shape.int](&.dict.F[int], args...)`.
For generic type `T` with method `M` and value `t` of type `T[int]`,
`t.M(args...)` will be rewritten to `T[go.shape.int].M(t,
&.dict.T[int], args...)`.
Two notable distinctions from the non-unified frontend:
1. For simplicity, currently shaping is limited to simply converting
type arguments to their underlying type. Subsequent CLs will implement
more aggressive shaping.
2. For generic types, a single dictionary is generated to be shared by
all methods, rather than separate dictionaries for each method. I
originally went with this design because I have an idea of changing
interface calls to pass the itab pointer via the closure
register (which should have zero overhead), and then the interface
wrappers for generic methods could use the *runtime.itab to find the
runtime dictionary that corresponds to the dynamic type. This would
allow emitting fewer method wrappers.
However, this choice does have the consequence that currently even if
a method is unused and its code is pruned by the linker, it may have
produced runtime dictionary entries that need to be kept alive anyway.
I'm open to changing this to generate per-method dictionaries, though
this would require changing the unified IR export data format; so it
would be best to make this decision before Go 1.20.
The other option is making the linker smarter about pruning unneeded
dictionary entries, like how it already prunes itab entries. For
example, the runtime dictionary for `T[int]` could have a `R_DICTTYPE`
meta-relocation against symbol `.dicttype.T[go.shape.int]` that
declares it's a dictionary associated with that type; and then each
method on `T[go.shape.T]` could have `R_DICTUSE` meta-relocations
against `.dicttype.T[go.shape.T]+offset` indicating which fields
within dictionaries of that type need to be preserved.
Change-Id: I369580b1d93d19640a4b5ecada4f6231adcce3fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/421821
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The splice syscall is buggy prior to Linux 2.6.29. CL 113999 added a
workaround to detect buggy versions and disable use of splice for these.
As of Go 1.18 the minumum Linux version is 2.6.32. Thus, a non-buggy
implementation of the splice syscall can be assumed.
For #45964Fixes#54505
Change-Id: Ied3a3334da7a3f7fa1280b7c5b1dfb9030219336
Reviewed-on: https://go-review.googlesource.com/c/go/+/422979
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Either ones where kind == kindNonBlock or those we've successfully called syscall.SetNonblock() on.
Restore blocking behavior if we detect an error registering with the netpoller and our flow was
successful in setting the inital syscall.SetNonblock().
Update #54100
Change-Id: I08934e4107c7fb36c15a7ca23ac880490b4df235
Reviewed-on: https://go-review.googlesource.com/c/go/+/420334
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Goutnik <dgoutnik@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Yuval Pavel Zholkover <paulzhol@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Plan 9 a.out was not implemented for debug/buildinfo, which
was causing test failures on Plan 9. This adds an implementation,
and causes the tests to pass.
Fixes#53949
Change-Id: I90a307ef9babf8cf381f8746d731cac2206b234a
Reviewed-on: https://go-review.googlesource.com/c/go/+/418014
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Generics lets us write Cache[K, V] instead of using unsafe.Pointer,
which lets us remove all the uses of package unsafe around the
uses of the cache.
I tried to do Cache[*K, *V] instead of Cache[K, V] but that was not possible.
Change-Id: If3b54cf4c8d2a44879a5f343fd91ecff096537e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/423357
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Change-Id: I4dad103d23121a21b04800ec157487fdf79f89a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/424398
Run-TryBot: hopehook <hopehook@qq.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
'go tool' sets environment variables, including the GOAMD64 value
from the user's go.env file.
'go tool dist test' then rebuilds and reinstalls the toolchain and
standard library based on those variables. It should not; instead, it
should test exactly the configuration installed by the make scripts.
Fixes#54084.
Change-Id: I7cc8a21cc1d8331e06d7b7c55b14d170f8e2faab
Reviewed-on: https://go-review.googlesource.com/c/go/+/420055
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
We have a very complex process to make VDSO calls on ARM. Create a
wrapper helper function which reduces duplication and allows for
additional calls from other packages.
vdsoCall has a few differences from the original code in
walltime/nanotime:
* It does not use R0-R3, as they are passed through as arguments to fn.
* It does not save g if g.m.gsignal.stack.lo is zero. This may occur if
it called at startup on g0 between assigning g0.m.gsignal and setting
its stack.
For #49182
Change-Id: I51aca514b4835b71142011341d2f09125334d30f
Reviewed-on: https://go-review.googlesource.com/c/go/+/362795
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Export cipher.xorBytes as subtle.XORBytes, for proposal #53021,
to provide fast XOR to cryptography libraries outside crypto/cipher.
Along with the move, implement the alignment check TODO
in xor_generic.go, so that systems with neither unaligned
accesses nor custom assembly can still XOR a word at a time
in word-based algorithms like GCM. This removes the need
for the separate cipher.xorWords.
Fixes#53021.
Change-Id: I58f80a922f1cff671b5ebc6168eb046e702b5a4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/421435
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This avoids an import conflict with crypto/subtle.
CL 424175 does the same for x/crypto.
Change-Id: Id4a319b3283b8affaaf769062388325b31fe1715
Reviewed-on: https://go-review.googlesource.com/c/go/+/424194
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Test is still flaky.
For #22857
Change-Id: Ic0d979778eb4c2d3779b18a983e7077789ae08a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/424535
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Request.Cookie(name string) will return the first cookie
when cookie name is "". Since readCookies in
file net/http/cookie.go at line 247 return all cookies
when second parameter is a empty string.
To fix it, Return ErrNoCookie from Request.Cookie(""),
instead of the first cookie in the request.
Fixes#53181
Change-Id: Ie623ca4c53da64ef7623a7863292a2d771f76832
GitHub-Last-Rev: 01098cd5db
GitHub-Pull-Request: golang/go#53183
Reviewed-on: https://go-review.googlesource.com/c/go/+/409754
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
