Unified IR is now at feature parity with the non-unified frontend.
Change-Id: I2a8cd41267a66f5eb1f425b89d18c6d501676e07
Reviewed-on: https://go-review.googlesource.com/c/go/+/422235
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Since the spec tests are now identical between the two type checkers,
remove the local copy of the spec tests and (for now) use the tests
in go/types/testdata/spec instead. Eventually we may decide to move
all tests out of the type checker directories and place them in a
shared space (e.g. internal/types/testdata).
For #54511.
Change-Id: Ibc62230553a5ff215160dcc97696b333ae9cf685
Reviewed-on: https://go-review.googlesource.com/c/go/+/424676
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Besides applying gofmt (which doesn't damage the tests in this case),
this removes a TODO for a set of nil-related tests.
The test files are now identical.
For #54511.
Change-Id: I0a286ad607f317f43972c1f5ee741b4f5bc9576d
Reviewed-on: https://go-review.googlesource.com/c/go/+/424675
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Besides applying gofmt (which doesn't damage the tests in this case),
the ERROR comments in the types2 files now match the go/types files.
But because types2 still reports some errors are different positions,
the checking code now allows for some position discrepancy (similar
to what we do for other tests).
Except for an outstanding TODO in go/types/testdata/examples/types.go
the test files are now identical.
For #54511.
Change-Id: I5748e0f678d11c5c0bdf4fdf28bd04f0b11b5b23
Reviewed-on: https://go-review.googlesource.com/c/go/+/424674
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Instead of simply reporting an error but otherwise dropping the
index expression from the parse tree when an index is missing
(as in: x[]), create an index expression with a "bad expression"
as index. This matches the behavior of go/parser and permits the
use of the same test case for both parsers.
(It would be simpler to adjust the go/parser to match the syntax
parser's behavior, but that would break backward-compatibility
of the go/parser.)
Adjust the affected test files.
For #54511.
Change-Id: If7668973794604593e869a24b560da92e100b812
Reviewed-on: https://go-review.googlesource.com/c/go/+/424654
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Update the version of BoringCrypto to boringssl tag
fips-20210429, for which FIPS approval is "in process".
Add GOARCH=arm64 BoringCrypto support.
Shuffle build to run as distinct steps in Docker so that
we can rerun later parts like build-goboring.sh without
rerunning all the setup.
Strip unnecessary parts of the syso using --strip-unneeded,
which cuts the amd64 syso from 10MB to 2.5MB.
The new arm64 syso is 2MB, so even though we added a new
architecture, we have half as much syso to distribute.
Change-Id: I0f7327389a3a485b82577abea9153d006418298f
Reviewed-on: https://go-review.googlesource.com/c/go/+/423362
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This resolves a TODO. Also, it allows go/types and types2 to use
identical test files in testdata/spec, a prerequisition for sharing
them eventually.
For #54511.
Change-Id: Ia9d11b15ada237c18b6ce8f72732f70134a1a06f
Reviewed-on: https://go-review.googlesource.com/c/go/+/424537
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This does not enable any new functionality. It should
behave identically to GOPPC64=power9.
Updates #44549
Change-Id: I9a860544527fcfe97cbaf89686459d40dcf9593e
Reviewed-on: https://go-review.googlesource.com/c/go/+/352791
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
CL 424396 and CL 424397 changed timer0When/timerModifiedEarliest to
atomic.Uint64, just they're guaranted to have 64-bit alignment.
Change-Id: Idaff1059da2aac84520b9b0e34f9721a74dbba5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/424794
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Not used any more.
Fixes#53860
Change-Id: Id0b1c3ed30b576d6c5f08f064d1262de337262b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/418374
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
This test was disabled for flakiness.
The underlying code has been rewritten.
Reenabling the test to see if it has been fixed.
Fixes#22857.
Change-Id: If488ee5f4692cdf4ed534b8f08b4a54b80a60943
Reviewed-on: https://go-review.googlesource.com/c/go/+/423454
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
GoTool was added in CL 20967, and revised in CL 21292, for #14901.
I don't fully understand what problem the GoTool function was added to
solve: the discussion on that issue was pretty sparse, but it seems
like when we run tests of GOROOT packages they always know their own
location relative to GOROOT (and thus always know where to find the
'go' tool).
Lacking that understanding, I don't want to change its behavior, but I
do at least want to verify that it resolves to the real 'go' tool in
the common case (running 'go test' on a package in GOROOT/src).
For #50892
For #50893
Updates #14901
Change-Id: I06d831e6765be631dfc4854d7fddc3d27fc1de34
Reviewed-on: https://go-review.googlesource.com/c/go/+/381834
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Optimize Time.GoString by avoiding multiple calls to absDate.
name old time/op new time/op delta
GoString-8 313ns ± 2% 197ns ± 1% -37.08% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
GoString-8 80.0B ± 0% 80.0B ± 0% ~ (all equal)
name old allocs/op new allocs/op delta
GoString-8 1.00 ± 0% 1.00 ± 0% ~ (all equal)
Fixes#54436
Change-Id: I8e6f8e7bbb9857b4bc0cdf6ed29a6b2415775db7
Reviewed-on: https://go-review.googlesource.com/c/go/+/423634
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Brings freebsd/amd64 on par with other OSes/archs.
Updates #53479
Change-Id: I05164c887d776dd4a0ae51eafd4014042b782999
Reviewed-on: https://go-review.googlesource.com/c/go/+/413366
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Following proposal discussion in #38687, add go generate -skip
to allow easier skipping of specific //go:generate directives.
Fixes#38687.
Change-Id: Ied5b4042965dd6a2b93c1c517045fccae2d95c3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/421440
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Brings freebsd/386 on par with other OSes/archs.
Updates #53479
Change-Id: I16a7d051233e06e589b19919e68f07b6bf92f73c
Reviewed-on: https://go-review.googlesource.com/c/go/+/413365
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
The existing implementation has an execution time higher in the benchmark than this one.
This is an optimized implementation using the copy() function and a constant 256 bytes string with the values to be copied.
```
name old time/op new time/op delta
NewEncoding-4 329ns ± 1% 231ns ± 1% -29.72% (p=0.008 n=5+5)
name old speed new speed delta
NewEncoding-4 778MB/s ± 1% 1108MB/s ± 1% +42.29% (p=0.008 n=5+5)
```
Fixes#53211
Change-Id: I80fe62aa40623125ef81ae9164a8405eed30b71b
GitHub-Last-Rev: 55dce6f636
GitHub-Pull-Request: golang/go#53212
Reviewed-on: https://go-review.googlesource.com/c/go/+/410194
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
No test case because the problem can only happen for invalid data.
Let the fuzzer find cases like this.
For #47653Fixes#52526
Change-Id: Id90a5e391a4f684f45f8d7e32608eb03b8081076
Reviewed-on: https://go-review.googlesource.com/c/go/+/413875
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Don't allocate slices that are too large; choose a smaller capacity
and build the slice using append. Use this in debug/macho to avoid
over-allocating if a fat header is incorrect.
No debug/macho test case because the problem can only happen for
invalid data. Let the fuzzer find cases like this.
For #47653Fixes#52523
Change-Id: I372c9cdbdda8626a3225e79d713650beb350ebc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/413874
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Change-Id: Id492ee4e614a38880a6a5830371dcd9a8b37129a
Reviewed-on: https://go-review.googlesource.com/c/go/+/422214
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: hopehook <hopehook@qq.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: hopehook <hopehook@qq.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
For #47653Fixes#53189
Change-Id: If35b968fc53e4c96b18964cfb020cdc003b881bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/412014
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
As CL 422214 did, this CL intends to clean up the rest
unreachable "Continue" after Fatal.
Change-Id: I3b7e1b59bdfccb185e20525ce113e241d277dad3
Reviewed-on: https://go-review.googlesource.com/c/go/+/422514
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: hopehook <hopehook@qq.com>
[This is a retry of CL 407036 + its revert CL 422394. The only
content change is the 1-line change in cmd/internal/obj/objfile.go.]
Read the bitmaps one uintptr at a time instead of one byte at a time.
Performance so far:
Allocation heavy, no retention: ~30% faster in heapBitsSetType
Scan heavy, ~no allocation: ~even in scanobject
Change-Id: I04d899e1dbd23e989e9f552cdc1880318779c14c
Reviewed-on: https://go-review.googlesource.com/c/go/+/422635
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
[this is a retry of CL 407035 + its revert CL 422395. The content is unchanged]
Use just 1 bit per word to record the ptr/nonptr bitmap.
Use word-sized operations to manipulate the bitmap, so we can operate
on up to 64 ptr/nonptr bits at a time.
Use a separate bitmap, one bit per word of the ptr/nonptr bitmap,
to encode a no-more-pointers signal. Since we can check 64 ptr/nonptr
bits at once, knowing the exact last pointer location is not necessary.
As a followon CL, we should make the gcdata bitmap an array of
uintptr instead of an array of byte, so we can load 64 bits of it at once.
Similarly for the processing of gc programs.
Change-Id: Ica5eb622f5b87e647be64f471d67b02732ef8be6
Reviewed-on: https://go-review.googlesource.com/c/go/+/422634
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Add a new Rewrite hook to ReverseProxy, superseding the Director hook.
Director does not distinguish between the inbound and outbound request,
which makes it possible for headers added by Director to be inadvertently
removed before forwarding if they are listed in the inbound request's
Connection header. Rewrite accepts a value containing the inbound
and outbound requests, with hop-by-hop headers already removed from
the outbound request, avoiding this problem.
ReverseProxy's appends the client IP to the inbound X-Forwarded-For
header by default. Users must manually delete untrusted X-Forwarded-For
values. When used with a Rewrite hook, ReverseProxy now strips
X-Forwarded-* headers by default.
NewSingleHostReverseProxy creates a proxy that does not rewrite the
Host header of inbound requests. Changing this behavior is
cumbersome, as it requires wrapping the Director function created
by NewSingleHostReverseProxy. The Rewrite hook's ProxyRequest
parameter provides a SetURL method that provides equivalent
functionality to NewSingleHostReverseProxy, rewrites the Host
header by default, and can be more easily extended with additional
customizations.
Fixes#28168.
Fixes#50580.
Fixes#53002.
Change-Id: Ib84e2fdd1d52c610e3887af66f517d4a74e594d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/407214
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
(But still not when -buildvcs=auto, the default.)
Fixes#52648.
Change-Id: I87a87d4ea84e8bf9635a4f7c8674c9311c3e21be
Reviewed-on: https://go-review.googlesource.com/c/go/+/409177
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
The design of FileSet encourages it to be used as a global variable.
Each call to AddFile consumes about 3KB, that is never returned,
even after an application no longer cares about the File.
This change adds a RemoveFile method that a long-running application
can use to release a File that is no longer needed, saving memory.
Fixesgolang/go#53200
Change-Id: Ifd34d650fe0d18b1395f922a4cd02a535afbe560
Reviewed-on: https://go-review.googlesource.com/c/go/+/410114
Auto-Submit: Alan Donovan <adonovan@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This test was apparently mistakenly removed without a replacement in
CL 213223, but its testdata was left in the tree. This change removes
the orphaned testdata subdirectory, and restores the test that
previously used that data as a self-contained script.
For #27494.
Change-Id: Ice81895a44c558aaab198b8ef7ec046d92f5d58f
Reviewed-on: https://go-review.googlesource.com/c/go/+/417658
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
As far as I can determine, this is the only existing non-script test
that relies on vcs-test.golang.org. I am attempting to eliminate the
vcs-test server, and to keep configuration straightforward I would
like to only set up its replacement for script tests.
For #27494.
Change-Id: Ib978228b9c3f403af5f1c445e08942cbe7915b62
Reviewed-on: https://go-review.googlesource.com/c/go/+/418103
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
$ cd $GOROOT/src/testing
$ go test
root
root
root
root
PASS
$
The root prints have been happening since Go 1.14.
There is a test in sub_test.go that calls b.Run directly
with a benchmark named "root", which triggers the print.
Silence them.
Change-Id: I2f0c186f04c6139bc24fab0e91975fcf0a8e80fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/421437
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that syscall.Mmap is defined on solaris (see CL 413374), use it in
mmapFile like on other Unix ports.
For #52875
Change-Id: Ic5c5a84da8613f0c6dc947a52b7fcca50af43d79
Reviewed-on: https://go-review.googlesource.com/c/go/+/413375
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
WithContext makes a shallow copy of a Request, and Clone makes a
deep copy. Both set the context of the new request. The distinction
between the two is clear, and it doesn't seem useful or necessary
to say that "it's rare to need WithContext".
Also update a couple locations that mention WithContext to mention
Clone as well.
Fixes#53413.
Change-Id: I89e6ddebd7d5ca6573e522fe48cd7f50cc645cdd
Reviewed-on: https://go-review.googlesource.com/c/go/+/412778
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
When accessing (*Checker).implements from types.AssignableTo or
types.ComparableTo, we don't need to build error strings -- they won't
be used.
This string manipulation showed up as a hot spot in gopls completion,
which checks a lot of type predicates when searching for candidate
completions.
This CL yields the following results for gopls' completion benchmarks:
StructCompletion-8 24.7ms ±34% 26.0ms ±17% ~ (p=0.447 n=10+9)
ImportCompletion-8 1.41ms ± 2% 1.45ms ± 4% +2.42% (p=0.027 n=8+9)
SliceCompletion-8 27.0ms ±18% 25.2ms ± 3% -6.67% (p=0.008 n=9+8)
FuncDeepCompletion-8 57.6ms ± 4% 22.4ms ± 4% -61.18% (p=0.000 n=8+9)
CompletionFollowingEdit-8 157ms ±13% 103ms ±15% -34.70% (p=0.000 n=10+10)
Notably, deep completion (which searches many candidates) is almost 3x
faster after this change.
Fixes#54172
Change-Id: If8303a411aed3a20bd91f7b61e346d703084166c
Reviewed-on: https://go-review.googlesource.com/c/go/+/423360
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
The new Clone function returns a copy of b[:len(b)]
for the input byte slice b.
The result may have additional unused capacity.
Clone(nil) returns nil.
Fixes#45038
Change-Id: I0469a202d77a7b491f1341c08915d07ddd1f0300
Reviewed-on: https://go-review.googlesource.com/c/go/+/359675
Run-TryBot: Martin Möhrmann <martin@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
So far was only documented in doc/diagnostics.
Fixes: #54183
Change-Id: Iab67a1500547f30325453c614a2f2f6621dfadb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/423275
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
The value of Expires is only checked when a value is set.
This fixes the bug that a cookie with a zero-valued Expire
was considered invalid, even though Expires is an optional
field.
Fixes#52989
Change-Id: I206c50e9b6ea2744a92c74673d589ce2aaa62670
Reviewed-on: https://go-review.googlesource.com/c/go/+/407654
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The length of slice hashedsyms is always 0, because it's not used after defined
Change-Id: Iba8e263aedfa403d5688678a1b37c2be3119eb7f
GitHub-Last-Rev: c236c4a482
GitHub-Pull-Request: golang/go#53450
Reviewed-on: https://go-review.googlesource.com/c/go/+/413234
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: guangyuan zhou <zhouguangyuan@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Use the helper added by CL 422038 instead of manually detecting the
noopt builder.
Change-Id: I353f1a9d5f0184d73869520eb1ae8d0bdbbe2006
Reviewed-on: https://go-review.googlesource.com/c/go/+/423855
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
A few lingering references to Go 1.4 remain.
Fix them, and document the ones that should stay.
For #44505.
Fixes#54301.
Change-Id: Ieb9c0f08e4d1890ea3fdfd9c8df5493934ae7493
Reviewed-on: https://go-review.googlesource.com/c/go/+/423354
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: Ie169c226e8973c8b504412cc0ac1f14abcdfdb1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/423755
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
CL 414836 limited the check for implicit dot for method call enabled by
a type bound. However, the checking condition for ODOTMETH only is not
right. For example, for promoted method, we have a OXDOT node instead,
and we still have to check for implicit dot in this case.
However, if the base type and embedded types have the same method name,
e.g in issue #53419, typecheck.AddImplicitDots will be confused and
result in an ambigus selector.
To fix this, we ensure methods for the base type are computed, then only
do the implicit dot check if we can find a matched method.
Fixes#54348
Change-Id: Iefe84ff330830afe35c5daffd499824db108da23
Reviewed-on: https://go-review.googlesource.com/c/go/+/422274
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This saves 11,000 allocations when loading the standard library
in golang.org/x/tools/go/ssa form.
Change-Id: I8aa32b0641c1a3dde29e6ee76c760006035dd56d
Reviewed-on: https://go-review.googlesource.com/c/go/+/423934
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
This CL make math.sqrt an intrinsic function, math.Sqrt is not affected
since compiler can inline it. With this change, we can remove all assembly
code for math.Sqrt that aims to speed up indirect call. The go compiler can
generate same or faster code (with regabi) for indirect call.
Benchmark on amd64:
name old time/op new time/op delta
SqrtIndirect 2.60ns ± 3% 1.03ns ± 4% -60.24% (p=0.000 n=10+10)
SqrtLatency 3.40ns ± 1% 3.32ns ± 1% -2.26% (p=0.000 n=10+8)
SqrtIndirectLatency 6.09ns ± 0% 3.31ns ± 0% -45.67% (p=0.000 n=10+10)
SqrtGoLatency 36.1ns ± 6% 34.6ns ± 1% ~ (p=0.101 n=10+10)
SqrtPrime 2.53µs ± 2% 2.55µs ± 6% ~ (p=0.398 n=9+9)
Change-Id: If4be0f242c1d9d4feca7d269fc9cd6e6066f163d
Reviewed-on: https://go-review.googlesource.com/c/go/+/421074
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
addresses proposal #53084
required by sha-256 change list developed for #50543
Change-Id: I5454d746fce069a7a4993d70dc5b0a5544f8eeaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/408794
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@google.com>
Due to the latest binutils change [1], at least for certain 32-bit
relocs in .eh_frame section, this new type of relocation record is
emitted, leading to breakage on systems with bleeding-edge toolchain
when trying to link with object(s) with such new-style relocs.
Simply treating it the same as the existing reloc types seems enough.
Fixes#54222
[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f09482a8747b6fd4c2d59a6a64677d3a3fe1e092
Change-Id: I876d6711d5d4a674bead37e57f9503f1622d1136
Reviewed-on: https://go-review.googlesource.com/c/go/+/420983
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Single quotes don't account for whitespace in this context, which causes
output to look like this:
$ ./make.bat
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
Building Go cmd/dist using C:\Program Files\Go. (go version =)
When it should look like this:
Building Go cmd/dist using C:\Program Files\Go. (go1.19 windows/amd64)
For #44505.
Change-Id: I71328add5c74bd2829c0e23224cfa6252395ff2c
GitHub-Last-Rev: a01fda6b52
GitHub-Pull-Request: golang/go#54270
Reviewed-on: https://go-review.googlesource.com/c/go/+/421356
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
We use EDNS(0) by default. No need to fall back to netdns=cgo if we
see a explicit request for EDNS(0) in resolv.conf.
For #51153
Change-Id: I135363112e3de43ce877aad45aba71d1448068b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/415579
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
The existing value for M1 is 64, which is the same as other arm64 cpus.
But the correct cacheLineSize for M1 should be 128, which can be
verified using the following command:
$ sysctl -a hw | grep cachelinesize
hw.cachelinesize: 128
Fixes#53075
Change-Id: Iaa8330010a4499b9b357c70743d55aed6ddb8588
GitHub-Last-Rev: df87eb9c50
GitHub-Pull-Request: golang/go#53076
Reviewed-on: https://go-review.googlesource.com/c/go/+/408576
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Martin Möhrmann <martin@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Keith Randall <khr@google.com>
Change-Id: I79695e1cfda3b4cd911673f6e14dc316c451e2ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/423436
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Extra Ms may lead to the "no consistent ordering of events possible" error when parsing trace file with cgo enabled, since:
1. The gs in the extra Ms may be in `_Gdead` status while starting trace by invoking `runtime.StartTrace`,
2. and these gs will trigger `traceEvGoSysExit` events in `runtime.exitsyscall` when invoking go functions from c,
3. then, the events of those gs are under non-consistent ordering, due to missing the previous events.
Add two events, `traceEvGoCreate` and `traceEvGoInSyscall`, in `runtime.StartTrace`, will make the trace parser happy.
Fixes#29707
Change-Id: I7cc4b80822d2c46591304a59c9da2c9fc470f1d0
GitHub-Last-Rev: 445de8eaf3
GitHub-Pull-Request: golang/go#53284
Reviewed-on: https://go-review.googlesource.com/c/go/+/411034
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
The HTTP/1 server deletes multipart form tempfiles after ServeHTTP
returns, but the HTTP/2 server does not. Add a test to verify
cleanup happens in both cases, temporarily disabled for the
HTTP/2 path.
For #20253
Updates #25965
Change-Id: Ib753f2761fe73b29321d9d4337dbb5090fd193c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/423194
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Two packages construct atomic booleans from atomic integers.
Replace these implementations with the new atomic.Bool type.
Indeed, these packages were the impetus for the new atomic.Bool
type, having demonstrated a need to access boolean values
atomically.
Change-Id: I6a0314f8e7d660984a6daf36a62ed05a0eb74b2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/411400
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
When ReverseProxy forwards a request with no User-Agent header, leave
the header in the forwarded request blank rather than inserting the
default Go HTTP clent User-Agent.
We already did this for NewSingleHostReverseProxy; generalize it to
every ReverseProxy.
Change-Id: Id81a230cb8d384acdfae190b78a4265d80720388
Reviewed-on: https://go-review.googlesource.com/c/go/+/407375
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
X-Forwarded-Host contains the original request's host.
X-Forwarded-Proto contains "http" or "https", depending on whether the
original request was made on a TLS-secured connection.
Setting either header to nil in Director disables adding the header,
same as for X-Forwarded-For.
Fixes#50465.
Change-Id: If8ed1f48d83f8ea0389c53519bc7994cb53891db
Reviewed-on: https://go-review.googlesource.com/c/go/+/407414
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The current implementation ignores cookies where the
cookie name starts or ends with a space. For example,
name =value
is ignored.
I have come across pages that send cookies in this weird format.
I tested with the latest versions of Firefox, Safari and Chrome,
all of which accept cookies in this format.
To do this, I remove leading and trailing spaces from the
cookie name after cutting at '='.
Change-Id: I8fd0c37a2113b6ce75712dd43607d1ea55e86c68
GitHub-Last-Rev: 368f50fcb4
GitHub-Pull-Request: golang/go#52121
Reviewed-on: https://go-review.googlesource.com/c/go/+/397734
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
CL 310850 dropped work re-checks on non-spinning Ms to fix#43997.
This introduced a new race condition: a non-spinning M may drop its P
and then park at the same time a spinning M attempts to wake a P to
handle some new work. The spinning M fails to find an idle P (because
the non-spinning M hasn't quite made its P idle yet), and does nothing
assuming that the system is fully loaded. This results in loss of work
conservation. In the worst case we could have a complete deadlock if
injectglist fails to wake anything just as all Ps are going idle.
sched.needspinning adds new synchronization to cover this case. If work
submission fails to find a P, it sets needspinning to indicate that a
spinning M is required. When non-spinning Ms prepare to drop their P,
they check needspinning and abort going idle to become a spinning M
instead. This addresses the race without extra spurious wakeups. In the
normal (non-racing case), an M will become spinning via the normal path
and clear the flag.
injectglist must change in addition to wakep because it is a similar
form of work submission, notably used following netpoll at a point when
we might not have a P that would guarantee the work runs.
Fixes#45867
Change-Id: Ieb623a6d4162fb8c2be7b4ff8acdebcc3a0d69a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/389014
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This converts several unsynchronized reads (reads without holding
prof.signalLock) into atomic reads.
For #53821.
For #52912.
Change-Id: I421b96a22fbe26d699bcc21010c8a9e0f4efc276
Reviewed-on: https://go-review.googlesource.com/c/go/+/420196
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
I've dropped the note that sched.timeToRun is protected by sched.lock,
as it does not seem to be true.
For #53821.
Change-Id: I03f8dc6ca0bcd4ccf3ec113010a0aa39c6f7d6ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/419449
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
This converts a few unsynchronized accesses.
For #53821.
Change-Id: Ie2728779111e3e042696f15648981c5d5a86ca6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/419448
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Note that this replaces numerous unsynchronized loads throughout the
scheduler.
For #53821.
Change-Id: Ica80b04c9e8c184bfef186e549526fc3f117c387
Reviewed-on: https://go-review.googlesource.com/c/go/+/419447
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Note that this converts nmspinning from uint32 to int32 for consistency
with the other count fields in schedt.
For #53821.
Change-Id: Ia6ca7a2b476128eda3b68e9f0c7775ae66c0c744
Reviewed-on: https://go-review.googlesource.com/c/go/+/419446
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Note that this converts npidle from uint32 to int32 for consistency with
the other count fields in schedt and the type of p.id.
Note that this changes previously unsynchronized operations to
synchronized operations in:
* handoffp
* injectglist
* schedtrace
* schedEnableUser
* sync_runtime_canSpin
For #53821.
Change-Id: I36d1b3b4a28131c9d47884fade6bc44439dd6937
Reviewed-on: https://go-review.googlesource.com/c/go/+/419445
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Note that this converts ngsys from uint32 to int32 to match the other
(non-atomic) counters.
For #53821.
Change-Id: I3acbfbbd1dabc59b0ea5ddc86a97e0d0afa9f80c
Reviewed-on: https://go-review.googlesource.com/c/go/+/419444
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Note that this converts pollUntil from uint64 to int64, the type used by
nanotime().
For #53821.
Change-Id: Iec9ec7e09d3350552561d0708ba6ea9e8a8ae7ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/419443
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Note that this changes the type from uint64 to int64, the type used by
nanotime(). It also adds an atomic load in pollWork(), which used to use
a non-atomic load.
For #53821.
Change-Id: I6173c90f20bfdc0e0a4bc3a7b1c798d1c429fff5
Reviewed-on: https://go-review.googlesource.com/c/go/+/419442
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We currently print these as -1, but some are technically uint64. We can
be more explicit about their irrelevance by printing 'nil' rather than
-1.
Change-Id: I267fd8830564c75032bfe9176af59047f5a90202
Reviewed-on: https://go-review.googlesource.com/c/go/+/419441
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
schedt.goidgen and p.goidcache are already uint64, this makes all cases
consistent.
The only oddball here is schedtrace which prints -1 as an equivalent for
N/A or nil. A future CL will make this more explicit.
Change-Id: I489626f3232799f6ca333d0d103b71d9d3aa7494
Reviewed-on: https://go-review.googlesource.com/c/go/+/419440
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
If a program only uses ecdh.P256(), the implementation of the other
curves shouldn't end up in the binary. This mostly required moving some
operations from init() time. Small performance hit in uncompressed
Bytes/SetBytes, but not big enough to show up in higher-level
benchmarks. If it becomes a problem, we can fix it by pregenerating the
p-1 bytes representation in generate.go.
For #52182
Updates #52221
Change-Id: I64460973b59ee3df787d7e967a6c2bcbc114ba65
Reviewed-on: https://go-review.googlesource.com/c/go/+/402555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Fernando Lobato Meeser <felobato@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
We use crypto/internal/edwards25519/field to implement X25519 directly,
so that golang.org/x/crypto/curve25519 can be dropped from the src
module dependencies, and eventually replaced with a crypto/ecdh wrapper,
removing the need to keep golang.org/x/crypto/curve25519/internal/field
in sync with crypto/internal/edwards25519/field.
In crypto/internal/nistec, we add BytesX to serialize only the x
coordinate, which we'll need for the horrible ECDSA x-coord-to-scalar
operation, too.
In crypto/tls, we replace the ECDHE implementation with crypto/ecdh,
dropping the X25519 special cases and related scaffolding.
Finally, FINALLY, we deprecate the ~white whale~ big.Int-based APIs of
the crypto/elliptic package. •_•) ( •_•)>⌐■-■ (⌐■_■)
Fixes#52182Fixes#34648Fixes#52221
Change-Id: Iccdda210319cc892e96bb28a0e7b7123551982c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/398914
Reviewed-by: Fernando Lobato Meeser <felobato@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
ONAME nodes are shared, so using their position for anything is almost
always a mistake. There are probably more instances of this mistake
elsewhere. For now, handle the case of map key temporaries, where it's
been a problem.
Fixes#53456.
Change-Id: Id44e845d08d428592ad3ba31986635b6b87b0041
Reviewed-on: https://go-review.googlesource.com/c/go/+/417076
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #47653Fixes#45599Fixes#52522
Change-Id: Id6a80186434080cb0a205978ad7f224252674604
Reviewed-on: https://go-review.googlesource.com/c/go/+/408679
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Now that we've moved the trace locks to the leaf of the lock graph, we
can safely annotate that any trace event may acquire trace.lock even
if dynamically it turns out a particular event doesn't need to flush
and acquire this lock.
This reveals a new edge where we can trace while holding the mheap
lock, so we add this to the lock graph.
For #53789.
Updates #53979.
Change-Id: I13e2f6cd1b621cca4bed0cc13ef12e64d05c89a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/418720
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that trace.lock cannot be held over a stack split, we can move
that lock and traceStackTab to the leaf of the lock graph. We add a
couple edges to STACKGROW that were previously passing through trace.
Fixes#53979.
Change-Id: Ie664ff7bb33973745f991f7516dc6106e60f5892
Reviewed-on: https://go-review.googlesource.com/c/go/+/418957
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, trace.lock can be acquired while on a user G and stack
splits can happen while holding trace.lock. That means every lock used
by the stack allocator must be okay to acquire while holding
trace.lock, including various locks related to span allocation. In
turn, we cannot safely emit trace events while holding any
allocation-related locks because this would cause a cycle in the lock
rank graph.
To fix this, require that trace.lock only be acquired on the system
stack, like mheap.lock. This pushes it into the "bottom half" and
eliminates the lock rank relationship between tracing and stack
allocation, making it safe to emit trace events in many more places.
One subtlety is that the trace code has race annotations and uses
maps, which have race annotations. By default, we can't have race
annotations on the system stack, so we borrow the user race context
for these situations.
We'll update the lock graph itself in the next CL.
For #53979. This CL technically fixes the problem, but the lock rank
checker doesn't know that yet.
Change-Id: I9f5187a9c52a67bee4f7064db124b1ad53e5178f
Reviewed-on: https://go-review.googlesource.com/c/go/+/418956
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We're about to require that all uses of trace.lock be on the system
stack. That's mostly easy, except that it's involving parking the
trace reader. Fix this by changing that parking protocol so it instead
synchronizes through an atomic.
For #53979.
Change-Id: Icd6db8678dd01094029d7ad1c612029f571b4cbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/418955
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Writing out the trace footer currently manages trace buffers
differently from the rest of trace code. Rearrange it so it looks like
the rest of the code. In particular, we now write the frequency event
out to the trace buffer rather than returning it in a special byte
slice, and (*traceStackTable).dump threads a traceBufPtr like most
other functions that write to the trace buffers.
Change-Id: I3d0e108e56df884e7bd19823310dfbc0e21af9a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/422974
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Following up on the previous CL, this CL removes a unnecessary stack
copy of a large object in a range loop. This drops another 64 KiB from
(*traceStackTable).dump's stack frame so it is now roughly 80 bytes
depending on architecture, which will easily fit on the system stack.
For #53979.
Change-Id: I16f642f6f1982d0ed0a62371bf2e19379e5870eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/422955
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
