This change modifies the scavenger to no longer hold the heap lock while
actively scavenging pages. To achieve this, the change also:
* Reverses the locking behavior of the (*pageAlloc).scavenge API, to
only acquire the heap lock when necessary.
* Introduces a new lock on the scavenger-related fields in a pageAlloc
so that access to those fields doesn't require the heap lock. There
are a few places in the scavenge path, notably reservation, that
requires synchronization. The heap lock is far too heavy handed for
this case.
* Changes the scavenger to marks pages that are actively being scavenged
as allocated, and "frees" them back to the page allocator the usual
way.
* Lifts the heap-growth scavenging code out of mheap.grow, where the
heap lock is held, and into allocSpan, just after the lock is
released. Releasing the lock during mheap.grow is not feasible if we
want to ensure that allocation always makes progress (post-growth,
another allocator could come in and take all that space, forcing the
goroutine that just grew the heap to do so again).
This change means that the scavenger now must do more work for each
scavenge, but it is also now much more scalable. Although in theory it's
not great by always taking the locked paths in the page allocator, it
takes advantage of some properties of the allocator:
* Most of the time, the scavenger will be working with one page at a
time. The page allocator's locked path is optimized for this case.
* On the allocation path, it doesn't need to do the find operation at
all; it can go straight to setting bits for the range and updating the
summary structure.
Change-Id: Ie941d5e7c05dcc96476795c63fef74bcafc2a0f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/353974
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
CL 287654 converted the syscall package on openbsd/386 to use libc.
However, the mksyscall.pl invocation wasn't adjusted. Do so now to use
syscall_openbsd_libc.go like the other libc-based openbsd ports.
Change-Id: I48a7bd6ce4c25eca5222f560ed584e412b466111
Reviewed-on: https://go-review.googlesource.com/c/go/+/361481
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The first stack-trace in #49361 shows that traceBuf must precede fin in
lockrank ordering, since traceBuf is acquired in StartTrace(), which
eventually leads to getting fin in queueFinalizer(). It is fine to move
traceBuf above fin, since there are no other conflicting dependencies.
The second stack trace shows that there is an edge bewtween reflectOffs
and fin, since reflectOffs is acquired in addReflectOff, and map
operations can lead to an allocation that eventually causes fin to be
acquired in queueFinalizer().
Fixes#49361
Change-Id: I8e857ef9ecdff37fdd229e4dba22e15bc71d4ba5
Reviewed-on: https://go-review.googlesource.com/c/go/+/361407
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The argument liveness tests expect outputs where a dead stack slot
has a poisoned value. If the test function is preempted at the
prologue, it will go with the morestack code path which will spill
all the argument registers. Mark them nosplit to avoid that.
Should fix#49354.
Change-Id: I3b13e72e925748687a53c494bfaa70f07d9496fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/361211
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
CL 360057 fixed missing update source type in storeArgOrLoad. However,
we should only update the type when processing struct/array. If we
update the type right before calling storeArgOrLoad, we may generate a
value with invalid type, e.g, OpStructSelect with non-struct type.
Fixes#49378
Change-Id: Ib7e10f72f818880f550aae5c9f653db463ce29b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361594
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently, we rely on a "crawling" step during export to identify
function and method bodies that need to be exported or re-exported so
we can trim out unnecessary ones and reduce build artifact sizes. To
catch cases where we expect a function to be inlinable but we failed
to export its body, we made this condition a fatal compiler error.
However, with generics, it's much harder to perfectly identify all
function bodies that need to be exported; and several attempts at
tweaking the algorithm have resulted in still having failure cases.
So for now, this CL changes a missing inline body into a graceful
failure instead.
Change-Id: I04b0872d0dcaae9c3de473e92ce584e4ec6fd782
Reviewed-on: https://go-review.googlesource.com/c/go/+/361403
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
The current code, introduced in CL 2422, mixes K bits of entropy with
the private key and message digest to generate the signature nonce,
where K is half the bit size of the curve. While the ECDLP complexity
(and hence security level) of a curve is half its bit size, the birthday
bound on K bits is only K/2. For P-224, this means we should expect a
collision after 2^56 signatures over the same message with the same key.
A collision, which is unlikely, would still not be a major practical
concern, because the scheme would fall back to a secure deterministic
signature scheme, and simply leak the fact that the two signed messages
are the same (which is presumably already public).
Still, we can simplify the code and remove the eventuality by always
drawing 256 bits of entropy.
Change-Id: I58097bd3cfc9283503e38751c924c53d271af92b
Reviewed-on: https://go-review.googlesource.com/c/go/+/352530
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This adds a maymorestack hook that moves the stack at every
cooperative preemption point.
For #48297.
Change-Id: Ic15f9bcbc163345e6422586302d57fda4744caec
Reviewed-on: https://go-review.googlesource.com/c/go/+/359797
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
This adds a maymorestack hook that forces a preemption at every
possible cooperative preemption point. This would have helped us catch
several recent preemption-related bugs earlier, including #47302,
#47304, and #47441.
For #48297.
Change-Id: Ib82c973589c8a7223900e1842913b8591938fb9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/359796
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
This adds a debugging hook for optionally calling a "maymorestack"
function in the prologue of any function that might call morestack
(whether it does at run time or not). The maymorestack function will
let us improve lock checking and add debugging modes that stress
function preemption and stack growth.
Passes toolstash-check -all (except on js/wasm, where toolstash
appears to be broken)
Fixes#48297.
Change-Id: I27197947482b329af75dafb9971fc0d3a52eaf31
Reviewed-on: https://go-review.googlesource.com/c/go/+/359795
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This moves and slightly generalizes the -d debug flag parser from
cmd/compile/internal/base to cmd/internal/objabi so that we can use
the same debug flag syntax in other tools.
This makes a few minor tweaks to implementation details. The flag
itself is now just a flag.Value that gets constructed explicitly,
rather than at init time, and we've cleaned up the implementation a
little (e.g., using a map instead of a linear search of a slice). The
help text is now automatically alphabetized. Rather than describing
the values of some flags in the help text footer, we simply include it
in the flags' help text and make sure multi-line help text renders
sensibly.
For #48297.
Change-Id: Id373ee3b767e456be483fb28c110d025149be532
Reviewed-on: https://go-review.googlesource.com/c/go/+/359956
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A code comment on amd64 for windows and plan9 contained a snippet for
splitting apart the sec and nsec components of a unix timestamp, with
produced assembly below, which was then cleaned up by hand. When arm64
was ported, that code snippet in the comment went through the compiler
to produce some code that was then pasted and cleaned up. Unfortunately,
the comment had a typo in it, containing 8 zeros instead of 9.
This resulted in the constant used in the assembly being wrong, spotted
by @bufflig's eagle eyes. So, this commit fixes the comment on all three
platforms, and the assembly on windows/arm64.
Fixes#48072.
Change-Id: I786fe89147328b0d25544f52c927ddfdb9f6f1cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/361474
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
TestHammerStoreLoad involves a stress test of StorePointer, which has a
write barrier. The "pointer" that is being written is not a real value,
which is generally fine (though not *really* safe) on 64-bit systems
because they never point to an actual object.
On 32-bit systems, however, this is much more likely. Because I can't
figure out how to rewrite the test such that it still is testing the
same conditions but is also using real pointers, just disable the GC
during the test, and make sure there isn't one currently in progress.
Fixes#49362.
Change-Id: If81883fedf06568132e6484f40c820aa69027a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/361455
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
We were re-allocating a new RawSockaddrAny on every UDP read/write.
We can re-use them instead.
This reduces the number of allocs for UDP read/write on windows to zero.
Co-authored-by: David Crawshaw <crawshaw@golang.org>
Change-Id: I2f05c974e2e7b4f67937ae4e1c99583e81d140af
Reviewed-on: https://go-review.googlesource.com/c/go/+/361404
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
...instead of the structs themselves.
Escape analysis can handle this,
and it'll avoid a bunch of large struct copies.
Change-Id: Ia9c6064ed32a4c26d5a96dae2ed7d7ece6d38704
Reviewed-on: https://go-review.googlesource.com/c/go/+/361264
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The new GC pacer has a bug where the hard goal isn't set in relation to
the original heap goal, but rather to the one already extrapolated for
overshoot.
In practice, I have never once seen this case arise because the
extrapolated goal used for overshoot is conservative. No test because
writing a test for this case is impossible in the idealized model the
pacer tests create. It is possible to simulate but will take more work.
For now, just leave a TODO.
Change-Id: I24ff710016cd8100fad54f71b2c8cdea0f7dfa79
Reviewed-on: https://go-review.googlesource.com/c/go/+/361435
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
These error messages contain the expected shortened revision in braces,
but don't explicitly tell the user that this is the expected one.
Just unified it with the "does not match version-control timestamp" error which does the same...
Change-Id: I8e07df7bd776fd1b39c4c90c4788cb3d626ea00b
GitHub-Last-Rev: d14681ad08
GitHub-Pull-Request: golang/go#42578
Reviewed-on: https://go-review.googlesource.com/c/go/+/269877
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Fixes#49317
Change-Id: I4038fd4c1d845d54ecbbf82bf73060db1b44c9bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/361095
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The help text for the go test -shuffle flag is not indented like the
other flags. This patch brings it into alignment.
Fixes#49357
Change-Id: I3f18dc7cd84d5f23099262acf6e2fedccb11379c
Reviewed-on: https://go-review.googlesource.com/c/go/+/361395
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In modules that specify 'go 1.17' or higher, the go.mod file
explicitly requires modules for all packages transitively imported by
the main module. Users tend to use 'go mod download' to prepare for
testing the main module itself, so we should only download those
relevant modules.
In 'go 1.16' and earlier modules, we continue to download all modules
in the module graph (because we cannot in general tell which ones are
relevant without loading the full package import graph).
'go mod download all' continues to download every module in
'go list all', as it did before.
Fixes#44435
Change-Id: I3f286c0e2549d6688b3832ff116e6cd77a19401c
Reviewed-on: https://go-review.googlesource.com/c/go/+/357310
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
The behavior of all Curve methods and package functions when provided an
off-curve point is undefined, except for IsOnCurve which should really
always return false, not panic.
Change-Id: I52f65df25c5af0314fef2c63d0778db72c0f1313
Reviewed-on: https://go-review.googlesource.com/c/go/+/361402
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Adjust TypeDefn(), which is used by reportTypeLoop(), to work for nodes
with no Ntype set (which are all nodes in -G=3 mode). Normally,
reportTypeLoop() would not be called, because the types2 typechecker
would have already caught it. This is a possible way to report an
unusual type loop involving type params, which is not being caught by
the types2 type checker.
Updates #48962
Change-Id: I55edee46026eece2e8647c5b5b4d8dfb39eeb5f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/361398
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently allocToCache ham-handedly calls pageAlloc.allocRange on the
full size of the cache. This is fine as long as scavenged bits are never
set when alloc bits are set. This is true right now, but won't be true
as of the next CL.
This change makes allocToCache more carefully set the bits. Note that in
the allocToCache path, we were also calling update *twice*, erroneously.
The first time, with contig=true! Luckily today there's no correctness
error there because the page cache is small enough that the contig=true
logic doesn't matter, but this should at least improve allocation
performance a little bit.
Change-Id: I3ff9590ac86d251e4c5063cfd633570238b0cdbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/356609
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
The first step toward acquiring the heap lock less frequently in the
scavenger.
Change-Id: Idc69fd8602be2c83268c155951230d60e20b42fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/353973
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This doesn't handle every possible scenario,
but improves the one we can control. For example,
if the worker panics for some reason, we have no
way of knowing whether the panic occurred in an
expected way (while executing the fuzz target) or
due to an internal error in the worker. So any
panic will still be treated as a crash.
However, if it fails due to some internal bug that
we know how to catch, then the error should be
reported to the user without a new crasher being
written to testdata.
This is very difficult to test. The reasons an
internal error would occur is because something went
very wrong, and we have a bug in our code (which is
why they were previously panics). So simulating
a problem like this in a test is not really feasible.
Fixes#48804
Change-Id: I334618f84eb4a994a8d17419551a510b1fdef071
Reviewed-on: https://go-review.googlesource.com/c/go/+/361115
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Change-Id: Ifb90d5482cb0cedee6cb4d6297853ac7913d14ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/358674
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change implements the GC pacer redesign outlined in #44167 and the
accompanying design document, behind a GOEXPERIMENT flag that is on by
default.
In addition to adding the new pacer, this CL also includes code to track
and account for stack and globals scan work in the pacer and in the
assist credit system.
The new pacer also deviates slightly from the document in that it
increases the bound on the minimum trigger ratio from 0.6 (scaled by
GOGC) to 0.7. The logic behind this change is that the new pacer much
more consistently hits the goal (good!) leading to slightly less
frequent GC cycles, but _longer_ ones (in this case, bad!). It turns out
that the cost of having the GC on hurts throughput significantly (per
byte of memory used), though tail latencies can improve by up to 10%! To
be conservative, this change moves the value to 0.7 where there is a
small improvement to both throughput and latency, given the memory use.
Because the new pacer accounts for the two most significant sources of
scan work after heap objects, it is now also safer to reduce the minimum
heap size without leading to very poor amortization. This change thus
decreases the minimum heap size to 512 KiB, which corresponds to the
fact that the runtime has around 200 KiB of scannable globals always
there, up-front, providing a baseline.
Benchmark results: https://perf.golang.org/search?q=upload:20211001.6
tile38's KNearest benchmark shows a memory increase, but throughput (and
latency) per byte of memory used is better.
gopher-lua showed an increase in both CPU time and memory usage, but
subsequent attempts to reproduce this behavior are inconsistent.
Sometimes the overall performance is better, sometimes it's worse. This
suggests that the benchmark is fairly noisy in a way not captured by the
benchmarking framework itself.
biogo-igor is the only benchmark to show a significant performance loss.
This benchmark exhibits a very high GC rate, with relatively little work
to do in each cycle. The idle mark workers are quite active. In the new
pacer, mark phases are longer, mark assists are fewer, and some of that
time in mark assists has shifted to idle workers. Linux perf indicates
that the difference in CPU time can be mostly attributed to write-barrier
slow path related calls, which in turn indicates that the write barrier
being on for longer is the primary culprit. This also explains the memory
increase, as a longer mark phase leads to more memory allocated black,
surviving an extra cycle and contributing to the heap goal.
For #44167.
Change-Id: I8ac7cfef7d593e4a642c9b2be43fb3591a8ec9c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/309869
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
On ARM64 PE, when external linking, the PE relocation does not
have an explicit addend, and instead has the addend encoded in
the instruction or data. An instruction (e.g. ADRP, ADD) has
limited width for the addend, so when the addend is large we use
a label symbol, which points to the middle of the original target
symbol, and a smaller addend. But for an absolute address
relocation in the data section, we have the full width to encode
the addend and we should not use the label symbol. Also, since we
do not adjust the addend in the data, using the label symbol will
actually make it point to the wrong address. E.g for an R_ADDR
relocation targeting x+0x123456, we should emit 0x123456 in the
data with an IMAGE_REL_ARM64_ADDR64 relocation pointing to x,
whereas the current code emits 0x123456 in the data with an
IMAGE_REL_ARM64_ADDR64 relocation pointing to the label symbol
x+1MB, so it will actually be resolved to x+0x223456. This CL
fixes this.
Fixes#47557.
Change-Id: I64e02b56f1d792f8c20ca61b78623ef5c3e34d7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360895
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
In order to know the actual number of bytes
of the entire corpus entry, the coordinator
would likely need to unmarshal the bytes and
tally up the length. That's more work than it
is worth, so this change just clarifies that
the printed # of bytes is the length of the
entire file, not just the entry itself.
Fixes#48989
Change-Id: I6fa0c0206a249cefdf6335040c560ec0c5a55b4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/361414
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: I02724dadacd9b3f23ca7e6bda581cba62ceff828
Reviewed-on: https://go-review.googlesource.com/c/go/+/361274
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
https://golang.org/cl/246763 accidentally changed this to assign the old
value of vdsoPC to the upper half of sec as that is the last value in
R1.
The old value of vdsoPC is usually zero, so this typically works.
However, the reentrant case will have a non-zero value, resulting in a
bogus returned time. I am unsure if walltime is reachable from a signal
handler, so this may never occur.
Change-Id: I8562d6ec2a845fcffee9618d994b8ea57fbd199e
Reviewed-on: https://go-review.googlesource.com/c/go/+/361159
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Pull in the latest published version of github.com/google/pprof
as part of #36905.
This adds the fmt.Println redundant newline fix from
google/pprof@f987b9c94b.
Done with:
go get -d github.com/google/pprof@latest
go mod tidy
go mod vendor
For #36905.
Fixes#49322.
Change-Id: Ia832766bba65a30c68407b73b33fefbe81438e65
Reviewed-on: https://go-review.googlesource.com/c/go/+/361294
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Zvonimir Pavlinovic <zpavlinovic@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Zvonimir Pavlinovic <zpavlinovic@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
This enables the elimination of convertibleToImpl again,
with the code structure close to the original non-generic
version, and closely matching the structure of assignableTo.
We also don't need the hasTerm tests; instead we can rely
directly on the mechanism of TypeParam.is which is feeding
a nil term if there are no specific types.
Change-Id: I0385acca779d75c3c961d06afb464714fe51705d
Reviewed-on: https://go-review.googlesource.com/c/go/+/361269
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Don't inline a function fn that has no shape parameters, but is passed
at least one shape arg. This means we must be inlining a non-generic
function fn that was passed into a generic function, and can be called
with a shape arg because it matches an appropriate type parameter. But
fn may include an interface conversion (that may be applied to a shape
arg) that was not apparent when we first created the instantiation of
the generic function. We can't handle this if we actually do the
inlining, since we want to know all interface conversions immediately
after stenciling. So, we avoid inlining in this case.
Fixes#49309.
Change-Id: I7b8ab7b13e58fdb0111db91bc92a91d313f7c2c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/361260
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Update cmd/doc and go/doc for the generics, by adding handling for type
parameters and the new embedded interface elements.
Specifically:
- Format type parameters when summarizing type and function nodes.
- Find the origin type name for instantiation expressions, so that
methods are associated with generic type declarations.
- Generalize the handling of embedding 'error' in interfaces to
arbitrary predeclared types.
- Keep embedded type literals.
- Update filtering to descend into embedded type literals.
Also add "any" to the list of predeclared types.
Updates #49210
Change-Id: I6ea82869f19c3cdbc3c842f01581c8fc7e1c2ee7
Reviewed-on: https://go-review.googlesource.com/c/go/+/359778
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The x/sys/windows package currently uses go:linkname for other facilities
inside of runtime that are not suitable to be exposed as a public API
due to their dangers but are still necessary for manipulating any
low-level plumbing that the runtime controls.
Logging, via the built-in println and panic handler, is one such
low-level plumbing feature. In this case, x/sys/windows/svc needs to be
able to redirect panics to the Windows event log. Because the event log
is a complicated interface, this requires a bit more fiddling than the
simple solution used on Android (baking it into runtime itself), and
because Windows services are very diverse, the event log might not even
always be a desirable destination.
This commit accomplishes this by exposing a function pointer called
"overrideWrite" that low-level runtime packages like x/sys/windows/svc
can use to redirect output logs toward the event log or otherwise.
It is not safe or acceptable to use as a generic mechanism, and for that
reason, we wouldn't want to expose this as a real stable API, similar to
the other instances of go:linkname in x/sys/windows. But for packages
that must interoperate with low-level Go runtime fundamentals, this is a
safety hatch for packages that are developed in tandem with the runtime.
x/sys/windows is one such package.
Updates #42888.
Change-Id: I77a32ff7e1494324e8cc38e792e007f86d32672d
Reviewed-on: https://go-review.googlesource.com/c/go/+/278792
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The test had been setting an arbitrary 200ms timeout to allow the
server's handler to set up before timing out. That is not only
potentially flaky on slow machines, but also typically much longer
than necessary. Replace the hard-coded timeout with a much shorter
initial timeout, and use exponential backoff to lengthen it if needed.
This allows the test to be run about 20x faster in the typical case,
which may make it easier to reproduce rare failure modes by running
with a higher -count flag.
For #43120
Change-Id: I1e0d0ec99d5a107fff56e3bcc7174d686ec582d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/361275
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
It appears Windows 7 ignores WER_FAULT_REPORTING_NO_UI WerSetFlags
API flag.
And now after CL 307372, runtime will display WER GUI dialogue.
We don't want to introduce random GUI dialogues during Go program
execution. So disable dump crash creation on Windows 7 altogether.
Updates #20498
Change-Id: Ie268a7d4609f8a0eba4fe9ecf250856b0a61b331
Reviewed-on: https://go-review.googlesource.com/c/go/+/360617
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Patrik Nyblom <pnyb@google.com>
These functions are exported for the compiler and are used after
type checking is finished. There is no need to call under() in
their implementations; they can rely entirely on the public API.
This opens the door to moving them into the compiler eventually.
They may also be slightly more efficient.
Change-Id: Ib4f83d2dcf82e3c319c3147e01ecaea684553ea5
Reviewed-on: https://go-review.googlesource.com/c/go/+/361214
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
- reordered some functions for better organization
- renamed single arguments typ to t for consistency
- updated some comments
No functional changes.
Change-Id: I4362ac48044595cdf5c3d9eb7b2f7b94e776d65b
Reviewed-on: https://go-review.googlesource.com/c/go/+/360956
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is s/is_/is/ throughout. No other changes.
Change-Id: I1be77a209133edc68a6dec0677a4991a7683f116
Reviewed-on: https://go-review.googlesource.com/c/go/+/361134
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Rename the isX predicates to allX to clearly identify that these
predicates are looking inside type parameters.
Introduce is_X as predicates that do not look
inside type parameters so we can see all call sites.
The next CL will rename them all back to isX.
Review all call sites and use correct predicate.
Replace the single helper function is with isBasic and allBasic.
Change-Id: I3430ccfc466fdedf4b58a6158f95d47b9020f7a5
Change-Id: I81116b87cf8f2e17526723c7440676d133057aca
Reviewed-on: https://go-review.googlesource.com/c/go/+/360955
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a clean port of CL 360938 from go/types to types2.
For #49215.
Change-Id: If20779c862b71641cb6afe4c281fbad5488a8abe
Reviewed-on: https://go-review.googlesource.com/c/go/+/361266
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
After removing trivial wrapper types, the source needs to be updated
with new type, otherwise, it leads to mismatch between field offset and
the source type for selecting struct/array.
Fixes#49249
Change-Id: I26f9440bcb2e78bcf0617afc21d9d40cdbe4aca6
Reviewed-on: https://go-review.googlesource.com/c/go/+/360057
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
RegEnumKeyEx has an undocumented requirement that subsequent calls need
to be made from the same thread. This change documents that requirement
and fixes uses of it in std.
Fixes#49320.
Change-Id: I6d182227e22dd437996a878b3a978943f01b2d61
Reviewed-on: https://go-review.googlesource.com/c/go/+/361154
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Just add a test for another function that is not monomorphisable, which
comes from the Featherweight Go paper.
Updates #48018
Change-Id: I664e3f48412b02678e32b50204dc4befae90374c
Reviewed-on: https://go-review.googlesource.com/c/go/+/361262
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Type parameters only exist within the scope of a type or function
declaration, so there is really no reason to package-qualify them. It is
also confusing to do so, as it makes their type string look like a
defined type.
Fixes#49215
Change-Id: I986c527e78d45f3cadd75bc3b244e23dabe707ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/360938
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This redundancy is now caught by the improved printf vet checker.
Updates #49322
Change-Id: Ic7a931b8d4838be02ebb855b69624b95093bd114
Reviewed-on: https://go-review.googlesource.com/c/go/+/361265
Run-TryBot: Zvonimir Pavlinovic <zpavlinovic@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Zvonimir Pavlinovic <zpavlinovic@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This redundancy is now caught by the improved printf vet checker
(golang/go#30436).
Updates #49322
Change-Id: Id450247adc6fa28a9244c019be3c1b52c2d17f49
Reviewed-on: https://go-review.googlesource.com/c/go/+/361263
Run-TryBot: Zvonimir Pavlinovic <zpavlinovic@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Zvonimir Pavlinovic <zpavlinovic@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
These were identical. This is a preliminary step
towards remove allocs per UDP receive.
Change-Id: I83106cd3f1fe4bc5bae2d1b0ebd23eedd820abed
Reviewed-on: https://go-review.googlesource.com/c/go/+/361258
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These were identical. This is a preliminary step
towards remove allocs per UDP send.
Change-Id: I21e1264c7d4747baa626ddb93afff4c1cf225d13
Reviewed-on: https://go-review.googlesource.com/c/go/+/361256
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I67998f70969ac6e6ff1b52a56e49a61ef167ed50
Reviewed-on: https://go-review.googlesource.com/c/go/+/361055
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When drivers return driver.ErrBadConn, no meaningful
information about what the cause of the problem is
returned. Ideally the driver.ErrBadConn would be
always caught with the retry loop, but this is not
always the case. Drivers today must choose between
returning a useful error and use the rety logic.
This allows supporting both.
Fixes#47142
Change-Id: I454573028f041dfdf874eed6c254fb194ccf6d96
Reviewed-on: https://go-review.googlesource.com/c/go/+/333949
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 331490 and friends added new API to package syscall.
This was a mistake that we need to fix before Go 1.18 is released.
Change-Id: I697c9a4fa649d564822f585dc163df5ab9e5ae08
Reviewed-on: https://go-review.googlesource.com/c/go/+/361216
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Use go.shape instead of .shape as the package the compiler uses
to store shape types.
Prevent path escaping for compiler-internal types, so we don't
need to see %2e everywhere.
Change-Id: I98e39c3b6472560113bdea7e0ba6eb7b81cb35e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361174
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Fix idle connection reuse so that ConnMaxIdleTime clears down excessive
idle connections.
This now ensures that db.freeConn is ordered by returnedAt and that
connections that have been idle for the shortest period are reused
first.
In addition connectionCleanerRunLocked updates the next check deadline
based on idle and maximum life time information so that we avoid waiting
up to double MaxIdleTime to close connections.
Corrected the calling timer of connectionCleaner.
Fixes#39471
Change-Id: I6d26b3542179ef35aa13e5265a89bc0f08ba7fa1
Reviewed-on: https://go-review.googlesource.com/c/go/+/237337
Reviewed-by: Tamás Gulácsi <tgulacsi78@gmail.com>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Trust: Ian Lance Taylor <iant@golang.org>
On 64-bit, this is more efficient, and on ARM64, this prevents the time
from moving backwards due to the weaker memory model. On ARM32 due to
the weaker memory model, we issue a memory barrier.
Updates #48072.
Change-Id: If4695716c3039d8af14e14808af217f5c99fc93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/361057
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Pointers to arrays can be used to cast from a slice. We need
the shape of such type params to be different so we can compile
those casts correctly.
This is kind of a big hammer to fix#49295. It would be nice to
only do this when we know there's a []T->*[N]T conversion.
Fixes#49295
Change-Id: Ibda33057fab2dd28162537aab0f1244211d68e3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/361135
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
TestCPUProfileMultithreadMagnitude compares Go's CPU profile against the
OS's accounting of the process's execution time, expecting them to be
near equal. Background work from the runtime (especially in the garbage
collector) can add significant noise to that measurement and flakiness
to the test. Disable automatic GC cycles during the test.
Updates #49065
Change-Id: Ie88895bfea17374278c5187f3a83e9f486bd37fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/359934
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
This provides the runtime glue (_rt0_riscv64_linux_lib) for c-archive and c-shared
support, along with enabling both of these buildmodes on linux/riscv64.
Both misc/cgo/testcarchive and misc/cgo/testcshared now pass on this platform.
Fixes#47100
Change-Id: I7ad75b23ae1d592dbac60d15bba557668287711f
Reviewed-on: https://go-review.googlesource.com/c/go/+/334872
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The X3 (aka GP) register will potentially be loaded with the __global_pointer$ symbol
during program start up (usually by the dynamic linker). As such, non-Go code may depend
on the contents of GP and calculate offsets based on it, including code called via cgo
and signal handlers installed by non-Go code. As such, stop using the X3 register so
that there are fewer issues interacting between Go and non-Go code.
While here remove the X4 (TP) name from the assembler such that any references must
use the 'TP' name. This should reduce the likelihood of accidental use (like we do
for the 'g' register). The same applies for X3 (GP) when the -shared flag is given.
Updates #47100
Change-Id: I72e82b5ca3f80c46a781781345ca0432a4111b74
Reviewed-on: https://go-review.googlesource.com/c/go/+/351859
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Same logic as CL 357449 (including CL 360815), just ported to types2.
Updates #48098.
Change-Id: I4578f7329bb4ffc42410025bb6cb97e24697ebfd
Reviewed-on: https://go-review.googlesource.com/c/go/+/360857
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Fixes#49288
Change-Id: I7bfcbecbefa68871a3e556935a73f241fff44c0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360861
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is a port of CL 360795 to go/types. Error messages were adjusted
accordingly, with a TODO to fix the discrepancy.
Change-Id: Ifd7d8248fa11a31fde391021f3c5f1840877892f
Reviewed-on: https://go-review.googlesource.com/c/go/+/360937
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a clean port of CL 360603 to go/types.
Change-Id: Iadb312f07e509ff83339d5525765b7b7987bf233
Reviewed-on: https://go-review.googlesource.com/c/go/+/360936
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a clean port of CL 360514 to go/types.
Change-Id: Ia13638b3758b3b8017867934d09136ac5f9a62ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/360935
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of both CL 360396 and CL 360796 to go/types. The latter
is added to avoid introducing an intermediate bug.
An error message was adjusted in issue49296.go2, with a TODO to switch
to the types2 error.
Change-Id: Iede294b69b4e097e53876498f039ee18667568c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/360934
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Fixes#49287
Change-Id: I3f970d6db0b1dee886df2f7bb6cbeb56a37c42c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/360860
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
types2 methods are now sorted in the same way as types1, so this TODO is
no longer needed. (Comment change only).
Change-Id: Ic975ce001a5d54f15381a9cb7b6969dff795e3b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/360856
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is a clean port of CL 360274 to go/types.
Change-Id: Idfa584fab95f7226e10b1a7c5b06d56a0bf9d757
Reviewed-on: https://go-review.googlesource.com/c/go/+/360759
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a clean port of CL 359177 to go/types.
Change-Id: I6c1574e3a1c23ea326eb8d4aacea0e78415703ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/360758
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a clean port of CL 359015 to go/types.
Change-Id: Iea4e3bfe0a4ae0e5a9052cb6e66c01405bd57c3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/360756
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a clean port of CL 358621 to go/types.
Change-Id: I4e858b1b70cff69b6e0e76bb8a58a70ff54990c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/360755
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a clean port of CL 358774 to go/types.
Change-Id: Icba54336de2b8de7c2002d2a44cac856907178c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/360754
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
"so" didn't have an antecedent.
Change-Id: I27f7b334decea7bc34bfa3f3f2d3a79874c6fe90
Reviewed-on: https://go-review.googlesource.com/c/go/+/360797
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, opening a zip with (*Reader).Open could result in a panic if
the zip contained a file whose name was exclusively made up of slash
characters or ".." path elements.
Open could also panic if passed the empty string directly as an argument.
Now, any files in the zip whose name could not be made valid for
fs.FS.Open will be skipped, and no longer added to the fs.FS file list,
although they are still accessible through (*Reader).File.
Note that it was already the case that a file could be accessible from
(*Reader).Open with a name different from the one in (*Reader).File, as
the former is the cleaned name, while the latter is the original one.
Finally, made the actual panic site robust as a defense-in-depth measure.
Fixes CVE-2021-41772
Fixes#48085
Co-authored-by: Filippo Valsorda <filippo@golang.org>
Change-Id: I6271a3f2892e7746f52e213b8eba9a1bba974678
Reviewed-on: https://go-review.googlesource.com/c/go/+/349770
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Julie Qiu <julie@golang.org>
This is a port of CL 358597 to go/types. A comment was missing in the
base of applyTypeFunc, which had been there since the initial check-in
of types2; somehow it was not in go/types.
Change-Id: If08efd92d782dd3099b26254ae6e311c6cea8c3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/360477
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently, the syscall test suite takes very little time to run. It
stands to reason that pretty much every time, zero GCs execute.
With CL 309869, this changes because the minimum heap size is lowered,
triggering two bugs in the test suite.
One bug is in TestFcntlFlock, where a raw FD is wrapped in an os.File
whose last reference is passed into a Cmd. That FD is then closed by a
defer syscall.Close, instead of the os.File's Close, so the finalizer
may fire *after* that FD has already been reused by another test.
The second bug is in the child helper process of TestPassFD, where
there's a small window in which a temp file's FD is encoded for an
out-of-band unix domain socket message to the parent, but not yet sent.
The point of encoding is also the last reference that FD's os.File, so a
finalizer may run at any time. While it's safe for the finalizer to run
after the FD is sent, if it runs before, the send will fail, since unix
domain sockets require that any sent FDs are valid.
Change-Id: I2d1bd7e6db6efcc6763273217fd85cb5b9764274
Reviewed-on: https://go-review.googlesource.com/c/go/+/360575
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL replaces monoEdge's "report" field with fields "pos" and
"typ", and pushes the logic for formatting them into the report
loop. This avoids needing to allocate a function closure for each
edge.
Also tweak a test case so the two type parameters involved in the
cycle aren't both "T" so they're easier to understand.
Change-Id: I9d392ad1d99a4c5e89da4613084e885149ebad07
Reviewed-on: https://go-review.googlesource.com/c/go/+/360815
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This test assumes that two successive TCP connections will use different
source ports. This does not appear to be a universally safe assumption.
Rewrite the test to use httptrace to detect connection reuse instead.
Fixes#46707
Change-Id: Iebfbdfdeb77a1e6663a0c654dc847cc270c5d54d
Reviewed-on: https://go-review.googlesource.com/c/go/+/360854
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Fix a few types in the header comment for 'ComputePadding'.
Change-Id: If38911e6dcbec571845ae44eef30fd6c33f589cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/360814
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
It is now possible to do completely allocation-free UDP.
This is implemented completely separately from ReadFromUDP
because ReadFromUDP exists in a delicate balance to allow
mid-stack inlining. After performance-sensitive callers have
migrated to ReadFromUDPAddrPort, we may be able to simplify
ReadFromUDP to call ReadFromUDPAddrPort.
name old time/op new time/op delta
WriteToReadFromUDPAddrPort-8 4.71µs ± 2% 4.81µs ± 5% +2.18% (p=0.000 n=14+14)
name old alloc/op new alloc/op delta
WriteToReadFromUDPAddrPort-8 4.00B ± 0% 0.00B -100.00% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
WriteToReadFromUDPAddrPort-8 1.00 ± 0% 0.00 -100.00% (p=0.000 n=15+15)
Change-Id: I37f5ad9416a1d4333ed48d83474b2cf933b2a1be
Reviewed-on: https://go-review.googlesource.com/c/go/+/360600
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
See the recent change optimizing WriteMsgUDPAddrPort
for an explanation of why this change includes copy/paste/modify
instead of implementing WriteToUDP using WriteToUDPAddrPort.
name old time/op new time/op delta
WriteToReadFromUDPAddrPort-8 5.02µs ± 3% 4.71µs ± 2% -6.31% (p=0.000 n=15+14)
name old alloc/op new alloc/op delta
WriteToReadFromUDPAddrPort-8 68.0B ± 0% 4.0B ± 0% -94.12% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
WriteToReadFromUDPAddrPort-8 3.00 ± 0% 1.00 ± 0% -66.67% (p=0.000 n=15+15)
Change-Id: I301715e774de07eb6ccb4e329ccf2e554609abc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/360599
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The types of the two interfaces should be equal, but they aren't.
We end up with multiple descriptors for a type when we need type
descriptors to be unique.
Fixes#49241
Change-Id: I8a6c70da541c6088a92a01392bc83b61cc130eba
Reviewed-on: https://go-review.googlesource.com/c/go/+/360134
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Disallow the usage of coverprofile, blockprofile, cpuprofile, memprofile,
mutexprofile, and trace when fuzzing, since these currently do not work
as the user would expect.
Fixes#48178
Change-Id: Ibe6dfaef9b28a91c60c26fcad38c33a2a959d869
Reviewed-on: https://go-review.googlesource.com/c/go/+/360395
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This CL adds a check to ensure that generic Go code doesn't involve
any unbounded recursive instantiation, which are incompatible with an
implementation that uses static instantiation (i.e., monomorphization
or compile-time dictionary construction).
Updates #48098.
Change-Id: I9d051f0f9369ab881592a361a5d0e2a716788a6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/357449
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Improve TestIndexNearPageBoundary to verify needles
ending on a page boundary don't cause a segfault.
Change-Id: I2edb13db63a71dc9955e266f6b97026ee13bf76e
Reviewed-on: https://go-review.googlesource.com/c/go/+/356889
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
This is a port of CL 357917 to go/types. Some error messages in
assignability.go2 had to be adjusted. I left a TODO to investigate
whether we should align error messages.
Change-Id: Ia323ffe18bc08e82de62044f35b8b0f3edd7dc08
Reviewed-on: https://go-review.googlesource.com/c/go/+/360476
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of CL 358594 to go/types. Some code in conversions.go had
to be trivially reorganized to align with types2 -- I'm not sure how
go/types diverged from the base.
Change-Id: I40ce247bbb3b9d0e87ce88c50e440c12774c0745
Reviewed-on: https://go-review.googlesource.com/c/go/+/360475
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a clean port of CL 358175 to go/types.
Change-Id: If1b4e51d1579fd168e651d79d031335ff09ca128
Reviewed-on: https://go-review.googlesource.com/c/go/+/360474
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Make Go runtime throw if it's been compiled to assume instruction
set extensions that aren't available on the CPU.
Updates #48506
Change-Id: Ic4d6696e1cd6b28d389a86fe64e8175ea3ca135a
GitHub-Last-Rev: ba338377f5
GitHub-Pull-Request: golang/go#48514
Reviewed-on: https://go-review.googlesource.com/c/go/+/351191
Run-TryBot: Martin Möhrmann <martin@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <martin@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Martin Möhrmann <martin@golang.org>
When seeing Key:Value expression in slice literal, the compiler only
needs to emit tmp var for the Value, not the whole expression.
Fixes#49240
Change-Id: I7bda3c796a93c0fa1974f7c5930f38025dfa665c
Reviewed-on: https://go-review.googlesource.com/c/go/+/360055
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This reverts CL 351751.
Reason for revert: new test is failing on many builders.
Change-Id: I066211c9f25607ca9eb5299aedea2ecc5069e34f
Reviewed-on: https://go-review.googlesource.com/c/go/+/360757
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Correctly track if the index expression is addressable.
Rewrote code slightly.
Fixes#49275.
Change-Id: Ic54edd0213a091173ff5403ab0e3e1f1fca0e361
Reviewed-on: https://go-review.googlesource.com/c/go/+/360603
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For constraint type inference failures where the type parameter doesn't
match the constraint, print the type parameter rather than its type name
object. This provides more flexibility for improving the error message
down the road.
Change-Id: I188871d6f26a16cd96e59770966a1ec65607b128
Reviewed-on: https://go-review.googlesource.com/c/go/+/360514
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When converting a constant to a type parameter, the result is never
constant (type parameters are not constant types), but we still need
to verfy that the constant is representable by each specific type in
the type set of the type parameter.
Fixes#49247.
Change-Id: I460983c7070b33baadce25dd23210e10930cfb2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/360396
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Use gp.m.curg instead of the gp when recording cpu profiler stack
traces. This ensures profiler labels are captured when systemstack or similar
is executing on behalf of the current goroutine.
After this there are still rare cases of samples containing the labelHog
function, so more work might be needed. This patch should fix ~99% of the
problem.
Fixes#48577.
Change-Id: I27132110e3d09721ec3b3ef417122bc70d8f3279
Reviewed-on: https://go-review.googlesource.com/c/go/+/351751
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
TestExec and TestExecHelper check for a workaround of a particular OS
bug on darwin that's triggered more often via asynchronous preemption.
As part of this, the test sets up 100 CPU-bound goroutines, and sets
GOMAXPROCS to 50, sleeping for a little bit before calling Exec. Thus
far, this is fine because the scheduler runs the Execing goroutine in a
timely manner. However, CL 309869 will reduce the minimum heap size,
causing a GC to happen during the test.
On a 16 CPU machine, with GOMAXPROCS at 50, and 100 CPU-bound
goroutines, both the OS scheduler and the Go scheduler are severly
oversaturated. As a result, the test often (not always, but often) runs
out for the full lifetime of those 100 goroutines, which run for about 1
second.
The minimum heap size reduction is not necessary to trigger this; an
additional call to runtime.GC in the helper is also sufficient to
trigger this delay.
The delay on its own isn't great, since it adds a whole second to
all.bash on its own. However, it also seems correlated with other
subprocess tests in the syscall package, namely TestPassFD and
TestFcntlFlock. These tests fail in a fairly superficial way: the file
descriptor for the temporary directories they make gets clobbered, is
closed, or becomes stale.
Change-Id: I213dd5e38967d19a8b317e6d4c5024b57f9e3fed
Reviewed-on: https://go-review.googlesource.com/c/go/+/360574
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add asan tests to check the use of Go with -asan option.
Currenly, the address sanitizer in Go only checks for error
memory access to heap objects.
TODO: Enable check for error memory access to global objects.
Updates #44853.
Change-Id: I83579f229f117b5684a369fc8f365f4dea140648
Reviewed-on: https://go-review.googlesource.com/c/go/+/298615
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Go exchanges siginfo and sigevent structures with the kernel. They
contain unions, but Go's use is limited to the first few fields. Pad out
the rest so the size Go sees is the same as what the Linux kernel sees.
This is a follow-up to CL 342052 which added the sigevent struct without
padding, and to CL 353136 which added the padding but with an assertion
that confused several type-checkers. It updates the siginfo struct as
well so there are no bad examples in the defs_linux_*.go files.
Reviewed-on: https://go-review.googlesource.com/c/go/+/353136
Change-Id: I9610632ff0ec43eba91f560536f5441fa907b36f
Reviewed-on: https://go-review.googlesource.com/c/go/+/360094
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Add explicit address sanitizer instrumentation to the runtime and
syscall packages. The compiler does not instrument the runtime
package. It does instrument the syscall package, but we need to add
a couple of cases that it can't see.
Refer to the implementation of the asan malloc runtime library,
this patch also allocates extra memory as the redzone, around the
returned memory region, and marks the redzone as unaddressable to
detect the overflows or underflows.
Updates #44853.
Change-Id: I2753d1cc1296935a66bf521e31ce91e35fcdf798
Reviewed-on: https://go-review.googlesource.com/c/go/+/298614
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: fannie zhang <Fannie.Zhang@arm.com>
This is one step towards optimizing WriteMsgUDPAddrPort.
Further steps remain, namely to avoid the syscall.Sockaddr interface,
as we do for UDPConn.WriteToUDP and UDPConn.ReadFromUDP.
A previous change optimized ReadMsgUDPAddrPort by having
ReadMsgUDP call ReadMsgUDPAddrPort rather than the other way around.
This change does not implement WriteMsgUDP in terms of WriteMsgUDPAddrPort,
because a few layers deep, on posix platforms only
(in ipToSockaddrInet4 and ipToSockaddrInet6),
is special handling of zero-length IP addresses and IPv4zero.
It treats IP(nil) as equivalent to 0.0.0.0 or ::,
and 0.0.0.0 as equivalent to :: in an IPv6 context.
Based on the comments, I suspect that this treatment was intended
for the Listen* API, not the Write* API, but it affects both,
and I am nervous about changing the behavior for Write*.
The netip package doesn't have a way to represent a "zero-length IP address"
as distinct from an invalid IP address (which is a good thing),
so to implement WriteMsgUDP using WriteMsgUDPAddrPort,
we would have to duplicate this special handling at the start of WriteMsgUDP.
But this handling depends on whether the UDPConn is an IPv4 or an IPv6 conn,
which is also platform-specific information.
As a result, every attempt I made to implement WriteMsgUDP using
WriteMsgUDPAddrPort while preserving behavior ended up
being considerably worse than copy/paste/modify.
This does mean that WriteMsgUDP and WriteMsgUDPAddrPort will have
different behavior in these cases.
name old time/op new time/op delta
ReadWriteMsgUDPAddrPort-8 5.29µs ± 6% 5.02µs ± 7% -5.14% (p=0.000 n=13+15)
name old alloc/op new alloc/op delta
ReadWriteMsgUDPAddrPort-8 128B ± 0% 64B ± 0% -50.00% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
ReadWriteMsgUDPAddrPort-8 4.00 ± 0% 2.00 ± 0% -50.00% (p=0.000 n=15+15)
Change-Id: Ia78eb49734f4301d7772dfdbb5a87e4d303a9f7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/360597
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Instead of implementing ReadMsgUDPAddrPort in terms of ReadMsgUDP,
do it the other way around. This keeps the code minimal while
still avoiding allocs.
We could also rearrange ReadMsgUDP to be mid-stack inlined to avoid
allocating the *UDPAddr, but anyone who's trying to eliminate
allocs should use ReadMsgUDPAddrPort instead anyway,
because ReadMsgUDP will always allocate at least once (the IP slice).
name old time/op new time/op delta
ReadWriteMsgUDPAddrPort-8 5.26µs ± 3% 5.29µs ± 6% ~ (p=0.429 n=12+13)
name old alloc/op new alloc/op delta
ReadWriteMsgUDPAddrPort-8 176B ± 0% 128B ± 0% -27.27% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
ReadWriteMsgUDPAddrPort-8 5.00 ± 0% 4.00 ± 0% -20.00% (p=0.000 n=15+15)
Change-Id: I15228cb4ec4f13f2f390407b6c62c44c228e7201
Reviewed-on: https://go-review.googlesource.com/c/go/+/360596
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In case of reference to method call of an imported fully-instantiated
type, nameNode.Func will be nil causes checkFetchBody panic. To fix
this, make sure checkFetchBody is only called when Func is not nil.
Fixes#49246
Change-Id: I32e9208385a86d4600d8ebf6f5efd8fca571ea16
Reviewed-on: https://go-review.googlesource.com/c/go/+/360056
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Previously, when resolving references of form
(https://golang.org/?hello).ResolveReference(?)
we only used URL.RawQuery to determine whether or not a query part is
defined. Go 1.7 introduced URL.ForceQuery as a flag for the situation
where a query part is provided but empty. But we did not use it in
ResolveReference. This leads to the erroneous output
https://golang.org/?hello
when the correct output should be
https://golang.org/?
This commit rectifies that error.
Fixes#46033
Change-Id: I05bc0b48bf2bbf13b4ddc0dd10599ea613dc2188
Reviewed-on: https://go-review.googlesource.com/c/go/+/317930
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Damien Neil <dneil@google.com>
When type inference cannot infer type arguments it prints the list of
inferred type arguments (often empty) at the end of the error message.
This was meant as debugging support only. Removed for now.
Eventually we should provide a better error message.
Fixes#49272.
Change-Id: I68d43a6ace91081009cab0f2fbad7bfbddf5e76b
Reviewed-on: https://go-review.googlesource.com/c/go/+/360554
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This benchmark simulates object starvation in order to force Ps to steal
objects from other Ps. Extracted from CL 314229.
Change-Id: Iee31df355ba04d80fbd91c4414e397a375e6d6d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/360256
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Trust: Cherry Mui <cherryyz@google.com>
If a identical input is already present in the corpus, don't re-add it.
This may happen when the same input produces a different coverage map,
causing the coordinator to think it has found a new input.
This fixes a race between reading/writing cached inputs.
Fixes#48721
Change-Id: I4807602f433c2b99396d25ceaa58b827796b3555
Reviewed-on: https://go-review.googlesource.com/c/go/+/359755
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
Fixes#49213
Change-Id: I2bfc151b74b0d14efbd00e5d28584f4180126c5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/359656
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This is a port of CL 359656 from go/types to types2.
For #49213.
Change-Id: Ib98f9a344c1397af92e061cafd519ea374fd60bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/360294
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a port of CL 357814 from go/types to types2 with minor
adjustments due to small differences in error handling code.
Change-Id: I72ecc4532e8349f569cabb38006f3d8ff517bf30
Reviewed-on: https://go-review.googlesource.com/c/go/+/360276
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When checking assignability, a value of a named type (incl. a type parameter)
can never be assigned to a variable of a differently named type. Specifically,
if the types are two differently named type parameters, then values of one are
never assignable to variables of the other.
This CL clarifies the assignabiliy rules and simplifies the implementation.
Fixes#49242.
Change-Id: Id72a2c9bed5cdb726855e7a707137db1009e7953
Reviewed-on: https://go-review.googlesource.com/c/go/+/360274
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Add a comment how strings of length 0 are treated and
that they always will result in the return of a string
equal to the constant string "".
The previous implementation would return a string header that uses
runtime.zerobase as the backing array pointer while the string constant
"" has 0 as pointer value.
Using 0 has the backing array pointer is also the behaviour of
string([]byte(input)) which makes the new behaviour a better drop in
replacement.
Change-Id: Ic5460e9494b6708edbdfa4361e878d50db54ba10
Reviewed-on: https://go-review.googlesource.com/c/go/+/360255
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Martin Möhrmann <martin@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This code is only generated when linking cgo internally with fixed
position code. This feature of the internal linker is only supported
on ppc64le/linux targets. This moves ppc64le/linux a little closer
to supporting PIE when internal linking.
This is more similar to the implementation suggested in the power
architecture elfv2 supplement, and works with both PIE and static
code.
Change-Id: I0b64e1c22b9e07b5151378d2ab19ee0e50405fc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/357332
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is heavily based on CL 341336 by Joe Tsai and CL 351452 by
Jay Conrod.
T.Run and T.Name use a map[string]int64 to hold the next suffix to use
when duplicate names are passed to T.Run. This map necessarily retains
one entry per unique name. However, it's a waste of memory to retain
one entry per duplicate name: when we encounter the Nth duplicate, we
know that names 00 through N-1 have been used just by looking at N.
We do still need to store (and check for collisions againsts) explicit
names provided by the caller. For example, if the user passes in "a",
then "a#01", then "a" again, we cannot deduplicate the second "a" to
"a#01" — we need to instead skip ahead to "a#02". We can do so by
checking the count of "a", then generating a proposed deduplicated
name, then double-checking that proposed name against only the
explicit names so far.
This somewhat reduces memory usage for tests that spawn large numbers
of duplicate subtests, but doesn't solve the problem of memory growth
for fuzzing — we still have to track all of the explicit,
user-provided subtest names, and in a long-running fuzz test that set
alone may be unbounded.
This fixes memory growth for the example described in
https://golang.org/issue/44517#issuecomment-897104060,
but not the one in
https://golang.org/issue/44517#issuecomment-933825661.
For #44517
Change-Id: Ia159ecfcf44561ba67508d3af6377c27856df31d
Reviewed-on: https://go-review.googlesource.com/c/go/+/354749
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Use a pointer reciever to avoid copying the hiter struct when
checking if it is intialized.
Found through profiling that showed reflect map iteration spending
a good amount of time in duffcopy.
This change will also help other MapIter methods checking hiter struct
initialization like Value() and Key().
name old time/op new time/op delta
MapIterNext-12 97.9ns ± 4% 83.8ns ± 2% -14.37% (p=0.000 n=10+10)
Change-Id: I73ab964fa28061ee7e6d5c663a85048bd2e0274e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360254
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Martin Möhrmann <martin@golang.org>
Simplify the parsing of array or slice constraint types added in CL
359134, following the port in CL 360135.
Change-Id: Ia86d4b0149a222423d3b19623dd39d4aeb23857d
Reviewed-on: https://go-review.googlesource.com/c/go/+/360115
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The intention is for BenchmarkFooBar functions to map 1:1 to drawFooBar
functions. Recent draw.go changes have added more drawFooBar functions
and have further modified the mapping, as fallback drawFooBar functions
aren't invoked as often as they used to.
This commit restores the 1:1 mapping and reorganizes the BenchmarkFooBar
functions in the same order as the matching drawFooBar functions appear.
Also modify a TestDraw test case from vgradGreen(255) = {0, 136, 0, 255}
to vgradGreen(90) = {0, 48, 0, 90}. Doing so matches the existing "The
source pixel is {0, 48, 0, 90}" comment but also makes for a more
interesting test case, as the source pixel is no longer fully opaque.
Fully opaque is already covered by the vgradGray() test case on the next
line.
Also fix a "variable source" comment copy-pasto when the source image is
actually uniform, not variable.
Also add a func DrawMask type switch comment about interface types.
Change-Id: I828e71f2ee8ec617f523c8aafb118fb7ba166876
Reviewed-on: https://go-review.googlesource.com/c/go/+/358974
Trust: Nigel Tao <nigeltao@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a port of the idea used in CL 359134 from go/parser to syntax,
with adjustments due to the slightly different structure of the two
parsers, and some refactoring to simplify the logic.
Fixes#49175.
Change-Id: Ib4955bde708f2b08345f35523e6094c03ab3076c
Reviewed-on: https://go-review.googlesource.com/c/go/+/360135
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
There are multiple things preventing the -memprofilerate flag from
working right now:
- CmdFlags.MemProfileRate has type int64, which is currently not
supported by the compiler's reflection-based registerFlags.
Unfortunately, rather than letting you know this, registerFlags
simply ignores this field.
- Nothing consumes CmdFlags.MemProfileRate anyway. startProfile
instead uses a package-local memprofilerate variable that is never
set to anything.
Fix this by making CmdFlags.MemProfileRate an int (that's what
runtime.MemProfileRate is anyway) and using it in startProfile. While
we're here, prevent similar flag parsing bugs in the future by making
registerFlags panic if it encounters a flag field of unsupported type.
Change-Id: Ib9a1fcd8f4c5e9d7175a4fabc375f31e79774f9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/359955
Trust: Austin Clements <austin@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Currently, the compiler will emit any const that doesn't fit in an
int64 to go_asm.h like
#define const_stackPreempt constant.intVal{val:(*big.Int)(0xc000c06c40)}
This happens because dumpasmhdr formats the constant.Value using the
verb "%#v". Since constant.Value doesn't implement the GoString()
method, this just prints the Go-syntax representation of the value.
This happens to work for small integer constants, which go/constant
represents directly as an int64, but not for integer constants that
don't fit in an int64, which go/constant represents as a big.Int.
Make these constants usable by changing the formatting verb to "%v",
which will call the String() method, giving a reasonable result in all
cases.
Change-Id: I365eeb88c8acfc43ff377cc873432269bde3f541
Reviewed-on: https://go-review.googlesource.com/c/go/+/359954
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This abstracts the clunky and not constant time math/big elliptic.Curve
compatibility layer away from the pure fiat-backed group logic.
Change-Id: I3b7a7495034d0c569b21c442ae36958763b8b2d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/320074
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Julie Qiu <julie@golang.org>
Michael Anthony Knyszek
Tobias Klauser
Josh Bleecher Snyder
Dan Scales
Brad Fitzpatrick
Cherry Mui
Cuong Manh Le
Matthew Dempsky
Andy Pan
lgbgbl
Filippo Valsorda
Austin Clements
Jason A. Donenfeld
Matthias Dötsch
Bryan C. Mills
Simon Law
Katie Hockman
jiahua wang
Michael Pratt
Dmitri Shuralyov
Robert Griesemer
Robert Findley
Alex Brainman
Zvonimir Pavlinovic
Mostafa Solati
Daniel Theophanes
Keith Randall
Steven Hartland
Rhys Hiltner
Joel Sing
Ian Lance Taylor
Jason7602
Damien Neil
Than McIntosh
Roland Shoemaker
Paul E. Murphy
vpachkov
Amelia Downs
Felix Geisendörfer
fanzha02
Timothy Gu
Ruslan Andreev
zhouguangyuan
Martin Möhrmann
Alexander Melentyev
Nigel Tao