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>
Add test for indexing on variables whose types are constrained to
various kinds of types.
Change-Id: I991eecfe39dba5d817c0fbe259ba558d4881ea84
Reviewed-on: https://go-review.googlesource.com/c/go/+/360867
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>
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>
