When an opcode generates a known high bit state (typically, a sub-word
operation that zeros the high bits), we can remove any subsequent
extension operation that would be a no-op.
x = (OP ...)
y = (ZeroExt32to64 x)
If OP zeros the high 32 bits, then we can replace y with x, as the
zero extension doesn't do anything.
However, x in this situation normally has a sub-word-sized type. The
semantics of values in registers is typically that the high bits
beyond the value's type size are junk. So although the opcode
generating x *currently* zeros the high bits, after x is rewritten to
another opcode it may not - rewrites of sub-word-sized values can
trash the high bits.
To fix, move the extension-removing rules to late lower. That ensures
that their arguments won't be rewritten to change their high bits.
I am also worried about spilling and restoring. Spilling and restoring
doesn't preserve the high bits, but instead sets them to a known value
(often 0, but in some cases it could be sign-extended). I am unable
to come up with a case that would cause a problem here, so leaving for
another time.
Update #66076
Change-Id: I3b5c091b3b3278ccbb7f11beda8b56f4b6d3fde7
Reviewed-on: https://go-review.googlesource.com/c/go/+/568616
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit a46ecdca36)
Reviewed-on: https://go-review.googlesource.com/c/go/+/573375
Fixes a couple of misalignments with RFC 5322 which introduce
significant diffs between (mostly) conformant parsers.
This change reverts the changes made in CL50911, which allowed certain
special RFC 5322 characters to appear unquoted in the "phrase" syntax.
It is unclear why this change was made in the first place, and created
a divergence from comformant parsers. In particular this resulted in
treating comments in display names incorrectly.
Additionally properly handle trailing malformed comments in the group
syntax.
For #65083Fixed#65849
Change-Id: I00dddc044c6ae3381154e43236632604c390f672
Reviewed-on: https://go-review.googlesource.com/c/go/+/555596
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/566215
Reviewed-by: Carlos Amedee <carlos@golang.org>
This change fixes a bug where we incorrectly filtered out the main
modules from the beginning of the build list before verifying them. We
made the assumption that the first MainModules.Len() entries of the
build list were the main modules, but now it can contain the go and
toolchain version entries, so removing the first MainModules.Len()
entries could leave main module names in the build list if any of
their names sorted after the string 'go'.
For #62663Fixes#65852
Change-Id: I35ab6857a556f58d306303322afe24c48fc8b38f
Reviewed-on: https://go-review.googlesource.com/c/go/+/565378
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 3f60da7944)
Reviewed-on: https://go-review.googlesource.com/c/go/+/565775
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
To determine the identity of a goroutine for displaying in the trace UI,
we should use the root frame from a call stack. This will be the
starting function for the goroutine and is the same for each call stack
from a given goroutine. The new tracer no longer includes starting PCs
for goroutines which existed at the start of tracing, so we can't use a
PC for grouping together goroutines any more. Instead, we just use the
name of the entry function for grouping.
For #65574Fixes#65577
Change-Id: I5324653316f1acf0ab90c30680f181060ea45dd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/562455
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit a51713103b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/562558
Reviewed-by: Michael Pratt <mpratt@google.com>
The jump table symbol is accessed only from the function symbol
(in the same package), so it can be static. Also, if the function
is DUPOK and it is, somehow, compiled differently in two different
packages, the linker must choose the jump table symbol associated
to the function symbol it chose. Currently the jump table symbol
is DUPOK, so that is not guaranteed. Making it static will
guarantee that, as each copy of the function symbol refers to its
own jump table symbol.
Updates #65783.
Fixes#65818.
Change-Id: I27e051d01ef585d07700b75d4dfac5768f16441e
Reviewed-on: https://go-review.googlesource.com/c/go/+/565535
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit 2908352980)
Reviewed-on: https://go-review.googlesource.com/c/go/+/566475
PGO uses noder.LookupFunc to look for devirtualization targets in
export data. LookupFunc does not support type-parameterized
functions, and will currently fail the build when attempting to lookup
a type-parameterized function because objIdx is passed the wrong
number of type arguments.
This doesn't usually come up, as a PGO profile will report a generic
function with a symbol name like Func[.go.shape.foo]. In export data,
this is just Func, so when we do LookupFunc("Func[.go.shape.foo]")
lookup simply fails because the name doesn't exist.
However, if Func is not generic when the profile is collected, but the
source has since changed to make Func generic, then LookupFunc("Func")
will find the object successfully, only to fail the build because we
failed to provide type arguments.
Handle this with a objIdxMayFail, which allows graceful failure if the
object requires type arguments.
Bumping the language version to 1.21 in pgo_devirtualize_test.go is
required for type inference of the uses of mult.MultFn in
cmd/compile/internal/test/testdata/pgo/devirtualize/devirt_test.go.
For #65615.
Fixes#65618.
Change-Id: I84d9344840b851182f5321b8f7a29a591221b29f
Reviewed-on: https://go-review.googlesource.com/c/go/+/562737
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 532c6f1c8d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/563016
testenv's TestHasGoBuild test is supposed to allow noopt builders to not
have go build, but the pattern match is failing on the LUCI builders
where a test shard might have an additional "-test_only" suffix in the
builder name. Furthermore, in the LUCI world, "run mods" (the builder
type suffixes) are supposed to be well-defined and composable, so it
doesn't make sense to restrict "-noopt" to the builder suffix anyway.
This change modifies the test to allow "-noopt" to appear anywhere in
the builder name when checking if it's running on a noopt builder.
For #65470.
Fixes#65471.
Change-Id: I393818e3e8e452c7b0927cbc65726d552aa8ff8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/558596
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
(cherry picked from commit 93f0c0b25e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/560696
Currently there are a few places where a P can get stolen where the
runtime doesn't traceAcquire and traceRelease across the steal itself.
What can happen then is the following scenario:
- Thread 1 enters a syscall and writes an event about it.
- Thread 2 steals Thread 1's P.
- Thread 1 exits the syscall and writes one or more events about it.
- Tracing ends (trace.gen is set to 0).
- Thread 2 checks to see if it should write an event for the P it just
stole, sees that tracing is disabled, and doesn't.
This results in broken traces, because there's a missing ProcSteal
event. The parser always waits for a ProcSteal to advance a
GoSyscallEndBlocked event, and in this case, it never comes.
Fixes#65181.
Change-Id: I437629499bb7669bf7fe2fc6fc4f64c53002916b
Reviewed-on: https://go-review.googlesource.com/c/go/+/560235
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit c9d88ea2aa)
Reviewed-on: https://go-review.googlesource.com/c/go/+/559958
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently the trace map is cleared with an assignment, but this ends up
invoking write barriers. Theoretically, write barriers could try to
write a trace event and eventually try to acquire the same lock. The
static lock ranking expresses this constraint.
This change replaces the assignment with a call to memclrNoHeapPointer
to clear the map, removing the write barriers.
Note that technically this problem is purely theoretical. The way the
trace maps are used today is such that reset is only ever called when
the tracer is no longer writing events that could emit data into a map.
Furthermore, reset is never called from an event-writing context.
Therefore another way to resolve this is to simply not hold the trace
map lock over the reset operation. However, this makes the trace map
implementation less robust because it needs to be used in a very
specific way. Furthermore, the rest of the trace map code avoids write
barriers already since its internal structures are all notinheap, so
it's actually more consistent to just avoid write barriers in the reset
method.
Fixes#56554.
Change-Id: Icd86472e75e25161b2c10c1c8aaae2c2fed4f67f
Reviewed-on: https://go-review.googlesource.com/c/go/+/560216
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 829f2ce3ba)
Reviewed-on: https://go-review.googlesource.com/c/go/+/559957
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently the stop reason for runtime.Gosched is labeled
"runtime.GoSched" which doesn't actually match the function name. Fix
the label to match the function name.
This change doesn't regenerate the internal/trace/v2 tests, because
regenerating the tests breaks summarization tests in internal/trace that
rely on very specific details in the example traces that aren't
guaranteed. Also, go122-gc-trace.test isn't generated at all, as it
turns out. I'll fix this all up in a follow-up CL. For now, just replace
runtime.GoSched with runtime.Gosched in the traces so we don't have a
problem later if a test wants to look for that string.
This change does regenerate the cmd/trace/v2 test, but it turns out the
cmd/trace/v2 tests are way too strict about network unblock events, and
3 usually pop up instead of 1 or 2, which is what the test expects.
AFAICT this looks plausible to me, so just lift the restriction on
"up to 2" events entirely.
Change-Id: Id7350132be19119c743c259f2f5250903bf41a04
Reviewed-on: https://go-review.googlesource.com/c/go/+/552275
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit 287f791845)
Reviewed-on: https://go-review.googlesource.com/c/go/+/560555
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
The proposal discussion made clear that suffixes should be accepted,
so that people who use custom VERSION files can still pass runtime.Version()
to this code. But we forgot to do that in the CL. Do that.
Note that cmd/go also strips space- and tab-prefixed suffixes,
but go.dev/doc/toolchain only mentions dash, so this code only
strips dash.
Fixes#65061.
Change-Id: I6a427b78f964eb41c024890dae30223beaef13eb
Cq-Include-Trybots: luci.golang.try:go1.22-linux-amd64-longtest,go1.22-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/559796
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/559802
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently the new execution tracer's handling of CPU profile samples is
very best-effort. The same CPU profile buffer is used across
generations, leading to a high probability that CPU samples will bleed
across generations. Also, because the CPU profile buffer (not the trace
buffer the samples get written into) isn't guaranteed to be flushed when
we close out a generation, nor when tracing stops. This has led to test
failures, but can more generally just lead to lost samples.
In general, lost samples are considered OK. The CPU profile buffer is
only read from every 100 ms, so if it fills up too much before then, old
samples will get overwritten. The tests already account for this, and in
that sense the CPU profile samples are already best-effort. But with
actual CPU profiles, this is really the only condition under which
samples are dropped.
This CL aims to align CPU profiles better with traces by eliminating
all best-effort parts of the implementation aside from the possibility
of dropped samples from a full buffer.
To achieve this, this CL adds a second CPU profile buffer and has the
SIGPROF handler pick which CPU profile buffer to use based on the
generation, much like every other part of the tracer. The SIGPROF
handler then reads the trace generation, but not before ensuring it
can't change: it grabs its own thread's trace seqlock. It's possible
that a SIGPROF signal lands while this seqlock is already held by the
thread. Luckily this is detectable and the SIGPROF handler can simply
elide the locking if this happens (the tracer will already wait until
all threads exit their seqlock critical section).
Now that there are two CPU profile buffers written to, the read side
needs to change. Instead of calling traceAcquire/traceRelease for every
single CPU sample event, the trace CPU profile reader goroutine holds
this conceptual lock over the entirety of flushing a buffer. This means
it can pick the CPU profile buffer for the current generation to flush.
With all this machinery in place, we're now at a point where all CPU
profile samples get divided into either the previous generation or the
current generation. This is good, since it means that we're able to
emit profile samples into the correct generation, avoiding surprises in
the final trace. All that's missing is to flush the CPU profile buffer
from the previous generation, once the runtime has moved on from that
generation. That is, when the generation counter updates, there may yet
be CPU profile samples sitting in the last generation's buffer. So,
traceCPUFlush now first flushes the CPU profile buffer, followed by any
trace buffers containing CPU profile samples.
The end result of all this is that no sample gets left behind unless it
gets overwritten in the CPU profile buffer in the first place. CPU
profile samples in the trace will now also get attributed to the right
generation, since the SIGPROF handler now participates in the tracer's
synchronization across trace generations.
Fixes#55317.
Change-Id: I47719fad164c544eef0bb12f99c8f3c15358e344
Reviewed-on: https://go-review.googlesource.com/c/go/+/555495
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
(cherry picked from commit f5e475edaf)
Reviewed-on: https://go-review.googlesource.com/c/go/+/557838
Reviewed-by: Cherry Mui <cherryyz@google.com>
Earlier in the development of the new tracer, m.id was used as a the
canonical ID for threads. Later, we switched to m.procid because it
matches the underlying OS resource. However, in that switch, we missed a
spot.
The tracer catches and emits statuses for goroutines that have remained
in either waiting or syscall across a whole generation, and emits a
thread ID for the latter set. The ID being used here, however, was m.id
instead of m.procid, like the rest of the tracer.
This CL also adds a regression test. In order to make the regression
test actually catch the failure, we also have to make the parser a
little less lenient about GoStatus events with GoSyscall: if this isn't
the first generation, then we should've seen the goroutine bound to an
M already when its status is getting emitted for its context. If we emit
the wrong ID, then we'll catch the issue when we emit the right ID when
the goroutine exits the syscall.
Fixes#65196.
Change-Id: I78b64fbea65308de5e1291c478a082a732a8bf9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/557456
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit c46966653f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/557436
This works around an apparent bug in the Git HTTP backend, introduced
in Git 2.21, that causes responses for the version 1 protocol to
provide incomplete tags.
For Git commands older than 2.18, this configuration flag is ignored.
(Note that Git 2.29 and above already use protocol version 2 by
default.)
Fixes#56881.
Change-Id: I9b241cfb604e5f633ca6a5d799df6706246684a7
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/556358
Run-TryBot: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Add missing checks for the case where the range expression is
a (possibly untyped) constant integer expression.
Add context parameter to assignVar for better error message
where the expression is part of a range clause.
Also, rename s/expr/Expr/ where it denotes an AST expression,
for clarity.
Fixes#65133.
For #65137.
Change-Id: I72962d76741abe79f613e251f7b060e99261d3ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/556398
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Now, this is embarrassing. For the whole Go 1.20 and Go 1.21 cycles, we
based RSA public key operation (verification and decryption) benchmarks
on the keys in rsa_test.go, which had E = 3. Most keys in use, including
all those generated by GenerateKey, have E = 65537. This significantly
skewed even relative benchmarks, because the new constant-time
algorithms would incur a larger slowdown for larger exponents.
I noticed this only because I got a production profile for an
application that does a lot of RSA verifications, saw ExpShort show up,
made ExpShort faster, and the crypto/rsa profiles didn't move.
We were measuring the wrong thing, and the slowdown was worse than we
thought. My apologies.
(If E had not been parametrized, it would have avoided issues like this
one, too. Grumble. https://words.filippo.io/parameters/#fn9)
goos: darwin
goarch: arm64
pkg: crypto/rsa
│ g35222eeb78 │ new │
│ sec/op │ sec/op vs base │
DecryptPKCS1v15/2048-8 1.414m ± 2% 1.417m ± 1% ~ (p=0.971 n=10)
DecryptPKCS1v15/3072-8 4.107m ± 0% 4.160m ± 1% +1.29% (p=0.000 n=10)
DecryptPKCS1v15/4096-8 9.363m ± 1% 9.305m ± 1% ~ (p=0.143 n=10)
EncryptPKCS1v15/2048-8 162.8µ ± 2% 212.1µ ± 0% +30.34% (p=0.000 n=10)
DecryptOAEP/2048-8 1.460m ± 4% 1.413m ± 1% ~ (p=0.105 n=10)
EncryptOAEP/2048-8 161.7µ ± 0% 213.4µ ± 0% +31.99% (p=0.000 n=10)
SignPKCS1v15/2048-8 1.419m ± 1% 1.476m ± 1% +4.05% (p=0.000 n=10)
VerifyPKCS1v15/2048-8 160.6µ ± 0% 212.6µ ± 3% +32.38% (p=0.000 n=10)
SignPSS/2048-8 1.419m ± 0% 1.477m ± 2% +4.07% (p=0.000 n=10)
VerifyPSS/2048-8 163.9µ ± 8% 212.3µ ± 0% +29.50% (p=0.000 n=10)
geomean 802.5µ 899.1µ +12.04%
Updates #63516
Change-Id: Iab4a0684d8101ae07dac8462908d8058fe5e9f3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/552895
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 555355 has a bug in it - the GC program flag was also used to decide
when to free the unrolled bitmap. After that CL, we just don't free any
unrolled bitmaps, leading to a memory leak.
Use a separate flag to track types that need to be freed when their
corresponding object is freed.
Change-Id: I841b65492561f5b5e1853875fbd8e8a872205a84
Reviewed-on: https://go-review.googlesource.com/c/go/+/555416
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Accurate position information for embedded types in interfaces is
crucial to identify the corresponding source file, and with that
the Go language version associated with that file. (The position
information is also important for proper error messages.)
Before this CL, the position information for embedded types was
discarded after type set computation, in the assumption that it
was not needed anymore. However, substitutions that update the
interface may lead to repeated type set computations which then
won't have the correct position information.
This CL does preserve the position information for embedded
types until the end of type checking (cleanup phase), and also
copy the position information during a substitution of the
interface.
The respective bug (#64759) doesn't seem to appear in 1.22 (most
likely because it's hidden by some of the changes made with respect
to the file version logic), but the existing code is still wrong.
The backport of this code to 1.21 and 1.20 fixes the issue in those
releases.
For #64759.
Change-Id: I80f4004c9d79cb02eac6739c324c477706615102
Reviewed-on: https://go-review.googlesource.com/c/go/+/555296
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Per https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html:
“If, when attempting to write a file, the destination directory is
non-existent an attempt should be made to create it with permission
0700. […] The application should be prepared to handle the case where
the file could not be written […]. In such case it may choose to
present an error message to the user.”
In certain CI environments, these directories have well-defined
locations but do not exist and cannot be created. In that case,
we now choose to log and return from the test without failing it.
To prevent the functions from falling back to being entirely untested,
we still fail the test (and “present an error message to the user”) if
either function returns an empty string without an error, or returns a
path that refers to a non-directory or results in an error other than
ErrNotExist.
In addition, since the tests themselves no longer create subdirectories,
we add examples illustrating the suggested pattern of usage.
Fixes#64990.
Change-Id: Ie72106424f5ebe36eaf9288c22710d74bb14a462
Reviewed-on: https://go-review.googlesource.com/c/go/+/554815
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Shape-based stenciling in the Go compiler's generic instantiation
phase looks up shape types using the underlying type of a given target
type. This has a beneficial effect in most cases (e.g. we can use the
same shape type for two different named types whose underlying type is
"int"), but causes some problems when the underlying type is a very
large structure. The link string for the underlying type of a large
imported struct can be extremely long, since the link string
essentially enumerates the full package path for every field type;
this can produce a "go.shape.struct { ... " symbol name that is
absurdly long.
This patch switches the compiler to use a hash of the underlying type
link string instead of the string itself, which should continue to
provide commoning but keep symbol name lengths reasonable for shape
types based on large imported structs.
Fixes#65030.
Change-Id: I87d602626c43172beb99c186b8ef72327b8227a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/554975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Than McIntosh <thanm@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 549536 intended to decouple the internal implementation of rwmutex
from the semantic meaning of an rwmutex read/write lock in the static
lock ranking.
Unfortunately, it was not thought through well enough. The internals
were represented with the rwmutexR and rwmutexW lock ranks. The idea was
that the internal lock ranks need not model the higher-level ordering,
since those have separate rankings. That is incorrect; rwmutexW is held
for the duration of a write lock, so it must be ranked before any lock
taken while any write lock is held, which is precisely what we were
trying to avoid.
This is visible in violations like:
0 : execW 11 0x0
1 : rwmutexW 51 0x111d9c8
2 : fin 30 0x111d3a0
fatal error: lock ordering problem
execW < fin is modeled, but rwmutexW < fin is missing.
Fix this by eliminating the rwmutexR/W lock ranks shared across
different types of rwmutex. Instead require users to define an
additional "internal" lock rank to represent the implementation details
of rwmutex.rLock. We can avoid an additional "internal" lock rank for
rwmutex.wLock because the existing writeRank has the same semantics for
semantic and internal locking. i.e., writeRank is held for the duration
of a write lock, which is exactly how rwmutex.wLock is used, so we can
use writeRank directly on wLock.
For #64722.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-staticlockranking
Change-Id: Ia572de188a46ba8fe054ae28537648beaa16b12c
Reviewed-on: https://go-review.googlesource.com/c/go/+/555055
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Merge List:
+ 2024-01-08 8eaa7935db net: clarify maxListenerBacklog windows implementation
+ 2024-01-08 759849187f log/slog: clarify SetDefault behavior
+ 2024-01-08 10a66d6816 sync: use map[any]any instead of map[interface{}]interface{} in the godoc
+ 2024-01-08 881869dde0 cmd/compile: handle defined iter func type correctly
+ 2024-01-05 1ae729e6d3 doc: s/adjustements/adjustments
+ 2024-01-05 8088b6db23 slices: explicitly discard results of some functions
+ 2024-01-05 c0693f648a cmd/go: run cover tool before swig
+ 2024-01-04 8db131082d github: switch seen/expected order in issue forms
+ 2024-01-04 ead47b0ab3 net/http: respond with 400 Bad Request for empty hex number of chunk length
+ 2024-01-04 1e07c144c3 net/http/cgi: in TestCopyError, check for a Handler.ServeHTTP goroutine instead of a running PID
+ 2024-01-04 15dcdeb5aa cmd/api: fix panic on exported basic type aliases
+ 2024-01-03 6db1102605 pagetrace: fix build when experiment is on
+ 2024-01-03 7d1b82dbf1 net/http: make Request.Clone create fresh copies for matches and otherValues
+ 2024-01-03 aa0a6ad1db doc/go1.22: add links to go/types symbols
+ 2024-01-03 c95fe91d07 runtime: correct scavengeIndex.sysGrow min index handling
+ 2023-12-30 b25f5558c6 all: replace outdated links
+ 2023-12-30 3233542e85 reflect: fix typo in type.go
+ 2023-12-27 988b718f41 doc: fix typo in example in spec
+ 2023-12-27 26ba75fe59 doc: document new iteration variable semantics in spec
+ 2023-12-27 1dddd83c49 doc: document version at which new language features were introduced in spec
+ 2023-12-26 36a2463e7c lib/time: update to 2023d/2023d
+ 2023-12-21 2184a39477 runtime/metrics: godoc link fixes
+ 2023-12-21 9c01ecce48 doc: fix misspelling in go1.22 release notes
+ 2023-12-21 0b56804084 runtime: use racereleasemerge for godebugInc
+ 2023-12-21 f6509cf5cd cmd/compile: handle constant-folding of an out-of-range jump table index
+ 2023-12-20 adec22b9f7 doc/go1.22: document changes to vet loopclosure analyzer
+ 2023-12-20 a2a2c5b947 doc: update unsafe.Pointer rule in spec
+ 2023-12-19 35222eeb78 doc: add html/template release note
Change-Id: I0709455dc512c94d2cbdb15c10d5c91f4bdaaa71
The previous TODO comments were somewhat ambiguous. This aims to
provide a clearer understanding of the behavior on Windows.
Windows does not offer a way to peek at the current backlog length, this
is explicitly stated in the winapi for `listen`.
When set to `syscall.SOMAXCONN`, the OS dynamically adjusts the
backlog to a maximum reasonable value. It goes as far as the dotnet
runtime itself introducing a new version of `listen` that does not accept a
backlog parameter to help eliminate the confusion when comparing the
behavior with UNIXes.
The docs also mention that `SOMAXCONN_HINT(N)` can be used, and that
it clips the final computed value between (200, 65535), which suggests
windows might use a `uint16` to back this number. Either way it does not
matter since windows will adjust this value anyway, so I removed the
wrapping TODO as well.
See https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen
Change-Id: I7b2e7cb547467c4bfc572ef0477a58de8c772521
GitHub-Last-Rev: 34e74abffe
GitHub-Pull-Request: golang/go#63549
Reviewed-on: https://go-review.googlesource.com/c/go/+/535475
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When building a package, run the cover tool on the collected go/cgo
source files before invoking swig (if swig files are present), as
opposed to running swig and then cover. Running swig adds new Go files
to the "cgo" list, and we want to avoid running those newly generated
files through the cover tool.
Fixes#64661.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I32b6dad5c39fcf5e656c40fb3b44220c69320889
Reviewed-on: https://go-review.googlesource.com/c/go/+/552095
Auto-Submit: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Previously, the test could fail spuriously if the CGI process's PID
happened to be reused in between checks. That sort of reuse is highly
unlikely on platforms that cycle through the PID space sequentially
(such as Linux), but plausible on platforms that use randomized PIDs
(such as OpenBSD).
Also unskip the test on Windows, since it no longer relies on being
able to send signal 0 to an arbitrary PID.
Also change the expected failure mode of the test to a timeout instead
of a call to t.Fatalf, so that on failure we get a useful goroutine
dump for debugging instead of a non-actionable failure message.
Fixes#57369 (maybe).
Change-Id: Ib7e3fff556450b48cb5e6ea120fdf4d53547479b
Reviewed-on: https://go-review.googlesource.com/c/go/+/554075
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
The order of emitting named type and type aliases in the `Walker`'s
`emitType` function is inverted. When the type alias references a basic
type, this causes a panic as the type assertion on `*types.Named` fails.
This change reorders the logic such that type aliases are emitted prior
to this type assertion.
Fixes#64958
Change-Id: I52dbe13999978912ded788d9cf4948103869bcfa
Reviewed-on: https://go-review.googlesource.com/c/go/+/554076
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
The backing store for the scavengeIndex chunks slice is allocated on demand
as page allocation occurs. When pageAlloc.grow is called, a range is
allocated from a reserved region, before scavengeIndex.grow is called
to ensure that the chunks needed to manage this new range have a valid
backing store. The valid region for chunks is recorded as the index min
and index max. Any changes need to take the existing valid range into
consideration and ensure that a contiguous valid range is maintained.
However, a bug in the min index handling can currently lead to an existing
part of the chunk slice backing store being zeroed via remapping. Initially,
there is no backing store allocated and both min and max are zero. As soon
as an allocation occurs max will be non-zero, however it is still valid for
min to be zero depending on the base addresses of the page allocations. A
sequence like the following will trigger the bug:
1. A page allocation occurs requiring chunks [0, 512) (after rounding) - a
sysMap occurs for the backing store, min is set to 0 and max is set
to 512.
2. A page allocation occurs requiring chunks [512, 1024) - another sysMap
occurs for this part of the backing store, max is set to 1024, however
min is incorrectly set to 512, since haveMin == 0 (validly).
3. Another page allocation occurs requiring chunks [0, 512) - since min is
currently 512 a sysMap occurs for the already mapped and inuse part
of the backing store from [0, 512), zeroing the chunk data.
Correct this by only updating min when either haveMax == 0 (the
uninitialised case) or when needMin < haveMin (the case where the new
backing store range is actually below the current allocation). Remove
the unnecessary haveMax == 0 check for updating max, as the existing
needMax > haveMax case already covers this.
Fixes#63385
Change-Id: I9deed74c4ffa187c98286fe7110e5d735e81f35f
Reviewed-on: https://go-review.googlesource.com/c/go/+/553135
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Add a new section to the Appendix describing what features were
changed or added in which language version.
Add short links with references to the required language version
where relevant.
Fixes#63857.
Change-Id: I5250f856d8688a71602076fcc662aa678d96a5d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/549518
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
CL 549796 adds race annotations to godebugInc. It uses racerelease
to model a CompareAndSwap. However, a CompareAndSwap is
essentially a load and a store. Modeling it as just racerelease
makes it not synchronized with other racerelease, i.e. other CAS.
For the following execution
thread A B
load, got nil
load, got nil
set *inc
set *inc
racerelease
CAS success
racerelease
CAS fail
load
raceacquire
use *inc (from A)
On thread B, the raceacquire synchronizes with the previous
racerelease, which is not synchronized with racerelease on thread
A, so it doesn't know that the use of *inc on thread B is after
the set on thread A, and will report a race.
Change it to use racereleasemerge, which synchronizes with
previous racerelease and racereleasemerge. So in the case above it
knows thread B's CAS is after thread A's.
Also remove stale comment that was more relevant when the code
used atomic store, where CL 549796 changed to CAS.
Updates #64649.
Change-Id: I17671090a19c0699fcb4e6481e2abd98ef2e5542
Reviewed-on: https://go-review.googlesource.com/c/go/+/551856
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
The valid conversions consider the core types of operands, not just
their underlying type.
This also explains the valid arguments for unsafe.Slice which are
explained in terms of unsafe.Pointer conversions.
unsafe.SliceData simply refers to "slice argument" and we use
similar terminology elsewhere in the spec to denote values that
have a core type of slice (or any other type for that matter).
Leaving alone for now.
Fixes#64452.
Change-Id: I0eed3abbc0606f22358835e5d434f026fe0909c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/551379
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Merge List:
+ 2023-12-19 03242506de doc: comment out remaining TODOs in Go 1.22 relnotes (for now)
+ 2023-12-19 9dd1cde9ac doc/go1.22,cmd/go: document that 'go mod init' no longer imports from other vendoring tools
+ 2023-12-19 22284c34f2 doc/go1.22: document removal of 'go get' support in GOPATH mode
+ 2023-12-19 339177aa31 doc: typo fix for net/http.ServeMux
+ 2023-12-19 52dbffeac8 cmd/go/internal/toolchain: revert "make a best effort to parse 'go run' and 'go install' flags"
Change-Id: I102e8267373364d0ad6170d36442d19048268765
Per the discussion on the issue, since no problems related to this
appeared since Go 1.20, remove the ability to disable the check for
anonymous interface cycles permanently.
Adjust various tests accordingly.
For #56103.
Change-Id: Ica2b28752dca08934bbbc163a9b062ae1eb2a834
Reviewed-on: https://go-review.googlesource.com/c/go/+/550896
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Also fix its call site in internal/poll to pass the length of the
actual buffer instead of an unrelated variable, and update the
definition of FILE_BASIC_INFO to match the documented field types
and add padding that is empirically needed on the 386 architecture.
Passing a pointer to a Go-allocated buffer as type uintptr violates
the unsafe.Pointer conversion rules, which allow such a conversion
only in the call expression itself for a call to syscall.Syscall or
equivalent. That can allow the buffer to be corrupted arbitrarily if
the Go runtime happens to garbage-collect it while the call to
SetFileInformationByHandle is in progress.
The Microsoft documentation for SetFileInformationByHandle specifies
its third argument type as LPVOID, which corresponds to Go's
unsafe.Pointer, not uintptr.
Fixes#58933 (maybe).
Change-Id: If577b57adea9922f5fcca55e46030c703d8f035c
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/549256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This test was added to check new mutex profile functionality.
Specifically, it checks to make sure that the functionality behind
GODEBUG=runtimecontentionstacks works. The runtime currently tracks
contention from runtime-internal mutexes in mutex profiles, but it does
not record stack traces for them, attributing the time to a dummy
symbol. This GODEBUG enables collecting stacks.
Just disable the test. Even if this functionality breaks, it won't
affect Go users and it'll help keep the builders green. It's fine to
leave the test because this will be revisited in the next dev cycle.
For #64253.
Change-Id: I7938fe0f036fc4e4a0764f030e691e312ec2c9b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/550775
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently, lock ranking doesn't really try to model rwmutex. It records
the internal locks rLock and wLock, but in a subpar fashion:
1. wLock is held from lock to unlock, so it works OK, but it conflates
write locks of all rwmutexes as rwmutexW, rather than allowing
different rwmutexes to have different rankings.
2. rLock is an internal implementation detail that is only taken when
there is contention in rlock. As as result, the reader lock path is
almost never checked.
Add proper modeling. rwmutexR and rwmutexW remain as the ranks of the
internal locks, which have their own ordering. The new init method is
passed the ranks of the higher level lock that this represents, just
like lockInit for mutex.
execW ordered before MALLOC captures the case from #64722. i.e., there
can be allocation between BeforeFork and AfterFork.
For #64722.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-staticlockranking
Change-Id: I23335b28faa42fb04f1bc9da02fdf54d1616cd28
Reviewed-on: https://go-review.googlesource.com/c/go/+/549536
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Right shift by 0 has bad semantics. Make sure if we try to right shift by 0,
do a left shift by 0 instead.
CL 549955 handled full instructions with this strange no-op encoding.
This CL handles the shift done to instruction register inputs.
(The former is implemented using the latter, but not until deep
inside the assembler.)
Update #64715
Change-Id: Ibfabb4b13e2595551e58b977162fe005aaaa0ad1
Reviewed-on: https://go-review.googlesource.com/c/go/+/550335
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Also use CompareAndSwap to make the code actually less racy.
Added a test which will be meaningful when run under the race
detector (tested it -race with broken fix in runtime, it failed).
Fixes#64649
Change-Id: I5972e08901d1adc8ba74858edad7eba91be1b0ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/549796
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When the argument to 'go install' or 'go run' looks like a versioned
package, we make a best effort to switch to a toolchain compatible
with the module containing that package, by fetching its go.mod file
and checking the go version it specifies.
At this point in the code, we have not yet parsed the arguments given
on the command line: instead, we just make a best effort to find one
we can use to select a toolchain version. Since that toolchain may be
newer, the command to install it may also include flags that are only
supported by that Go version — and we don't want to fail due to an
error that would be resolved by switching to a more appropriate
toolchain.
So at this point in the code we can't parse the flags in a way that
will surface errors, but we want to make a best effort to parse the
ones that we know about. It turns out that “parse the flags we know
about” is already a familiar problem: that's also what we do in
'go test', so we can reuse the cmdflag library from that to do the
best-effort pass of parsing.
If it turns out that we don't need to switch toolchains after all,
cmd/go's main function will parse the flags again, and will report any
errors at that point.
This fixes a regression, introduced in CL 497879, which caused
'go install -modcacherw pkg@version' to unset the write bit for
directories created while selecting the toolchain to use.
Fixes#64282.
Updates #57001.
Change-Id: Icc409c57858aa15c7d58a97a61964b4bc2560547
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/546635
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This works around a bug in 'git http-backend' that was fixed in
Git 2.34.0,¹ and will hopefully allow the tests in
cmd/go/internal/modfetch/codehost to pass reliably using older
Git releases (I tested with 2.30.2).
¹ff6a37c99eFixes#56881.
Change-Id: Icd2e4d252d5f712685d146f34e11922dd0c41ff0
Reviewed-on: https://go-review.googlesource.com/c/go/+/549795
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
When generic function[a,b] is inlined to the same generic function[b,a]
with different types (not recursion) it is expected to get a pprof with
a single Location with two functions. However due to incorrect check
for generics names using runtime.Frame.Function, the profileBuilder
assumes it is a recursion and emits separate Location.
This change fixes the recursion check for generics functions by using
runtime_expandFinalInlineFrame
Fixes#64641
Change-Id: I3f58818f08ee322b281daa377fa421555ad328c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/549135
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change lookupMethod such that "foldCase" means "ignore case
and package" and analyze a lookup result further to determine
if a method name was not exported, and report a better error
message in that case.
Fixes#59831.
Change-Id: Ice6222e1fc00dba13caeda6c48971e8473d12da5
Reviewed-on: https://go-review.googlesource.com/c/go/+/549298
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
This is a partial fix for situations where a method lookup leads to
an error due to non-matching signatures, but where the signatures
print exactly the same. This can happen if both signatures contain
type parameters (after instantiation) and the type parameters have
the same name (such as "T").
For now, rather than printing a confusing error message in this
case, leave away the confusing part of the error message (at the
cost of providing slightly less information).
In the long run, we need to find a better solution for this problem;
but this seems better than what we had before.
For #61685.
Change-Id: I259183f08b9db400ffc8e1cf447967c640a0f444
Reviewed-on: https://go-review.googlesource.com/c/go/+/549296
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Introduce a new type "target" to pass around target types together
with a suitable description (typically a variable name) for a better
error message.
As a side effect, using a specific type (target), rather than just Type
avoids accidental confusion with other types.
Use the target type description for a better error message in some
cases.
The error message can be further improved by flipping the order of
the sentence (for another CL to keep this one small and simple).
Also, and unrelated to this fix, remove the first argument to errorf
in infer.go: the argument is always "type" (there's only one call).
For #60747.
Change-Id: I2118d0fe9e2b4aac959371941064e0e9ca7b3b6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/548995
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
If we encounter an unclassified error in modload.Query, it takes
precedence even if the package is found in some other module.
(That is intentional, so that if a package exists in both a parent
and a nested module the outcome is deterministic, and does not shift
if a temporary error causes one of the modules to be unavailable.)
A pseudo-version is formed from a base version and a commit hash.
Each version tag is specific to the module in a particular directory
of the repo (often the root directory), whereas the commit hash is
the same for all subdirectories. When we go to check a particular
subdirectory for the requested package, we may find that that version
is not valid for that combination of <subdirectory, commit hash>,
but we should keep looking to see whether it is valid for a module
in some other subdirectory.
Fixes#47650.
Change-Id: Id48f590ce906a3d4cf4e82fc66137bf67613277d
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/548475
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
The pointer stored in mspan.largeType is an invalid pointer when
the span is an arena. We need to make sure that pointer isn't seen
by the garbage collector, as it might barf on it. Make sure we
zero the pointer using a uintptr write so the old value isn't picked
up by the write barrier.
The mspan.largeType field itself is in a NotInHeap struct, so a heap
scan won't find it. The only way we find it is when writing it, or
when reading it and putting it in a GC-reachable location. I think we
might need to audit the runtime to make sure these pointers aren't
being passed in places where the GC might (non-conservatively) scan a
stack frame it lives in. (It might be ok, many such places are either
systemstack or nosplit.)
Change-Id: Ie059d054e0da4d48a4c4b3be88b8e1e46ffa7d10
Reviewed-on: https://go-review.googlesource.com/c/go/+/548535
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 516860 accidentally changed the randomness
used in TempFile from 32 to 64 bits on 64-bit platforms,
meaning from 10 to 20 decimal bytes.
This is enough to cause problems in a few tests
because it makes temporary directory names just
a little bit longer.
Limit back down to 32 bits of randomness, which is fine,
and add a test to avoid repeating the mistake.
Fixes#64605.
Change-Id: I17b8c063d11d5c0a96a68b5e5f83c889a13bca77
Reviewed-on: https://go-review.googlesource.com/c/go/+/548635
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
This change restores the original logic in parseParameterList to what
it was before CL 538858 (which caused the issue), not in exact wording
but in identical semantic meaning, and thus restores this function to
a state that we know was working fine.
However, the change keeps the improved error reporting introduced by
CL 538858. To keep the code changes somewhat minimal as we are close
to RC1, the improved error handling exists twice for now even though
it could be factored out.
Fixes#64534.
Change-Id: I0b7bbf74d28811e8aae74f838f2d424f78af1f38
Reviewed-on: https://go-review.googlesource.com/c/go/+/548395
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In CL 547998 I relaxed cmd/go's parsing of version lines to allow it
to recognize clang versions with vendor prefixes. To prevent false-positives,
I added a check for a version 3-tuple following the word "version".
However, it appears that some releases of GCC use only a 2-tuple instead.
Updates #64423.
Fixes#64619.
Change-Id: I5f1d0881b6295544a46ab958c6ad4c2155cf51fe
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/548120
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
We can't delete all the outgoing edges and then add one back in, because
then we've lost the argument of any phi at the target. Instead, move
the important target to the front of the list and delete the rest.
This normally isn't a problem, because there is never normally a phi
at the target of a jump table. But this isn't quite true when in race
build mode, because there is a phi of the result of a bunch of raceread
calls.
The reason this happens is that each case is written like this (where e
is the runtime.eface we're switching on):
if e.type == $type.int32 {
m = raceread(e.data, m1)
}
m2 = phi(m1, m)
if e.type == $type.int32 {
.. do case ..
goto blah
}
so that if e.type is not $type.int32, it falls through to the default
case. This default case will have a memory phi for all the (jumped around
and not actually called) raceread calls.
If we instead did it like
if e.type == $type.int32 {
raceread(e.data)
.. do case ..
goto blah
}
That would paper over this bug, as it is the only way to construct
a jump table whose target is a block with a phi in it. (Yet.)
But we'll fix the underlying bug in this CL. Maybe we can do the
rewrite mentioned above later. (It is an optimization for -race mode,
which isn't particularly important.)
Fixes#64606
Change-Id: I6f6e3c90eb1e2638112920ee2e5b6581cef04ea4
Reviewed-on: https://go-review.googlesource.com/c/go/+/548356
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Callers should be using math/rand/v2.Uint64 instead,
but there are lots of linkname references to runtime.fastrand
in public code. If we break it all now, that will require people
to use //go:build tags to use rand/v2.Uint64 with Go 1.22
and keep using the linkname for earlier versions.
Instead, leave the linkname working and then we can remove
it in Go 1.24, at which point everyone should be able to use
math/rand/v2.Uint64 unconditionally.
Change-Id: I7287ca4f67c270b009562313661cc28a4c2219a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/548235
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
This is a partial revert of CL 483137.
CL 483137 started checking errors in postDecode, which is good. Now we
can catch more malformed pprof protos. However this made
TestEmptyProfile fail, so an early return was added when the profile was
"empty" (no samples).
Unfortunately, this was problematic. Profiles with no samples can still
be valid, but skipping postDecode meant that the resulting Profile was
missing values from the string table. In particular, net/http/pprof
needs to parse empty profiles in order to pass through the sample and
period types to a final output proto. CL 483137 broke this behavior.
internal/profile.Parse is only used in two places: in cmd/compile to
parse PGO pprof profiles, and in net/http/pprof to parse before/after
pprof profiles for delta profiles. In both cases, the input is never
literally empty (0 bytes). Even a pprof proto with no samples still
contains some header fields, such as sample and period type. Upstream
github.com/google/pprof/profile even has an explicit error on 0 byte
input, so `go tool pprof` will not support such an input.
Thus TestEmptyProfile was misleading; this profile doesn't need to
support empty input at all.
Resolve this by removing TestEmptyProfile and replacing it with an
explicit error on empty input, as upstream
github.com/google/pprof/profile has. For non-empty input, always run
postDecode to ensure the string table is processed.
TestConvertCPUProfileEmpty is reverted back to assert the values from
before CL 483137. Note that in this case "Empty" means no samples, not a
0 byte input.
Continue to allow empty files for PGO in order to minimize the chance of
last minute breakage if some users have empty files.
Fixes#64566.
Change-Id: I83a1f0200ae225ac6da0009d4b2431fe215b283f
Reviewed-on: https://go-review.googlesource.com/c/go/+/547996
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
To better diagnose bugs like this one in the future, I think
we should also refuse to use a C compiler if we can't identify
a sensible version for it. I did not do that in this CL because
I want it to be small and low-risk for possible backporting.
Fixes#64423.
Change-Id: I21e44fc55f6fcf76633e4fecf6400c226a742351
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/547998
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Before this CL, testEndToEnd only turns the relative PC to absolute PC
when pattern "off(PC)" is the suffix of an instruction. But there are
some instructions like:
ADR 10(PC), R10
it's also acceptable for the assembler while the pattern "off(PC)" is
not a suffix, which makes the test fail.
This CL fixes this issue by searching the pattern in the whole string
instead of only in the suffix.
Change-Id: I0cffedeb7b3c63abca7697671088cf993aff71ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/547235
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ruinan Sun <Ruinan.Sun@arm.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
gitRepo.statLocal reports tag and version information.
If we are statting a hash that corresponds to a tag, we need to add that tag
before calling statLocal so that it can be included in that information.
Fixes#53955.
Updates #56881.
Change-Id: I69a71428e6ed9096d4cb8ed1bb79531415ff06c1
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/547155
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
profileruntimelocks is new in CL 544195, but the name is deceptive. Even
with profileruntimelocks=0, runtime-internal locks are still profiled.
The actual difference is that call stacks are not collected. Instead all
contention is reported at runtime._LostContendedLock.
Rename this setting to runtimecontentionstacks to make its name more
aligned with its behavior.
In addition, for this release the default is profileruntimelocks=0,
meaning that users are fairly likely to encounter
runtime._LostContendedLock. Rename it to
runtime._LostContendedRuntimeLock in an attempt to make it more
intuitive that these are runtime locks, not locks in application code.
For #57071.
Change-Id: I38aac28b2c0852db643d53b1eab3f3bc42a43393
Reviewed-on: https://go-review.googlesource.com/c/go/+/547055
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Rhys Hiltner <rhys@justin.tv>
Use a test-local directory for GOCACHE in "cover_statements" script
test, as a workaround for issue 64014.
For the portion of this test that verifies that caching works
correctly, the cache should theoretically always behave
reliably/deterministically, however if other tests are concurrently
accessing the cache while this test is running, it can lead to cache
lookup failures, which manifest as a flaky failure. To avoid such
flakes, use a separate isolated GOCACHE for this test.
For #64014.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: Ia66798215a75b7c41188ed15920c17b73f40152a
Reviewed-on: https://go-review.googlesource.com/c/go/+/545235
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Better order in description of changes to go/types.
Move go/types section up so it's in alphabetical order again.
No changes to actual content.
Change-Id: If2f085b665b412489e5dfdba79b7f93598ff2785
Reviewed-on: https://go-review.googlesource.com/c/go/+/546359
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
This is a replay of CL 516859, after its rollback in CL 543895,
with big-endian systems fixed and the tests disabled on RISC-V
since the compiler is broken there (#64285).
ChaCha8 provides a cryptographically strong generator
alongside PCG, so that people who want stronger randomness
have access to that. On systems with 128-bit vector math
assembly (amd64 and arm64), ChaCha8 runs at about the same
speed as PCG (25% slower on amd64, 2% faster on arm64).
Fixes#64284.
Change-Id: I6290bb8ace28e1aff9a61f805dbe380ccdf25b94
Reviewed-on: https://go-review.googlesource.com/c/go/+/546020
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
To begin with, CL 545515 made the trace parser tolerant of
GoCreateSyscall having a P, but that was wrong. Because dropm trashes
the M's syscalltick, that case should never be possible. So the first
thing this change does is it rewrites the test that CL introduced to
expect a failure instead of a success.
What I'd misinterpreted as a case that should be allowed was actually
the same as the other issues causing #64060, which is that the parser
doesn't correctly implement what happens to Ps when a thread calls back
into Go on non-pthread platforms, and what happens when a thread dies
on pthread platorms (or more succinctly, what the runtime does when it
calls dropm).
Specifically, the GoDestroySyscall event implies that if any P is still
running on that M when it's called, that the P stops running. This is
what is intended by the runtime trashing the M's syscalltick; when it
calls back into Go, the tracer models that thread as obtaining a new P
from scratch.
Handling this incorrectly manifests in one of two ways.
On pthread platforms, GoDestroySyscall is only emitted when a C thread
that previously called into Go is destroyed. However, that thread ID can
be reused. Because we have no thread events, whether it's the same
thread or not is totally ambiguous to the tracer. Therefore, the tracer
may observe a thread that previously died try to start running with a
new P under the same identity. The association to the old P is still
intact because the ID is the same, and the tracer gets confused -- it
appears as if two Ps are running on the same M!
On non-pthread platforms, GoDestroySyscall is emitted on every return to
C from Go code. In this case, the same thread with the same identity is
naturally going to keep calling back into Go. But again, since the
runtime trashes syscalltick in dropm, it's always going to acquire a P
from the tracer's perspective. But if this is a different P than before,
just like the pthread case, the parser is going to get confused, since
it looks like two Ps are running on the same M!
The case that CL 545515 actually handled was actually the non-pthread
case, specifically where the same P is reacquired by an M calling back
into Go. In this case, if we tolerate having a P, then what we'll
observe is the M stealing its own P from itself, then running with it.
Now that we know what the problem is, how do we fix it? This change
addresses the problem by emitting an extra event when encountering a
GoDestroySyscall with an active P in its context. In this case, it emits
an additional ProcSteal event to steal from itself, indicating that the
P stopped running. This removes any association between that M and that
P, resolving any ambiguity in the tracer.
There's one other minor detail that needs to be worked out, and that's
what happens to any *real* ProcSteal event that stole the P we're now
emitting an extra ProcSteal event for. Since, this event is going to
look for an M that may have moved on already and the P at this point is
already idle. Luckily, we have *exactly* the right fix for this. The
handler for GoDestroySyscall now moves any active P it has to the
ProcSyscallAbandoned state, indicating that we've lost information about
the P and that it should be treated as already idle. Conceptually this
all makes sense: this is a P in _Psyscall that has been abandoned by the
M it was previously bound to.
It's unfortunate how complicated this has all ended up being, but we can
take a closer look at that in the future.
Fixes#64060.
Change-Id: Ie9e6eb9cf738607617446e3487392643656069a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/546096
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Go 1.21.1 and Go 1.22 have ceased working around an issue with Linux
kernel defaults for transparent huge pages that can result in excessive
memory overheads. (https://bugzilla.kernel.org/show_bug.cgi?id=93111)
Many Linux distributions disable huge pages altogether these days, so
this problem isn't quite as far-reaching as it used to be. Also, the
problem only affects Go programs with very particular memory usage
patterns.
That being said, because the runtime used to actively deal with this
problem (but with some unpredictable behavior), it's preventing users
that don't have a lot of control over their execution environment from
upgrading to Go beyond Go 1.20.
This change adds a GODEBUG to smooth over the transition. The GODEBUG
setting disables transparent huge pages for all heap memory on Linux,
which is much more predictable than restoring the old behavior.
Fixes#64332.
Change-Id: I73b1894337f0f0b1a5a17b90da1221e118e0b145
Reviewed-on: https://go-review.googlesource.com/c/go/+/547475
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The chunked transfer encoding adds some overhead to
the content transferred. When writing one byte per
chunk, for example, there are five bytes of overhead
per byte of data transferred: "1\r\nX\r\n" to send "X".
Chunks may include "chunk extensions",
which we skip over and do not use.
For example: "1;chunk extension here\r\nX\r\n".
A malicious sender can use chunk extensions to add
about 4k of overhead per byte of data.
(The maximum chunk header line size we will accept.)
Track the amount of overhead read in chunked data,
and produce an error if it seems excessive.
Fixes#64433
Fixes CVE-2023-39326
Change-Id: I40f8d70eb6f9575fb43f506eb19132ccedafcf39
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2076135
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/547335
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
These tests represent two patterns of usage, found in Google-internal
tests, that deadlocked after CL 506755.
TestConcurrentRun is a minor variation on TestParallelSub, with the
additional expectation that the concurrent calls to Run (without
explicit calls to Parallel) proceed without blocking. It replaces
TestParallelSub.
TestParentRun is similar, but instead of calling Run concurrently it
calls Run from within the subtest body. It almost certainly represents
an accidental misuse of T.Run, but since that pattern used to run to
completion we don't want to break it accidentally. (Perhaps it should
be diagnosed with a vet check instead?)
While we are testing concurrency, this also cleans up
TestConcurrentCleanup to use a clearer synchronization pattern.
Fixes#64402.
Change-Id: I14fc7e7085a994c284509eac28190c3a8feb04cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/546019
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
This was released in 1.21, release noted in CL 524675.
(I think it was missed originally and then and backported,
but then somehow incorrectly made it into the 1.22 dragnet.)
Change-Id: I45f3182f14f77f8b92a3b7d5ef0011b71fd3c176
Reviewed-on: https://go-review.googlesource.com/c/go/+/546675
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Bypass: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Update the go doc for linker flags. Remove flags that no longer
exist. Also remove flags that are intended for debugging the
linker from user docs. Add -aslr to the doc.
The -n flag does nothing except print a nearly useless message on
XCOFF linking. Deprecate it.
Fixes#64476.
Change-Id: I518c9c6cc009eae50b7c11308348524ad6a62b69
Reviewed-on: https://go-review.googlesource.com/c/go/+/546615
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The code generation on riscv64 will currently result in incorrect
assembly when a 32 bit integer is right shifted by an amount that
exceeds the size of the type. In particular, this occurs when an
int32 or uint32 is cast to a 64 bit type and right shifted by a
value larger than 31.
Fix this by moving the SRAW/SRLW conversion into the right shift
rules and removing the SignExt32to64/ZeroExt32to64. Add additional
rules that rewrite to SRAIW/SRLIW when the shift is less than the
size of the type, or replace/eliminate the shift when it exceeds
the size of the type.
Add SSA tests that would have caught this issue. Also add additional
codegen tests to ensure that the resulting assembly is what we
expect in these overflow cases.
Fixes#64285
Change-Id: Ie97b05668597cfcb91413afefaab18ee1aa145ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/545035
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: M Zhuo <mzh@golangcn.org>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
The GoSyscallBegin event is a signal for both the P and the G to enter a
syscall state for the trace parser. (Ps can't have their own event
because it's too hard to model. As soon as the P enters _Psyscall it can
get stolen out of it.) But there's a window in time between when that
event is emitted and when the P enters _Psyscall where the P's status
can get emitted. In this window the tracer will emit the wrong status:
Running instead of Syscall. Really any call into the tracer could emit a
status event for the P, but in this particular case it's when running a
safepoint function that explicitly emits an event for the P's status.
The fix is straightforward. The source-of-truth on syscall status is the
G's status, so the function that emits the P's status just needs to
check the status of any G attached to it. If it's in _Gsyscall, then the
tracer should emit a Syscall status for the P if it's in _Prunning.
Fixes#64318.
Change-Id: I3b0fb0d41ff578e62810b04fa5a3ef73e2929b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/546025
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The parallel subtests are themselves removed from the running map
while they are blocked on calls to t.Parallel, so it is misleading to
log their parents as if they are running when we know they cannot be
making any kind of meaningful progress.
Fixes#64404.
Change-Id: Iaad11d5d4f4c86d775d36e5285c49629dccddd74
Reviewed-on: https://go-review.googlesource.com/c/go/+/546018
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Previously, its value was unset (NoPos), but the correct
value is a point after the signature (FuncType.End) and
before the body.
Also, fix a bug in Scope.Innermost whereby it would return
the wrong (outer) scope when the query position was in
the FuncType portion of a Func{Decl,Lit}.
The fix is to set the scope's pos/end to those of the
complete Func{Decl,Lit}. This is now documented at
Info.Scopes, along with other missing information.
Also, fix a bug in the go/types (but not types2) scope
test, in which comments were discarded by the parser,
causing the entire test to be a no-op (!).
Also, make failures of TestScopeLookupParent more
informative.
Also, add a release note about the change in behavior.
Fixes#64292Fixes#64295
Change-Id: Ib681f59d1b0b43de977666db08302d7524d3305f
Reviewed-on: https://go-review.googlesource.com/c/go/+/544035
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Robert Griesemer <gri@google.com>
As per #62352 the invocation of vmmap may fail (very rarely) due to
a temporary lack of resources on the test runner machine. This PR
allows for retrying the invocation a fixed number of times before
giving up. This is because we suspect the failure is due to
sensible to retry.
Fixes: #62352
Change-Id: I51aa66b949753d8127cc307181b6ef32e91d5b05
Reviewed-on: https://go-review.googlesource.com/c/go/+/545935
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The Go 1.22 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
Generated with:
go install golang.org/x/build/cmd/updatestd@latest
go install golang.org/x/tools/cmd/bundle@latest
updatestd -goroot=$(pwd) -branch=master
For #36905.
Change-Id: I76525261b9a954ed21a3bd3cb6c4a12e6c031d80
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-linux-amd64-longtest,gotip-linux-386-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/546055
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
ReadMemStats has a few assertions it makes about the consistency of the
stats it's about to produce. Specifically, how those stats line up with
runtime-internal stats. These checks are generally useful, but crashing
just because some stats are wrong is a heavy price to pay.
For a long time this wasn't a problem, but very recently it became a
real problem. It turns out that there's real benign skew that can happen
wherein sysmon (which doesn't synchronize with a STW) generates a trace
event when tracing is enabled, and may mutate some stats while
ReadMemStats is running its checks.
Fix this by synchronizing with both sysmon and the tracer. This is a bit
heavy-handed, but better that than false positives.
Also, put the checks behind a debug mode. We want to reduce the risk of
backporting this change, and again, it's not great to crash just because
user-facing stats are off. Still, enable this debug mode during the
runtime tests so we don't lose quite as much coverage from disabling
these checks by default.
Fixes#64401.
Change-Id: I9adb3e5c7161d207648d07373a11da8a5f0fda9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/545277
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
The type of the data pointer field of a slice should be a pointer
to the element type, not a *uint8.
This ensures that the SSA value representing the slice's data pointer
can be spilled to the stack slot for the corresponding argument.
Before this change the types didn't match so we ended up spilling the
argument to an autotmp instead of to the dedicated argument slot.
Fixes#64414
Change-Id: I09ee39e93f05aee07e3eceb14e39736d7fd70a33
Reviewed-on: https://go-review.googlesource.com/c/go/+/545357
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
On Darwin, the ptrace syscall is called in ptrace1, which then be
called in ptrace. This allows ptrace1 be disabled on iOS (by
implementing ptrace differently). But we can also achieve this by
adding a conditional directly in ptrace. This reduces stack usage
with -N -l, while keeping ptrace disabled on iOS.
For #64113.
Change-Id: I89d8e317e77352fffdbb5a25ba21ee9cdf2e1e20
Reviewed-on: https://go-review.googlesource.com/c/go/+/545276
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
bugs:
* drop unused labels
* drop the reproduce checkbox:
it's not a strong signal and introduces clutter in github as a task list
* link go.dev/play
govuln:
* use correct label
* ask for version of the tool
* link go.dev/play
telemetry:
* align title with purpose
Change-Id: Id7dd876e518c75dc22e9aec43d9af6e18af088fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/544775
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
The multiple issue templates pre-populate the issue title with a prefix
that Go issues customarily have. The "affected/package" phrase is short
for "the import path of the affected package". Let's try simplifying it
to just "import/path", and also include "issue title" to make the title
a more representative template of what the final title should look like.
Updates #29839.
Change-Id: I9736d24cf3d0a51536ac13dd07dd189fb51da021
Reviewed-on: https://go-review.googlesource.com/c/go/+/544556
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
The exitsyscall path, since the introduction of the new execution
tracer, stores a just little bit more data in the exitsyscall stack
frame, causing a build failure from exceeding the nosplit limit with
'-N -l' set on all packages (like Delve does).
One of the paths through which this fails is "throw" from wirep, called
by a callee of exitsyscall. By switching to the systemstack on this
path, we can avoid hitting the nosplit limit, fixing the build. It's
also not totally unreasonable to switch to the systemstack for the
throws in this function, since the function has to be nosplit anyway. It
gives the throw path a bit more wiggle room to dump information than it
otherwise would have.
Fixes#64113.
Change-Id: I56e94e40614a202b8ac2fdc8b8b731493b74e5d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/544535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is required by traceThreadDestroy, though it's not strictly
necessary in this case. The requirement to hold sched.lock comes from
the assumption that traceThreadDestroy is getting called when the thread
leaves the tracer's view, but in this case the extra m that dropm is
dropping never leaves the allm list. Nevertheless, traceThreadDestroy
requires it just as a safety measure, and that's reasonable. dropm is
generally rare on pthread platforms, so the extra lock acquire over this
short critical section (and only when tracing is enabled) is fine.
Change-Id: Ib631820963c74f2f087d14a0067d0441d75d6785
Reviewed-on: https://go-review.googlesource.com/c/go/+/544396
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently the wakeableSleep lock is placed just after timers in the
ranking, but it turns out the timers lock can never be held over a timer
func, so that's wrong. Meanwhile, wakeableSleep can acquire sched.lock.
wakeableSleep, as it turns out, doesn't have any dependencies -- it's
always acquired in a (mostly) regular goroutine context.
Change-Id: Icc8ea76a8b309fbaf0f02215f16e5f706d49cd95
Reviewed-on: https://go-review.googlesource.com/c/go/+/544395
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
semrelease may unblock a goroutine, but the act of unblocking a
goroutine may emit an event, which in turn may try to acquire trace.lock
again.
It's safe to release trace.lock in readTrace0 for this because all of
the state (one variable) it uses under the lock will be recomputed when
it reacquires the lock. There's also no other synchronization
requirement to hold trace.lock. This is just a mistake.
Change-Id: Iff6c6b02efa298ebed8e60cdf6539ec161d5ec48
Reviewed-on: https://go-review.googlesource.com/c/go/+/544178
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
There's a conceptual cycle between traceStackTable.lock and
allocation-related locks, but it can't happen in practice because the
caller guarantees that there are no more writers to the table at the
point that dump is called.
But if that's true, then the lock isn't necessary at all. It would be
difficult to model this quiesence in the lockrank mode, so just don't
hold the lock and expand the documentation of the dump method.
Change-Id: Id4db61363f075b7574135529915e8bd4f4f4c082
Reviewed-on: https://go-review.googlesource.com/c/go/+/544177
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Unwind info in .xdata was being parsed incorrectly, causing targetOff to
be incorrect and miss finding data in .xdata that it should have found.
This causes a linker issue when using the MinGW MSVCRT compiler.
Contains several fixes based on the exception handling docs: the offset
used to get the number of unwind codes, the calculation of the target
offset based on the dynamic size of the unwind data, and the
UNW_FLAG_CHAININFO flag's value.
Fixes#64200
Change-Id: I6483d921b2bf8a2512a95223bf3c8ce8bc63dc4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/544415
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
When I initially added the wasm code for these ops I did not saw that
wasm actually has the Cas operations implemented, although they are
merely pointer assignments since wasm is single threaded.
Now with a generic implementation for And/Or we can add wasm to the
build tags.
For #61395
Change-Id: I997dc90477c772882d6703df1b795dfc0d90a699
GitHub-Last-Rev: 92736a6e34
GitHub-Pull-Request: golang/go#64300
Reviewed-on: https://go-review.googlesource.com/c/go/+/544116
Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
KMCTR encoding arguments incorrect way, which leading illegal instruction wherver we call KMCTR instruction.IBM z13 machine test's TestAESGCM test using gcmASM implementation, which uses KMCTR instruction to encrypt using AES in counter mode and the KIMD instruction for GHASH. z14+ machines onwards uses gcmKMA implementation for the same.
Fixes#63387
Change-Id: I86aeb99573c3f636a71908c99e06a9530655aa5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/535675
Reviewed-by: Vishwanatha HD <vishwanatha.hd@ibm.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Variables in functions implemented in assembly should have the
same names as when they were defined. The names of some variables
in asan-related assembly functions do not follow the above rule,
which will cause the runtime test to fail. This CL fixes this issue.
Updates #64257
Change-Id: I261f4db807d25e460513ef1c92cd1b707cdd1a16
Reviewed-on: https://go-review.googlesource.com/c/go/+/543837
Run-TryBot: Fannie Zhang <Fannie.Zhang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Currently we dump text traces to the build log on failure
unconditionally, but this may cause the old infrastructure's builds'
logs to get truncated. Avoid that by setting a threshold on the maximum
size of the text trace we're willing to dump.
We don't need this workaround on the new infrastructure -- logs don't
get truncated there.
Change-Id: I0f50f50bb4b90f87250b673fbe56f48235325610
Reviewed-on: https://go-review.googlesource.com/c/go/+/544216
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
While investigating #60083, I found a couple of bugs (notably #61034)
that had slipped through code review in part because the concurrency
patterns used in the testing package were too complex for me to fully
reason about. This change adjusts those patterns to be more in line
with current idioms, and to reduce the number of special cases that
depend on details that should be orthogonal. (For example: the details
of how we invoke the Cleanup functions should not depend on whether
the test happened to run any parallel subtests.)
In the process, this change fixes a handful of bugs:
- Concurrent calls to Run (explicitly allowed by TestParallelSub)
could previously drive the testcontext.running count negative,
causing the number of running parallel tests to exceed the -parallel
flag.
- The -failfast flag now takes effect immediately on failure. It no
longer delays until the test finishes, and no longer misses failures
during cleanup (fixing #61034).
- If a Cleanup function calls runtime.Goexit (typically via t.FailNow)
during a panic, Cleanup functions from its parent tests are no
longer skipped and buffered logs from its parent tests are now
flushed.
- The time reported for a test with subtests now includes the time spent
running those subtests, regardless of whether they are parallel.
(Previously, non-parallel subtests were included but parallel subtests
were not.)
- Calls to (*B).Run in iterations after the first are now diagnosed
with a panic. (This diagnoses badly-behaved benchmarks: if Run is
called during the first iteration, no subsequent iterations are
supposed to occur.)
Fixes#61034.
Change-Id: I3797f6ef5210a3d2d5d6c2710d3f35c0219b02ea
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-amd64-longtest-race,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/506755
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The v2 execution tracer has a rudimentary deadlock detector, but it's
based on an arbitrary threshold that an actually get hit even if there's
no deadlock. This ends up breaking tests sometimes, and it would be bad
if this just appeared in production logs.
Put this 'deadlock detector' behind a flag.
For #55317.
Change-Id: I286f0c05b3ac9600f4f2f9696065cac8bbd25f00
Reviewed-on: https://go-review.googlesource.com/c/go/+/544235
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently entersyscall_gcwait always emits a ProcStop event. Most of the
time, this is correct, since the thread that just put the P into
_Psyscall is the same one that is putting it into _Pgcstop. However it's
possible for another thread to steal the P, start running a goroutine,
and then enter another syscall, putting the P back into _Psyscall. In
this case ProcStop is incorrect; the P is getting stolen. This leads to
broken traces.
Fix this by always emitting a ProcSteal event from entersyscall_gcwait.
This means that most of the time a thread will be 'stealing' the proc
from itself when it enters this function, but that's theoretically fine.
A ProcSteal is really just a fancy ProcStop.
Well, it would be if the parser correctly handled a self-steal. This is
a minor bug that just never came up before, but it's an update order
error (the mState is looked up and modified, but then it's modified
again at the end of the function to match newCtx). There's really no
reason a self-steal shouldn't be allowed, so fix that up and add a test.
Change-Id: Iec3d7639d331e3f2d127f92ce50c2c4a7818fcd3
Reviewed-on: https://go-review.googlesource.com/c/go/+/544215
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
CL 535080 incorrectly links the unclear mention of Unwrap to the func
Unwrap in doc for errors.Is and errors.As
Instead we clarify that "Unwrap" is a reference
to the "Unwrap() error" or "Unwrap() []error" methods, not to the
"Unwrap(error) error" function which is also available in the package.
Change-Id: I8314993932e1e7a2dc77400f74d81f3a8aa891de
Reviewed-on: https://go-review.googlesource.com/c/go/+/538155
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: qiulaidongfeng <2645477756@qq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This is a nice-to-have that's now straightforward to do with the new
trace format. This change adds a new query variable passed to the
/trace endpoint called "view," which indicates the type of view to
use. It is orthogonal with task-related views.
Unfortunately a goroutine-based view isn't included because it's too
likely to cause the browser tab to crash.
For #60773.
For #63960.
Change-Id: Ifbcb8f2d58ffd425819bdb09c586819cb786478d
Reviewed-on: https://go-review.googlesource.com/c/go/+/543695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
This change implements support for the trace?focustask=<taskid> endpoint
in the trace tool for v2 traces.
Note: the one missing feature in v2 vs. v1 is that the "irrelevant" (but
still rendered) events are not grayed out. This basically includes
events that overlapped with events that overlapped with other events
that were in the task time period, but aren't themselves directly
associated. This is probably fine -- the UI already puts a very obvious
focus on the period of time the selected task was running.
For #60773.
For #63960.
Change-Id: I5c78a220ae816e331b74cb67c01c5cd98be40dd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/543596
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change adds support for the trace?goid=<goid> endpoint to the trace
tool for v2 traces.
In effect, this change actually implements a per-goroutine view. I tried
to add a link to the main page to enable a "view by goroutines" view
without filtering, but the web trace viewer broke the browser tab when
there were a few hundred goroutines. The risk of a browser hang probably
isn't worth the cases where this is nice, especially since filtering by
goroutine already works. Unfortunate, but c'est l'vie. Might be worth
revisiting if we change out the web viewer in the future.
For #60773.
For #63960.
Change-Id: I8e29f4ab8346af6708fd8824505c30f2c43db796
Reviewed-on: https://go-review.googlesource.com/c/go/+/543595
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
This code will be useful for the new tracer, and there's no need to
duplicate it. This change copies it to internal/trace/traceviewer, adds
some comments, and renames it to TimeHistogram.
While we're here, let's get rid of the unused String method which has a
comment talking about how awful the rendering is.
Also, let's get rid of uses of niceDuration. We'd have to bring it
with us in the move and I don't think it's worth it. The difference
between the default time.Duration rendering and the niceDuration
rendering is usually a few extra digits of precision. Yes, it's noisier,
but AFAICT it's not substantially worse. It doesn't seem worth the new
API, even if it's just internal. We can also always bring it back later.
For #60773.
For #63960.
Change-Id: I795f58f579f1d503c540c3a40bed12e52bce38e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/542001
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
For v1 traces, cmd/trace contains code for analyzing tasks separately
from the goroutine analysis code present in internal/trace. As I started
to look into porting that code to v2 traces, I noticed that it wouldn't
be too hard to just generalize the existing v2 goroutine summary code to
generate exactly the same information.
This change does exactly that.
For #60773.
For #63960.
Change-Id: I0cdd9bf9ba11fb292a9ffc37dbf18c2a6a2483b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/542076
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The v2 trace parser currently handles task inheritance and region task
association incorrectly. It assumes that a TaskID of 0 means that there
is no task. However, this is only true for task events. A TaskID of 0
means that a region gets assigned to the "background task." The parser
currently has no concept of a "background task."
Fix this by defining the background task as task ID 0 and redefining
NoTask to ^uint64(0). This aligns the TaskID values more closely with
other IDs in the parser and also enables disambiguating these two cases.
For #60773.
For #63960.
Change-Id: I09c8217b33b87c8f8f8ea3b0203ed83fd3b61e11
Reviewed-on: https://go-review.googlesource.com/c/go/+/543019
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
This change adds support for the pprof endpoints to cmd/trace/v2.
In the process, I realized we need to pass the goroutine summaries to
more places, and previous CLs had already done the goroutine analysis
during cmd/trace startup. This change thus refactors the goroutine
analysis API once again to operate in a streaming manner, and to run
at the same time as the initial trace parsing. Now we can include it in
the parsedTrace type and pass that around as the de-facto global trace
context.
Note: for simplicity, this change redefines "syscall" profiles to
capture *all* syscalls, not just syscalls that block. IIUC, this choice
was partly the result of a limitation in the previous trace format that
syscalls don't all have complete durations and many short syscalls are
treated as instant. To this end, this change modifies the text on the
main trace webpage to reflect this change.
For #60773.
For #63960.
Change-Id: I601d9250ab0849a0bfaef233fd9b1e81aca9a22a
Reviewed-on: https://go-review.googlesource.com/c/go/+/541999
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The last change made the MMU rendering code common and introduced a new
API, but it was kind of messy. Part of the problem was that some of the
Javascript in the template for the main page referred to specific
endpoints on the server.
Fix this by having the Javascript access the same endpoint but with a
different query variable. Now the Javascript code doesn't depend on
specific endpoints, just on query variables for the current endpoint.
For #60773.
For #63960.
Change-Id: I1c559d9859c3a0d62e2094c9d4ab117890b63b31
Reviewed-on: https://go-review.googlesource.com/c/go/+/541259
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change moves the MMU HTTP handlers and functionality into the
traceviewer package, since unlike the goroutine pages the vast majority
of that functionality is identical between v1 and v2. This change
involves some refactoring so that callers can plug in their own mutator
utilization computation functions (which is the only point of difference
between v1 and v2). The new interface isn't especially nice, but part of
the problem is the MMU handlers depend on specific endpoints to exist. A
follow-up CL will clean this up a bit.
Like the previous CL did for goroutine analysis, modify the v2 mutator
utilization API to accept a slice of trace events. Again, we might as
well reuse what was already parsed and will be needed for other
purposes. It also simplifies the API slightly.
For #60773.
For #63960.
Change-Id: I6c21ec8d1bf7e95eff5363d0e0005c9217fa00e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/541258
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
This is a complete fork and most of a rewrite of the goroutine analysis
pages for v2 traces. It fixes an issue with the old page where GC time
didn't really make any sense, generalizes the page and breaks things
down further, and adds clarifying text.
This change also modifies the SummarizeGoroutines API to not stream the
trace. This is unfortunate, but we're already reading and holding the
entire trace in memory for the trace viewer. We can revisit this
decision in the future. Also, we want to do this now because the
GoroutineSummary holds on to pointers to events, and these events will
be used by the user region and user task analyses. While tracev2 events
are values and they should be equivalent no matter how many times we
parse a trace, this lets us reference the event in the slice directly.
For #60773.
For #63960.
Fixes#62443.
Change-Id: I1c5ab68141869378843f4f2826686038e4533090
Reviewed-on: https://go-review.googlesource.com/c/go/+/541257
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently goroutine names are determined (for v2 traces) by
internal/tracev/2.Event.Stack, but this is wrong in general. For
example, if we end up seeing a transition from GoNotExist->GoRunnable
(goroutine creation) then we're taking the stack from the creator, not
the created goroutine (which is what we're naming at that point).
Use the StateTransition.Stack instead. This is always the correct one to
use because we're always naming the goroutine that the state transition
is for.
Change-Id: I3fc7c8e4f85dfee3802d666c0c091b6953c7d6cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/544317
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Add runtime-internal locks to the mutex contention profile.
Store up to one call stack responsible for lock contention on the M,
until it's safe to contribute its value to the mprof table. Try to use
that limited local storage space for a relatively large source of
contention, and attribute any contention in stacks we're not able to
store to a sentinel _LostContendedLock function.
Avoid ballooning lock contention while manipulating the mprof table by
attributing to that sentinel function any lock contention experienced
while reporting lock contention.
Guard collecting real call stacks with GODEBUG=profileruntimelocks=1,
since the available data has mixed semantics; we can easily capture an
M's own wait time, but we'd prefer for the profile entry of each
critical section to describe how long it made the other Ms wait. It's
too late in the Go 1.22 cycle to make the required changes to
futex-based locks. When not enabled, attribute the time to the sentinel
function instead.
Fixes#57071
This is a roll-forward of https://go.dev/cl/528657, which was reverted
in https://go.dev/cl/543660
Reason for revert: de-flakes tests (reduces dependence on fine-grained
timers, correctly identifies contention on big-endian futex locks,
attempts to measure contention in the semaphore implementation but only
uses that secondary measurement to finish the test early, skips tests on
single-processor systems)
Change-Id: I31389f24283d85e46ad9ba8d4f514cb9add8dfb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/544195
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Rhys Hiltner <rhys@justin.tv>
Run-TryBot: Rhys Hiltner <rhys@justin.tv>
Currently StateTransition.Stack is only set for the GoCreate case,
because there are two stacks and we need to distinguish them. But the
docs for StateTransition.Stack say that that stack always references the
resource that is transitioning. There are quite a few cases where
Event.Stack is actually the appropriate stack to for
StateTransition.Stack, but in these cases it's left empty, and the
caller just needs to understand which one to look at. This isn't great.
Forward Event.Stack to StateTransition.Stack whenever Event.Stack also
refers to the resource experiencing the state transition.
Change-Id: Ie43fc6036f2712c7982174d5739d95765312dfcc
Reviewed-on: https://go-review.googlesource.com/c/go/+/544316
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change refactors the cmd/trace package and adds most of the support
for v2 traces.
The following features of note are missing in this CL and will be
implemented in follow-up CLs:
- The focustask filter for the trace viewer
- The taskid filter for the trace viewer
- The goid filter for the trace viewer
- Pprof profiles
- The MMU graph
- The goroutine analysis pages
- The task analysis pages
- The region analysis pages
This CL makes one notable change to the trace CLI: it makes the -d flag
accept an integer to set the debug mode. For old traces -d != 0 works
just like -d. For new traces -d=1 means the high-level events and -d=2
means the low-level events.
Thanks to Felix Geisendörfer (felix.geisendoerfer@datadoghq.com) for
doing a lot of work on this CL; I picked this up from him and got a
massive headstart as a result.
For #60773.
For #63960.
Change-Id: I3626e22473227c5980134a85f1bb6a845f567b1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/542218
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Back in the day, Wait used to accept options argument.
CL 4962042 fixed the issue of setting process.done flag when WNOHANG
option was used.
Later, CL 5688046 removed options argument from Wait, but did not remove
pid1 != 0 check which was meant to be used with WNOHANG only.
Remove the check, which is useless and also confusing.
Change-Id: I73b9ef4a0dbe35466e659ca58b896d515ba86d02
Reviewed-on: https://go-review.googlesource.com/c/go/+/543736
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
order.go ensures expressions that are passed to the runtime by address
are in fact addressable. However, in the case of local variables, if the
variable hasn't already been marked as addrtaken, then taking its
address here will effectively prevent the variable from being converted
to SSA form.
Instead, it's better to just copy the variable into a new temporary,
which we can pass by address instead. This ensures the original variable
can still be converted to SSA form.
Fixes#63332.
Change-Id: I182376d98d419df8bf07c400d84c344c9b82c0fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/541715
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
While working on CL 528798, I found out that sys.PidFD field (added
in CL 520266) is not filled in when CLONE_NEWUSER is used.
This happens because the code assumed that the parent and the child
run in the same memory space. This assumption is right only when
CLONE_VM is used for clone syscall, and the code only sets CLONE_VM
when CLONE_NEWUSER is not used.
Fix this, and add a test case (which fails before the fix).
Updates #51246.
Change-Id: I805203c1369cadd63d769568b132a9ffd92cc184
Reviewed-on: https://go-review.googlesource.com/c/go/+/542698
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
This patch revises the compiler's "-m=2" status messages related to
inlining. The "can inline" remarks will continue to use the same
format, but the remarks when a specific call site is inlined will be
changed to refer to the score used; before we had
runtime/traceback.go:1131:28: inlining call to gotraceback
runtime/traceback.go:1183:25: inlining call to readgstatus
and with GOEXPERIMENT=newinliner the new messages will be:
runtime/traceback.go:1131:28: inlining call to gotraceback with score 62
runtime/traceback.go:1183:25: inlining call to readgstatus with score 9
Change-Id: Ia86cf5351d29eda64a5426ca0a2a2ec0c2900d81
Reviewed-on: https://go-review.googlesource.com/c/go/+/540775
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The function passed to OnceFunc/OnceValue/OnceValues may transitively
keep more allocations alive. As the passed function is guaranteed to be
called at most once, it is safe to drop it after the first call is
complete. This avoids keeping the passed function (and anything it
transitively references) alive until the returned function is GCed.
Change-Id: I2faf397b481d2f693ab3aea8e2981b02adbc7a21
Reviewed-on: https://go-review.googlesource.com/c/go/+/481515
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: qiulaidongfeng <2645477756@qq.com>
Some small changes to help reduce compile time for function flags
computation. The current implementation of panic path detection adds
an entry to a map for every node in the function, which is wasteful
(and shows up in cpu profiles). Switch to only adding entries where
they are useful. This is especially important for functions with large
map literals and other constructs with many non-statement nodes.
Change-Id: I9cfb2cd1cbf480f21298e6102aa99e2d77219f3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/539696
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fix a bug in the code that analyzes how function parameters are used,
which wasn't properly handling certain types of closures. The code
in question has support for deriving flags for a given parameter based
on whether it is passed to a call. Example:
func foo(f1 func(int)) {
bar(32, f1)
}
func bar(x int, f2 func()) {
f2(x)
}
When analyzing "bar", we can derive the "FeedsIndirectCall" flag for
parameter "f1" by virtue of the fact that it is passed directly to
"bar", and bar's corresponding parameter "f2" has the flag set. For
a more complex example such as
func foo(f1 func(int)) func() int {
return func(q int) int { <<-- HERE
bar(99, f1)
return q
}
}
func bar(x int, f2 func()) {
f2(x)
}
The heuristics code would panic when examining the closure marked above
due to the fact that the call to "bar" was passing an ir.Name with class
PPARAM, but no such param was present in the enclosing function.
Change-Id: I30436ce716b51bfb03e42e7abe76a4514e6b9285
Reviewed-on: https://go-review.googlesource.com/c/go/+/539320
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These tests are checking the output of test functions that call the
Helper methods. However, they were reaching into package internals
instead of running those test functions as actual tests.
That not only produced significant differences in formatting (such as
indentation for subtests), but also caused test flags such as
"-failfast" passed for the overall test run to interfere with the
output formatting.
Now, we run the test functions as real tests in a subprocess,
so that we get the real output and formatting of those tests.
This makes the tests not only more realistic, but also less
sensitive to otherwise-irrelevant implementation details
(such as the names and signatures of unexported types and
functions in the testing package).
Fixes#61016.
Change-Id: I646fbbd7cfeb00382054677f726c05fc9d35d0dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/506955
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When running the code to compute function properties that feed
inlining heuristics, the existing heuristics implementation makes
fairly extensive use of ir.StaticValue and ir.Reassigned to sharpen
the analysis. These calls turn out to cause a significant compile time
increase, due to the fact that each call can potentially walk every
node in the IR for the function. To help with this problem, switch the
heuristics code over to using the new "batch mode" reassignment helper
added in the previous CL.
Change-Id: Ib15a62416134386e34b7cfa1130a4b413a37b225
Reviewed-on: https://go-review.googlesource.com/c/go/+/537977
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Add a new helper type 'ReassignOracle', useful for doing "batch mode"
reassignment analysis, e.g. deciding whether a given ir.Name or (chain
of connected names) has a single definition and is never reassigned.
The intended usage model is for clients to create/initialize a
ReassignOracle for a given function, then make a series of queries
using it (with the understanding that changing/mutating the func body
IR can invalidate the info cached in the oracle). This oracle is
intended to provide the same sort of analysis that ir.StaticValue and
ir.Reassigned carry out, but at a much reduced cost in compile
time.
Notes:
- the new helper isn't actually used for anything useful in this
patch; it will be hooked into the inline heuristics code as part of
a subsequent CL.
- this is probably not an ideal long-term solution; it would be better
to switch to a scheme based a flag on ir.Name, as opposed to a
side table.
Change-Id: I283e748e440a9f595df495f6aa48ee9c498702d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/539319
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Apparently, on Windows, throwing an exception on a non-system-
allocated crash stack causes EXCEPTION_STACK_OVERFLOW and hangs
the process (see issue #63938). Disable crash stack for now, which
gets us back the the behavior of Go 1.21.
Fixes#63938.
Change-Id: I4c090315b93b484e756b242f0de7a9e02f199261
Reviewed-on: https://go-review.googlesource.com/c/go/+/543996
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
As of Go 1.19, runtime.GOROOT() reports the empty string if the binary
was built with -trimpath. cmd/go/internal/cfg uses the path of the go
command executable to reverse-engineer the correct GOROOT setting,
but that means that cmd/go's "GOPATH set to GOROOT" warning needs to
use cfg.GOROOT instead of runtime.GOROOT().
In addition, if we fail to find the GOROOT then there is no point in
complaining about GOPATH also being empty: the missing GOROOT will stop
everything right away anyway, so there is no point confusing the user
with an additional warning about GOPATH.
Updates #51461.
Updates #18678.
Updates #3207.
Change-Id: Id7d0f4dc2f229c202dfda4e6e8af5dea909bb16f
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/543955
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently if morestack on g0 happens the wasm runtime prints
"RuntimeError: memory access out of bounds", which is quite misleading.
By switching to a crash stack we can get better stacktraces
for the error.
There is no way to automate tests for this feature on wasm, since
TestG0StackOverflow relies on spawning a subprocess which is not
supported by the wasm port.
The way I got this tested manually is to comment everything in
TestG0StackOverflow, leaving just runtime.G0StackOverflow().
Then it is a matter of invoking the test:
GOOS=js GOARCH=wasm go test runtime -v -run=TestG0StackOverflow
Change-Id: If450f3ee5209bb32efc1abd0a34b1cc4a29d0c46
GitHub-Last-Rev: 0d7c396e4c
GitHub-Pull-Request: golang/go#63956
Reviewed-on: https://go-review.googlesource.com/c/go/+/539995
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This change introduces new options to set the floating point
mode on ARM targets. The GOARM version number can optionally be
followed by ',hardfloat' or ',softfloat' to select whether to
use hardware instructions or software emulation for floating
point computations, respectively. For example,
GOARM=7,softfloat.
Previously, software floating point support was limited to
GOARM=5. With these options, software floating point is now
extended to all ARM versions, including GOARM=6 and 7. This
change also extends hardware floating point to GOARM=5.
GOARM=5 defaults to softfloat and GOARM=6 and 7 default to
hardfloat.
For #61588
Change-Id: I23dc86fbd0733b262004a2ed001e1032cf371e94
Reviewed-on: https://go-review.googlesource.com/c/go/+/514907
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
The devirtualizer and inliner both want to recognize call expressions
that are part of a go or defer statement. This CL refactors them to
use a single CallExpr.GoDefer flag, which gets set during
normalization of go/defer statements during typecheck.
While here, drop some OCALLMETH assertions. Typecheck has been
responsible for desugaring them into OCALLFUNC for a while now, and
ssagen will check this again for us later anyway.
Change-Id: I3fc370f4417431aae97239313da6fe523f512a2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/543657
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
For some types where the zero value is a value where all bits of this type are 0 optimize it.
goos: windows
goarch: amd64
pkg: reflect
cpu: AMD Ryzen 7 7840HS w/ Radeon 780M Graphics
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
IsZero/StructInt_512-16 109.75n ± 0% 72.61n ± 1% -33.84% (p=0.000 n=12)
Change-Id: I56de8b95f4d4482068960d6f38938763fa1caa90
GitHub-Last-Rev: c143f0cd76
GitHub-Pull-Request: golang/go#64220
Reviewed-on: https://go-review.googlesource.com/c/go/+/543355
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently the final size computed for an object in mallocgc excludes the
allocation header. This is correct in a number of cases, but definitely
wrong for memory profiling because the "free" side accounts for the full
allocation slot.
This change makes an explicit distinction between the parts of mallocgc
that care about the full allocation slot size ("the GC's accounting")
and those that don't (pointer+len should always be valid). It then
applies the appropriate size to the different forms of accounting in
mallocgc.
For #64153.
Change-Id: I481b34b2bb9ff923b59e8408ab2b8fb9025ba944
Reviewed-on: https://go-review.googlesource.com/c/go/+/542735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Add runtime-internal locks to the mutex contention profile.
Store up to one call stack responsible for lock contention on the M,
until it's safe to contribute its value to the mprof table. Try to use
that limited local storage space for a relatively large source of
contention, and attribute any contention in stacks we're not able to
store to a sentinel _LostContendedLock function.
Avoid ballooning lock contention while manipulating the mprof table by
attributing to that sentinel function any lock contention experienced
while reporting lock contention.
Guard collecting real call stacks with GODEBUG=profileruntimelocks=1,
since the available data has mixed semantics; we can easily capture an
M's own wait time, but we'd prefer for the profile entry of each
critical section to describe how long it made the other Ms wait. It's
too late in the Go 1.22 cycle to make the required changes to
futex-based locks. When not enabled, attribute the time to the sentinel
function instead.
Fixes#57071
Change-Id: I3eee0ccbfc20f333b56f20d8725dfd7f3a526b41
Reviewed-on: https://go-review.googlesource.com/c/go/+/528657
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Rhys Hiltner <rhys@justin.tv>
Reviewed-by: Than McIntosh <thanm@google.com>
A persistent performance regression was discovered on
perf.golang.org/dashboard and this was narrowed down to the switch to
footers. Using allocation headers instead resolves the issue.
The benchmark results for allocation footers weren't realistic, because
they were performed on a machine with enough L3 cache that it completely
hid the additional cache miss introduced by allocation footers.
This means that in some corner cases the Go runtime may no longer
allocate 16-byte aligned memory. Note however that this property was
*mostly* incidental and never guaranteed in any documentation.
Allocation headers were tested widely within Google and no issues were
found, so we're fairly confident that this will not affect very many
users.
Nonetheless, by Hyrum's Law some code might depend on it. A follow-up
change will add a GODEBUG flag that ensures 16 byte alignment at the
potential cost of some additional memory use. Users experiencing both a
performance regression and an alignment issue can also disable the
GOEXPERIMENT at build time.
This reverts commit 1e250a2199.
Change-Id: Ia7d62a9c60d1773c8b6d33322ee33a80ef814943
Reviewed-on: https://go-review.googlesource.com/c/go/+/543255
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Previously, we used the presence of individual origin fields
to decide whether an Origin could be checked for staleness,
with a nil Origin representing “use whatever you have”.
However, that turns out to be fairly bug-prone: if we forget
to populate an Origin somewhere, we end up with an incomplete
check instead of a non-reusable origin (see #61415, #61423).
As of CL 543155, the reusability check for a given query
now depends on what is needed by the query more than what
is populated in the origin. With that in place, we can simplify
the handling of the Origin struct by using a nil pointer
to represent inconsistent or unavailable origin data, and
otherwise always reporting whatever origin information we have
regardless of whether we expect it to be reused.
Updates #61415.
Updates #61423.
Change-Id: I97c51063d6c2afa394a05bf304a80c72c08f82cf
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/543216
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
When 'go list' or 'go mod download' uses a proxy to resolve a version
query like "@latest", it may have origin metadata about the resolved
version but not about the inputs that would be needed to resolve the
same query without using the proxy.
We shouldn't just redact the incomplete information, because it might
be useful independent of the -reuse flag. Instead, we examine the
query to decide which origin information it ought to need, and avoid
reusing it if that information isn't included.
Fixes#61423.
Change-Id: Ibeaa46ebba284beee285cbb1898e271e5a5b257b
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/543155
Reviewed-by: Michael Matloob <matloob@golang.org>
Commit-Queue: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
getimpliedreg was used to set a default register in cases where
one was implied but not set by the assembler or compiler.
In most cases with constant values, R0 is implied, and is the value
0 by architectural design. In those cases, R0 is always used, so
treat 0 and REG_R0 as interchangeable in those encodings.
Similarly, the pseudo-register SP or FP is used to in place of the
stack pointer, always R1 on PPC64. Unconditionally set this during
classification of NAME_AUTO and NAME_PARAM as it may be 0.
The case where REGSB might be returned from getimpliedreg is never
used. REGSB is aliased to R2, but in practice it is either R0 or R2
depending on buildmode. See symbolAccess in asm9.go for an example.
Change-Id: I7283e66d5351f56a7fe04cee38714910eaa73cb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/434775
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change enhances the zstd Reader's skipFrame function to validate
the new offset when skipping frames in a seekable stream, preventing
invalid offsets that could occur previously.
A set of "bad" test strings has been added to fuzz_test.go to extend
the robustness checks against potential decompression panics.
Additionally, a new test named TestReaderBad is introduced in
zstd_test.go to verify proper error handling with corrupted input
strings.
The BenchmarkLarge function has also been refactored for clarity,
removing unnecessary timer stops and resets.
Updates #63824
Change-Id: Iccd248756ad6348afa1395c7799350d07402868a
GitHub-Last-Rev: 63055b91e9
GitHub-Pull-Request: golang/go#64056
Reviewed-on: https://go-review.googlesource.com/c/go/+/541220
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Klaus Post <klauspost@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Module queries for "@latest" and inexact constraints (like "@v1.3")
may consult information about tags and/or branches before finally
returning either a result or an error.
To correctly invalidate the origin information for the -reuse flag,
the reported Origin needs to reflect all of those inputs.
Fixes#61415.
Change-Id: I054acbef7d218a92a3bbb44517326385e458d907
Reviewed-on: https://go-review.googlesource.com/c/go/+/542717
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
When debugging a runtime crash with a stack trace, sometimes we
have the g pointer in some places (e.g. as an argument of a
traceback function), but the g's goid in some other places (the
stack trace of that goroutine), which are usually not easy to
match up. This CL makes it print the g pointer. This is only
printed in crash mode, so it doesn't change the usual user stack
trace.
Change-Id: I19140855bf020a327ab0619b665ec1d1c70cca8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/541996
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
runtime.memhash_varlen is defined as a normal function, but it is
actually a closure. All references are generated by
cmd/compile/internal/reflectdata.genhash, which creates a closure
containing the size of the type, which memhash_varlen accesses with
runtime.getclosureptr.
Since this doesn't look like a normal closure, ir.Func.OClosure is not
set, thus PGO function value devirtualization is willing to devirtualize
it, generating a call that completely ignores the closure context. This
causes memhash_varlen to either crash or generate incorrect results.
Skip this function, which is the only caller of getclosureptr.
Unfortunately there isn't a good way to detect these ineligible
functions more generally.
Fixes#64209.
Change-Id: Ibf509406667c6d4e5d431f10e5b1d1f926ecd7dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/543195
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This allows those functions to be generated for go/types.
Also, change the generator's renameIdent mechanism so that
it can rename multiple identifiers in one pass through the
AST instead of requiring multiple passes.
No type-checker functionality changes.
Change-Id: Ic78d899c6004b6a0692a95902fdc13f8ffb47824
Reviewed-on: https://go-review.googlesource.com/c/go/+/542757
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This patch reworks how inlheur.AnalyzeFunc is called by the top level
inliner. Up until this point the strategy was to analyze a function at
the point where CanInline is invoked on it, however it simplifies
things to instead make the call outside of CanInline (for example, so
that directly recursive functions can be analyzed).
Also as part of this patch, change things so that we no longer run
some of the more compile-time intensive analysis on functions that
haven't been marked inlinable (so as to safe compile time), and add a
teardown/cleanup hook in the inlheur package to be invoked by the
inliner when we're done inlining.
Change-Id: Id0772a285d891b0bed66dd86adaffa69d973c26a
Reviewed-on: https://go-review.googlesource.com/c/go/+/539318
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This very minor refactoring changes the heuristics analysis code to
avoid running result-flag or param-flag analyzers on functions that
don't have any interesting results or parameters (so as to save a bit
of compile time). No change otherwise in heuristics functionality.
Change-Id: I7ee13f0499cc3d14d5638e2193e4bd8d7b690e5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/537976
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Rework the call site scoring process to relocate the code that looks
for interesting actual expressions at callsites (e.g. passing a
constant, passing a function pointer, etc) back into the original
callsite analysis phase, as opposed to trying to do the analysis at
scoring time. No changes to heuristics functionality; this doesn't
have much benefit here, but will make it easier later on (in a future
ptahc) to reduce ir.StaticValue calls.
Change-Id: I0e946f9589310a405951cb41835a819d38158e45
Reviewed-on: https://go-review.googlesource.com/c/go/+/539317
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Add a debugging flag "-d=inlscoreadj" intended to support running
experiments in which the inliner uses different score adjustment
values for specific heuristics. The flag argument is a series of
clauses separated by the "/" char where each clause takes the form
"adjK:valK". For example, in this build
go build -gcflags=-d=inlscoreadj=inLoopAdj:10/returnFeedsConstToIfAdj:-99
the "in loop" score adjustments would be reset to a value of 15 (effectively
penalizing calls in loops) adn the "return feeds constant to foldable if/switch"
score adjustment would be boosted from -15 to -99.
Change-Id: Ibd1ee334684af5992466556a69baa6dfefb246b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/532116
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TSAN recently got support for Go's new atomic And and Or
operations (#61395). This CL updates the race syso files to
include the change. Also regenerate cgo dynamic imports on darwin.
OpenBSD/AMD64 is not updated, as TSAN no longer supports OpenBSD
(#52090).
Linux/PPC64 is not updated, as I'm running into some builder
issues. Still working on it.
For #61395.
For #62624.
Change-Id: Ifc90ea79284f29a356f9e8a5f144f6c690881395
Reviewed-on: https://go-review.googlesource.com/c/go/+/543035
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Before Go 1.21, ValueOf always escapes and a Value's content is
always heap allocated. In Go 1.21, we made it no longer always
escape, guarded by go121noForceValueEscape. This behavior has
been released for some time and there is no issue so far. We can
remove the guard now.
Change-Id: I81f5366412390f6c63b642f4c7c016da534da76a
Reviewed-on: https://go-review.googlesource.com/c/go/+/542795
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
E.g.
`GOEXPERIMENT=rangefunc go test -v -gcflags=-d=rangefunccheck=0 rangefunc_test.go`
will turn off the checking and fail.
The benchmarks, which do not use pathological iterators, run slightly faster.
Change-Id: Ia3e175e86d67ef74bbae9bcc5d2def6a2cdf519d
Reviewed-on: https://go-review.googlesource.com/c/go/+/541995
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently bulkBarrierPreWrite follows a fairly slow path wherein it
calls typePointersOf, which ends up calling into fastForward. This does
some fairly heavy computation to move the iterator forward without any
assumptions about where it lands at all. It needs to be completely
general to support splitting at arbitrary boundaries, for example for
scanning oblets.
This means that copying objects during the GC mark phase is fairly
expensive, and is a regression from before allocheaders.
However, in almost all cases bulkBarrierPreWrite and
bulkBarrierPreWriteSrcOnly have perfect type information. We can do a
lot better in these cases because we're starting on a type-size
boundary, which is exactly what the iterator is built around.
This change adds the typePointersOfType method which produces a
typePointers iterator from a pointer and a type. This change
significantly improves the performance of these bulk write barriers,
eliminating some performance regressions that were noticed on the perf
dashboard.
There are still just a couple cases where we have to use the more
general typePointersOf calls, but they're fairly rare; most bulk
barriers have perfect type information.
This change is tested by the GCInfo tests in the runtime and the GCBits
tests in the reflect package via an additional check in getgcmask.
Results for tile38 before and after allocheaders. There was previous a
regression in the p90, now it's gone. Also, the overall win has been
boosted slightly.
tile38 $ benchstat noallocheaders.results allocheaders.results
name old time/op new time/op delta
Tile38QueryLoad 481µs ± 1% 468µs ± 1% -2.71% (p=0.000 n=10+10)
name old average-RSS-bytes new average-RSS-bytes delta
Tile38QueryLoad 6.32GB ± 1% 6.23GB ± 0% -1.38% (p=0.000 n=9+8)
name old peak-RSS-bytes new peak-RSS-bytes delta
Tile38QueryLoad 6.49GB ± 1% 6.40GB ± 1% -1.38% (p=0.002 n=10+10)
name old peak-VM-bytes new peak-VM-bytes delta
Tile38QueryLoad 7.72GB ± 1% 7.64GB ± 1% -1.07% (p=0.007 n=10+10)
name old p50-latency-ns new p50-latency-ns delta
Tile38QueryLoad 212k ± 1% 205k ± 0% -3.02% (p=0.000 n=10+9)
name old p90-latency-ns new p90-latency-ns delta
Tile38QueryLoad 622k ± 1% 616k ± 1% -1.03% (p=0.005 n=10+10)
name old p99-latency-ns new p99-latency-ns delta
Tile38QueryLoad 4.55M ± 2% 4.39M ± 2% -3.51% (p=0.000 n=10+10)
name old ops/s new ops/s delta
Tile38QueryLoad 12.5k ± 1% 12.8k ± 1% +2.78% (p=0.000 n=10+10)
Change-Id: I0a48f848eae8777d0fd6769c3a1fe449f8d9d0a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/542219
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
getgcmask stops referencing the object passed to it sometime between
when the object is looked up and when the function returns. Notably,
this can happen while the GC mask is actively being produced, and thus
the GC might free the object.
This is easily reproducible by adding a runtime.GC call at just the
right place. Adding a KeepAlive on the heap-object path fixes it.
Fixes#64188.
Change-Id: I5ed4cae862fc780338b60d969fd7fbe896352ce4
Reviewed-on: https://go-review.googlesource.com/c/go/+/542716
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Also allow specification of "directory" with a trailing
path separator on the name. Updated suffix ".mprof" to ".memprof",
others are similarly disambiguated.
Change-Id: I2f3f44a436893730dbfe70b6815dff1e74885404
Reviewed-on: https://go-review.googlesource.com/c/go/+/542715
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This permits collection of multiple profiles in a build
(instead of just the last compilation). If a -memprofile
specifies an existing directory instead of a file, it will
create "<url.PathEscape(pkgpath)>.mprof" in that directory.
The PathEscaped package names are ugly, but this puts all
the files in a single directory with no risk of name clashs,
which simplies the usual case for using these files, which
is something like
```
go tool pprof profiles/*.mprof
```
Creating a directory tree mimicking the package structure
requires something along the lines of
```
go tool pprof `find profiles -name "*.mprof" -print`
```
In addition, this turns off "legacy format" because that
is only useful for a benchcompile, which does not use this
new feature (and people actually interested in memory
profiles probably prefer the new ones).
Change-Id: Ic1d9da53af22ecdda17663e0d4bce7cdbcb54527
Reviewed-on: https://go-review.googlesource.com/c/go/+/539316
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
treat the panic, like a panic. It helps with inlining,
and thus reduced closure allocation and performance, for
many examples of function range iterators.
Change-Id: Ib1a656cdfa56eb2dee400089c4c94ac14f1d2104
Reviewed-on: https://go-review.googlesource.com/c/go/+/541235
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When this happens, panic.
This is a revised version of a check that used #next,
where this one instead uses a per-loop #exit flag,
and catches more problematic iterators.
Updates #56413.
Updates #61405.
Change-Id: I6574f754e475bb67b9236b4f6c25979089f9b629
Reviewed-on: https://go-review.googlesource.com/c/go/+/540263
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This was originally done for a #next-encoding-based check for
misbehaving loops, but it's a good idea anyhow because it makes
the code slightly easier to follow or change (we may decide to
check for errors the "other way" anyhow, later).
Change-Id: I2ba8f6e0f9146f0ff148a900eabdefd0fffebf8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/540261
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Historically, serveContent has not set Content-Length
when the user provides Content-Encoding.
This causes broken responses when the user sets both Content-Length
and Content-Encoding, and the request is a range request,
because the returned data doesn't match the declared length.
CL 381956 fixed this case by changing serveContent to always set
a Content-Length header.
Unfortunately, I've discovered multiple cases in the wild of
users setting Content-Encoding: gzip and passing serveContent
a ResponseWriter wrapper that gzips the data written to it.
This breaks serveContent in a number of ways. In particular,
there's no way for it to respond to Range requests properly,
because it doesn't know the recipient's view of the content.
What the user should be doing in this case is just using
io.Copy to send the gzipped data to the response.
Or possibly setting Transfer-Encoding: gzip.
But whatever they should be doing, what they are doing has
mostly worked for non-Range requests, and setting
Content-Length makes it stop working because the length
of the file being served doesn't match the number of bytes
being sent.
So in the interests of not breaking users (even if they're
misusing serveContent in ways that are already broken),
partially revert CL 381956.
For non-Range requests, don't set Content-Length when
the user has set Content-Encoding. This matches our previous
behavior and causes minimal harm in cases where we could
have set Content-Length. (We will send using chunked
encoding rather than identity, but that's fine.)
For Range requests, set Content-Length unconditionally.
Either the user isn't mangling the data in the ResponseWriter,
in which case the length is correct, or they are, in which
case the response isn't going to contain the right bytes anyway.
(Note that a Range request for a Content-Length: gzip file
is requesting a range of *gzipped* bytes, not a range from
the uncompressed file.)
Change-Id: I5e788e6756f34cee520aa7c456826f462a59f7eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/542595
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
This CL adds four new time histogram metrics:
/sched/pauses/stopping/gc:seconds
/sched/pauses/stopping/other:seconds
/sched/pauses/total/gc:seconds
/sched/pauses/total/other:seconds
The "stopping" metrics measure the time taken to start a stop-the-world
pause. i.e., how long it takes stopTheWorldWithSema to stop all Ps.
This can be used to detect STW struggling to preempt Ps.
The "total" metrics measure the total duration of a stop-the-world
pause, from starting to stop-the-world until the world is started again.
This includes the time spent in the "start" phase.
The "gc" metrics are used for GC-related STW pauses. The "other" metrics
are used for all other STW pauses.
All of these metrics start timing in stopTheWorldWithSema only after
successfully acquiring sched.lock, thus excluding lock contention on
sched.lock. The reasoning behind this is that while waiting on
sched.lock the world is not stopped at all (all other Ps can run), so
the impact of this contention is primarily limited to the goroutine
attempting to stop-the-world. Additionally, we already have some
visibility into sched.lock contention via contention profiles (#57071).
/sched/pauses/total/gc:seconds is conceptually equivalent to
/gc/pauses:seconds, so the latter is marked as deprecated and returns
the same histogram as the former.
In the implementation, there are a few minor differences:
* For both mark and sweep termination stops, /gc/pauses:seconds started
timing prior to calling startTheWorldWithSema, thus including lock
contention.
These details are minor enough, that I do not believe the slight change
in reporting will matter. For mark termination stops, moving timing stop
into startTheWorldWithSema does have the side effect of requiring moving
other GC metric calculations outside of the STW, as they depend on the
same end time.
Fixes#63340
Change-Id: Iacd0bab11bedab85d3dcfb982361413a7d9c0d05
Reviewed-on: https://go-review.googlesource.com/c/go/+/534161
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This patch fixes some problems with call site scoring, adds some new
tests, and moves more of the scoring-related code (for example, the
function "ScoreCalls") into "scoring.go". This also fixes some
problems with scoring of calls in non-inlinable functions (when new
inliner is turned on, scoring has to happen for all functions run
through the inliner, not just for inlinable functions). For such
functions, we build a table of inlinable call sites immediately prior
to scoring; the storage for this table is preserved between functions
so as to reduce allocations.
Change-Id: Ie6f691a3ad04fb7a03ab39f882a60aadaf957f6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/542217
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fix a bug in scoring of calls appearing on panic paths. For this code
snippet:
if x < 101 {
foo()
panic("bad")
}
the function flags analyzer was correctly capturing the status of the
block corresponding to the true arm of the "if" statement, but wasn't
marking "foo()" as being on a panic path.
Change-Id: Iee13782828a1399028e2b560fed5f946850eb253
Reviewed-on: https://go-review.googlesource.com/c/go/+/542216
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In the Checker, maintain a map of versions for each file, even if the
file doensn't specify a version. In that case, the version is the module
version.
If Info.FileVersions is set, use that map directly; otherwise allocate
a Checker-local map.
Introduce a new type, goVersion, which represents a Go language version.
This type effectively takes the role of the earlier version struct.
Replace all versions-related logic accordingly and use the go/version
package for version parsing/validation/comparison.
Added more tests.
Fixes#63974.
Change-Id: Ia05ff47a9eae0f0bb03c6b4cb65a7ce0a5857402
Reviewed-on: https://go-review.googlesource.com/c/go/+/541395
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Currently wakeableSleep has a race where, although stopTimer is called,
the timer could be queued already and fire *after* the wakeup channel is
closed.
Fix this by protecting wakeup with a lock used on the close and wake
paths and assigning the wakeup to nil on close. The wake path then
ignores a nil wakeup channel. This fixes the problem by ensuring that a
failure to stop the timer only results in the timer doing nothing,
rather than trying to send on a closed channel.
The addition of this lock requires some changes to the static lock
ranking system.
Thiere's also a second problem here: the timer could be delayed far
enough into the future that when it fires, it observes a non-nil wakeup
if the wakeableSleep has been re-initialized and reset.
Fix this problem too by allocating the wakeableSleep on the heap and
creating a new one instead of reinitializing the old one. The GC will
make sure that the reference to the old one stays alive for the timer to
fire, but that timer firing won't cause a spurious wakeup in the new
one.
Change-Id: I2b979304e755c015d4466991f135396f6a271069
Reviewed-on: https://go-review.googlesource.com/c/go/+/542335
Reviewed-by: Michael Pratt <mpratt@google.com>
Commit-Queue: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
After landing the new execution tracer, the Windows builders failed with
some new errors.
Currently the GoSyscallBegin event has no indicator that its the target
of a ProcSteal event. This can lead to an ambiguous situation that is
unresolvable if timestamps are broken. For instance, if the tracer sees
the ProcSteal event while a goroutine has been observed to be in a
syscall (one that, for instance, did not actually lose its P), it will
proceed with the ProcSteal incorrectly.
This is a little abstract. For a more concrete example, see the
go122-syscall-steal-proc-ambiguous test.
This change resolves this ambiguity by interleaving GoSyscallBegin
events into how Ps are sequenced. Because a ProcSteal has a sequence
number (it has to, it's stopping a P from a distance) it necessarily
has to synchronize with a precise ProcStart event. This change basically
just extends this synchronization to GoSyscallBegin, so the ProcSteal
can't advance until _exactly the right_ syscall has been entered.
This change removes the test skip, since it and CL 541695 fix the two
main issues observed on Windows platforms.
For #60773.
Fixes#64061.
Change-Id: I069389cd7fe1ea903edf42d79912f6e2bcc23f62
Reviewed-on: https://go-review.googlesource.com/c/go/+/541696
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
An out-of-memory error in this test has been observed on 32-bit
platforms, so halve the memory footprint of the test. Also halve the
size of steady-state allocation rate in bytes. The end result should be
approximately the same GC CPU load but at half the memory usage.
Change-Id: I2c2d335da7dc4c5c58cb9d92b6e5a4ece55d24a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/542215
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently the trace parser enforces that the timestamps for a series of
a batches on the same M come in order. We cannot actually assume this in
general because we don't trust timestamps. The source of truth on the
batch order is the order in which they were emitted. If that's wrong, it
should quickly become evident in the trace.
For #60773.
For #64061.
Change-Id: I7d5a407c9568dd1ce0b79d51b2b538ed6072b26d
Reviewed-on: https://go-review.googlesource.com/c/go/+/541695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Even though we don't issue beta pre-releases of Go at this time,
it can still be useful to build them without publishing as part
of testing the release infrastructure.
For such versions, use the next directory content so that the
API check doesn't produce a false positive during the earlier
stages of the development cycle, before the next directory is
merged into a combined and eventually frozen api file.
For #29205.
Change-Id: Ib5e962670de1df22f7df64dd237b555953096808
Reviewed-on: https://go-review.googlesource.com/c/go/+/542000
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Most of the uses of work.pauseStart are completely useless, it could
simply be a local variable. One use passes a parameter from gcMarkDone
to gcMarkTermination, but that could simply be an argument.
Keeping this field in workType makes it seems more important than it
really is, so just drop it.
Change-Id: I2fdc0b21f8844e5e7be47148c3e10f13e49815c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/542075
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Generate the CC version of many opcodes whose result is compared against
signed 0. The approach taken here works even if the opcode result is used in
multiple places too.
Add support for ADD, ADDconst, ANDN, SUB, NEG, CNTLZD, NOR conversions
to their CC opcode variant. These are the most commonly used variants.
Also, do not set clobberFlags of CNTLZD and CNTLZW, they do not clobber
flags.
This results in about 1% smaller text sections in kubernetes binaries,
and no regressions in the crypto benchmarks.
Change-Id: I9e0381944869c3774106bf348dead5ecb96dffda
Reviewed-on: https://go-review.googlesource.com/c/go/+/538636
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jayanth Krishnamurthy <jayanth.krishnamurthy@ibm.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
This CL exports the previously unexported Alias type and
corresponding functions and methods per issue #63223.
Whether Alias types are used or not is controlled by
the gotypesalias setting with the GODEBUG environment
variable. Setting gotypesalias to "1" enables the Alias
types:
GODEBUG=gotypesalias=1
By default, gotypesalias is not set.
Adjust test cases that enable/disable the use of Alias
types to use -gotypesalias=1 or -gotypesalias=0 rather
than -alias and -alias=false for consistency and to
avoid confusion.
For #63223.
Change-Id: I51308cad3320981afac97dd8c6f6a416fdb0be55
Reviewed-on: https://go-review.googlesource.com/c/go/+/541737
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
As of CL 539699, PGO-based devirtualization supports devirtualization of
function values in addition to interface method calls. As with CL
497175, we need to explicitly look up functions from export data that
may not be imported already.
Symbol naming is ambiguous (`foo.Bar.func1` could be a closure or a
method), so we simply attempt to do both types of lookup. That said,
closures are defined in export data only as OCLOSURE nodes in the
enclosing function, which this CL does not yet attempt to expand.
For #61577.
Change-Id: Ic7205b046218a4dfb8c4162ece3620ed1c3cb40a
Reviewed-on: https://go-review.googlesource.com/c/go/+/540258
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Today, PGO-based devirtualization only applies to interface calls. This
CL extends initial support to function values (i.e., function/closure
pointers passed as arguments or stored in a struct).
This CL is a minimal implementation with several limitations.
* Export data lookup of function value callees not implemented
(equivalent of CL 497175; done in CL 540258).
* Callees must be standard static functions. Callees that are closures
(requiring closure context) are not supported.
For #61577.
Change-Id: I7d328859035249e176294cd0d9885b2d08c853f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/539699
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In manual mode, _Alias nodes are disabled by default and can be
enabled with a line comment (// -alias) at the start of a file.
Follow-up on feedback for CL 521956.
Change-Id: I937eb2e58e9e96fa6785ac45ca19e6328d2bd1fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/541295
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
This change adds a new MutatorUtilization for traces for Go 1.22+.
To facilitate testing, it also generates a short trace with the
gc-stress.go test program (shortening its duration to 10ms) and adds it
to the tests for the internal/trace/v2 package. Notably, we make sure
this trace has a GCMarkAssistActive event to test that codepath.
For #63960.
For #60773.
Change-Id: I2e61f545988677be716818e2a08641c54c4c201f
Reviewed-on: https://go-review.googlesource.com/c/go/+/540256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change mostly implements the design described in #60773 and
includes a new scalable parser for the new trace format, available in
internal/trace/v2. I'll leave this commit message short because this is
clearly an enormous CL with a lot of detail.
This change does not hook up the new tracer into cmd/trace yet. A
follow-up CL will handle that.
For #60773.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-amd64-longtest-race
Change-Id: I5d2aca2cc07580ed3c76a9813ac48ec96b157de0
Reviewed-on: https://go-review.googlesource.com/c/go/+/494187
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently the user arena code writes heap bits to the (*mspan).heapBits
space with the platform-specific byte ordering (the heap bits are
written and managed as uintptrs). However, the compiler always emits GC
metadata for types in little endian.
Because the scanning part of the code that loads through the type
pointer in the allocation header expects little endian ordering, we end
up with the wrong byte ordering in GC when trying to scan arena memory.
Fix this by writing out the user arena heap bits in little endian on big
endian platforms.
This means that the space returned by (*mspan).heapBits has a different
meaning for user arenas and small object spans, which is a little odd,
so I documented it. To reduce the chance of misuse of the writeHeapBits
API, which now writes out heap bits in a different ordering than
writeSmallHeapBits on big endian platforms, this change also renames
writeHeapBits to writeUserArenaHeapBits.
Much of this can be avoided in the future if the compiler were to write
out the pointer/scalar bits as an array of uintptr values instead of
plain bytes. That's too big of a change for right now though.
This change is a no-op on little endian platforms. I confirmed it by
checking for any assembly code differences in the runtime test binary.
There were none. With this change, the arena tests pass on ppc64.
Fixes#64048.
Change-Id: If077d003872fcccf5a154ff5d8441a58582061bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/541315
Run-TryBot: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL changes the FileVersions map to map to version strings
rather than Version structs, for use with the new go/versions
package.
Adjust the cmd/dist bootstrap package list to include go/version.
Adjust the compiler's noder to work with the new API.
For #62605.
For #63974.
Change-Id: I191a7015ba3fb61c646e9f9d3c3dbafc9653ccb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/541296
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
While fixing several bugs in path handling on Windows,
beginning with \\?\.
Prior to #540277, VolumeName considered the first path component
after the \\?\ prefix to be part of the volume name.
After, it considered only the \\? prefix to be the volume name.
Restore the previous behavior.
Fixes#64028
Change-Id: I6523789e61776342800bd607fb3f29d496257e68
Reviewed-on: https://go-review.googlesource.com/c/go/+/541175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Currently tickspersecond forces a 100 millisecond sleep the first time
it's called. This isn't great for profiling short-lived programs, since
both CPU profiling and block profiling might call into it.
100 milliseconds is a long time, but it's chosen to try and capture a
decent estimate of the conversion on platform with course-granularity
clocks. If the granularity is 15 ms, it'll only be 15% off at worst.
Let's try a different strategy. First, let's require 5 milliseconds of
time to have elapsed at a minimum. This should be plenty on platforms
with nanosecond time granularity from the system clock, provided the
caller of tickspersecond intends to use it for calculating durations,
not timestamps. Next, grab a timestamp as close to process start as
possible, so that we can cover some of that 5 millisecond just during
runtime start.
Finally, this function is only ever called from normal goroutine
contexts. Let's do a regular goroutine sleep instead of a thread-level
sleep under a runtime lock, which has all sorts of nasty effects on
preemption.
While we're here, let's also rename tickspersecond to ticksPerSecond.
Also, let's write down some explicit rules of thumb on when to use this
function. Clocks are hard, and using this for timestamp conversion is
likely to make lining up those timestamps with other clocks on the
system difficult if not impossible.
Note that while this improves ticksPerSecond on platforms with good
clocks, we still end up with a pretty coarse sleep on platforms with
coarse clocks, and a pretty coarse result. On these platforms, keep the
minimum required elapsed time at 100 ms. There's not much we can do
about these platforms except spin and try to catch the clock boundary,
but at 10+ ms of granularity, that might be a lot of spinning.
Fixes#63103.
Fixes#63078.
Change-Id: Ic32a4ba70a03bdf5c13cb80c2669c4064aa4cca2
Reviewed-on: https://go-review.googlesource.com/c/go/+/538898
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently dedicated GC mark workers really try to avoid getting
preempted. The one exception is for a pending STW, indicated by
sched.gcwaiting. This is currently fine because other kinds of
preemptions don't matter to the mark workers: they're intentionally
bound to their P.
With the new execution tracer we're going to want to use forEachP to get
the attention of all Ps. We may want to do this during a GC cycle.
forEachP doesn't set sched.gcwaiting, so it may end up waiting the full
GC mark phase, burning a thread and a P in the meantime. This can mean
basically seconds of waiting and trying to preempt GC mark workers.
This change makes all mark workers yield if (*p).runSafePointFn != 0 so
that the workers actually yield somewhat promptly in response to a
forEachP attempt.
Change-Id: I7430baf326886b9f7a868704482a224dae7c9bba
Reviewed-on: https://go-review.googlesource.com/c/go/+/537235
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently any thread that tries to get the attention of all Ps (e.g.
stopTheWorldWithSema and forEachP) ends up in a non-preemptible state
waiting to preempt another thread. Thing is, that other thread might
also be in a non-preemptible state, trying to preempt the first thread,
resulting in a deadlock.
This is a general problem, but in practice it only boils down to one
specific scenario: a thread in GC is blocked trying to preempt a
goroutine to scan its stack while that goroutine is blocked in a
non-preemptible state to get the attention of all Ps.
There's currently a hack in a few places in the runtime to move the
calling goroutine into _Gwaiting before it goes into a non-preemptible
state to preempt other threads. This lets the GC scan its stack because
the goroutine is trivially preemptible. The only restriction is that
forEachP and stopTheWorldWithSema absolutely cannot reference the
calling goroutine's stack. This is generally not necessary, so things
are good.
Anyway, to avoid exposing the details of this hack, this change creates
a safer wrapper around forEachP (and then renames it to forEachP and the
existing one to forEachPInternal) that performs the goroutine status
change, just like stopTheWorld does. We're going to need to use this
hack with forEachP in the new tracer, so this avoids propagating the
hack further and leaves it as an implementation detail.
Change-Id: I51f02e8d8e0a3172334d23787e31abefb8a129ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/533455
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently the execution tracer synchronizes with itself using very
heavyweight operations. As a result, it's totally fine for most of the
tracer code to look like:
if traceEnabled() {
traceXXX(...)
}
However, if we want to make that synchronization more lightweight (as
issue #60773 proposes), then this is insufficient. In particular, we
need to make sure the tracer can't observe an inconsistency between g
atomicstatus and the event that would be emitted for a particular
g transition. This means making the g status change appear to happen
atomically with the corresponding trace event being written out from the
perspective of the tracer.
This requires a change in API to something more like a lock. While we're
here, we might as well make sure that trace events can *only* be emitted
while this lock is held. This change introduces such an API:
traceAcquire, which returns a value that can emit events, and
traceRelease, which requires the value that was returned by
traceAcquire. In practice, this won't be a real lock, it'll be more like
a seqlock.
For the current tracer, this API is completely overkill and the value
returned by traceAcquire basically just checks trace.enabled. But it's
necessary for the tracer described in #60773 and we can implement that
more cleanly if we do this refactoring now instead of later.
For #60773.
Change-Id: Ibb9ff5958376339fafc2b5180aef65cf2ba18646
Reviewed-on: https://go-review.googlesource.com/c/go/+/515635
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change replaces the 1-bit-per-word heap bitmap for most size
classes with allocation headers for objects that contain pointers. The
header consists of a single pointer to a type. All allocations with
headers are treated as implicitly containing one or more instances of
the type in the header.
As the name implies, headers are usually stored as the first word of an
object. There are two additional exceptions to where headers are stored
and how they're used.
Objects smaller than 512 bytes do not have headers. Instead, a heap
bitmap is reserved at the end of spans for objects of this size. A full
word of overhead is too much for these small objects. The bitmap is of
the same format of the old bitmap, minus the noMorePtrs bits which are
unnecessary. All the objects <512 bytes have a bitmap less than a
pointer-word in size, and that was the granularity at which noMorePtrs
could stop scanning early anyway.
Objects that are larger than 32 KiB (which have their own span) have
their headers stored directly in the span, to allow power-of-two-sized
allocations to not spill over into an extra page.
The full implementation is behind GOEXPERIMENT=allocheaders.
The purpose of this change is performance. First and foremost, with
headers we no longer have to unroll pointer/scalar data at allocation
time for most size classes. Small size classes still need some
unrolling, but their bitmaps are small so we can optimize that case
fairly well. Larger objects effectively have their pointer/scalar data
unrolled on-demand from type data, which is much more compactly
represented and results in less TLB pressure. Furthermore, since the
headers are usually right next to the object and where we're about to
start scanning, we get an additional temporal locality benefit in the
data cache when looking up type metadata. The pointer/scalar data is
now effectively unrolled on-demand, but it's also simpler to unroll than
before; that unrolled data is never written anywhere, and for arrays we
get the benefit of retreading the same data per element, as opposed to
looking it up from scratch for each pointer-word of bitmap. Lastly,
because we no longer have a heap bitmap that spans the entire heap,
there's a flat 1.5% memory use reduction. This is balanced slightly by
some objects possibly being bumped up a size class, but most objects are
not tightly optimized to size class sizes so there's some memory to
spare, making the header basically free in those cases.
See the follow-up CL which turns on this experiment by default for
benchmark results. (CL 538217.)
Change-Id: I4c9034ee200650d06d8bdecd579d5f7c1bbf1fc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/437955
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The Go linker doesn't currently merge .pdata/.xdata sections from the
host object files generated by the C compiler when using internal
linking. This means that the stack can't be unwind in C -> Go.
This CL fixes that and adds a test to ensure that the stack can be
unwind in C -> Go and Go -> C transitions, which was not well tested.
Updates #57302
Change-Id: Ie86a5e6e30b80978277e66ccc2c48550e51263c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/534555
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This optab matching rule was used to match signed 16 bit values shifted
left by 16 bits. Unsigned 16 bit values greater than 0x7FFF<<16 were
classified as C_U32CON which led to larger than necessary codegen.
Instead, rewrite logical/arithmetic operations in the preprocessor pass
to use the 16 bit shifted immediate operation (e.g ADDIS vs ADD). This
simplifies the optab matching rules, while also minimizing codegen size
for large unsigned values.
Note, ADDIS sign-extends the constant argument, all others do not.
For matching opcodes, this means:
MOVD $is<<16,Rx becomes ADDIS $is,Rx or ORIS $is,Rx
MOVW $is<<16,Rx becomes ADDIS $is,Rx
ADD $is<<16,[Rx,]Ry becomes ADDIS $is[Rx,]Ry
OR $is<<16,[Rx,]Ry becomes ORIS $is[Rx,]Ry
XOR $is<<16,[Rx,]Ry becomes XORIS $is[Rx,]Ry
Change-Id: I1a988d9f52517a04bb8dc2e41d7caf3d5fff867c
Reviewed-on: https://go-review.googlesource.com/c/go/+/536735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
This change introduces a new (unexported for now) _Alias type node
which serves as an explicit representation for alias types in type
alias declarations:
type A = T
The _Alias node stands for the type A in this declaration, with
the _Alias' actual type pointing to (the type node for) T.
Without the _Alias node, (the object for) A points directly to T.
Explicit _Alias nodes permit better error messages (they mention
A instead of T if the type in the source was named A) and can help
with certain type cycle problems. They are also needed to hold
type parameters for alias types, eventually.
Because an _Alias node is simply an alternative representation for
an aliased type, code that makes type-specific choices must always
look at the actual (unaliased) type denoted by a type alias.
The new function
func _Unalias(t Type) Type
performs the necessary indirection. Type switches that consider
type nodes, must either switch on _Unalias(typ) or handle the
_Alias case.
To avoid breaking clients, _Alias nodes must be enabled explicitly,
through the new Config flag _EnableAlias.
To run tests with the _EnableAlias set, use the new -alias flag as
in "go test -run short -alias". The testing harness understands
the flag as well and it may be used to enable/disable _Alias nodes
on a per-file basis, with a comment ("// -alias" or // -alias=false)
on the first line in those files. The file-based flag overrides the
command-line flag.
The use of _Alias nodes is disabled by default and must be enabled
by setting _EnableAlias.
Passes type checker tests with and without -alias flag set.
For #25838.
For #44410.
For #46477.
Change-Id: I78e178a1aef4d7f325088c0c6cbae4cfb1e5fb5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/521956
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Currently, instruction validation failure will result in a panic during
encoding. Furthermore, the errors generated do not include the PC or
file/line information that is normally present.
Fix this by:
- Tracking and printing the *obj.Prog associated with the instruction,
including the assembly instruction/opcode if it differs. This provides
the standard PC and file/line prefix, which is also expected by assembly
error end-to-end tests.
- Not proceeding with assembly if errors exist - with the current design,
errors are identified during validation, which is run via preprocess.
Attempts to encode invalid instructions will intentionally panic.
Add some additional riscv64 encoding errors, now that we can actually do so.
Change-Id: I64a7b83680c4d12aebdc96c67f9df625b5ef90d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/523459
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: M Zhuo <mzh@golangcn.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: M Zhuo <mzh@golangcn.org>
This fixes an inconsistency that was introduced in CL 537480 and noted
in the review on CL 539697.
In particular, 'go mod download' already updates the go.mod file when
other kinds of updates are needed. (#45551 suggested that it should
not do so, but that part of the change was not implemented yet;
finishing that change is proposed as #64008.)
Updates #62054.
Change-Id: Ic659eb8538f4afdec0454737e982d42ef8957e56
Reviewed-on: https://go-review.googlesource.com/c/go/+/540779
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
The fchmodat2 syscall was added in Linux kernel 6.6. Mirror the
implementation in golang.org/x/sys/unix.Fchmodat (CL 539635) and use
fchmodat2 in Fchmodat if flags are given. It will return ENOSYS on older
kernels (or EINVAL or any other bogus error in some container
implementations).
Also update ztypes_linux_$GOARCH.go for all linux platforms to add
_AT_EMPTY_PATH. It was added to linux/types in CL 407694 but was only
updated for linux/loong64 at that time.
Updates #61636
Change-Id: I863d06e35cd366f1cf99052e9f77c22ab8168b3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/540435
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
With the introduction of runtime.Pinner, returning a pointer to a pinned
struct that then points to an unpinned Go pointer is correctly caught.
However, the error message remained as "cgo result has Go pointer",
which should be updated to acknowledge that Go pointers to pinned
memory are allowed.
This also updates the comments for cgoCheckArg and cgoCheckResult
to similarly clarify.
Updates #46787
Change-Id: I147bb09e87dfb70a24d6d43e4cf84e8bcc2aff48
GitHub-Last-Rev: 706facb9f2
GitHub-Pull-Request: golang/go#62606
Reviewed-on: https://go-review.googlesource.com/c/go/+/527702
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
The current GOEXPERIMENT=newinliner strategy us to run "CanInline" for
a given function F with an expanded/relaxed budget of 160 (instead of
the default 80), and then only inline a call to F if the adjustments
we made to F's original score are below 80.
This way of doing things winds up writing out many more functions to
export data that have size between 80 and 160, on the theory that they
might be inlinable somewhere given the right context, which is
expensive from a compile time perspective.
This patch changes things to add a pass that revises the inlinability
of a function after its properties are computed by looking at its
properties and estimating the largest possible negative score
adjustment that could happen given the various return and param props.
If the computed score for the function minus the max adjust is not
less than 80, then we demote it from inlinable to non-inlinable to
save compile time.
Change-Id: Iedaac520d47f632be4fff3bd15d30112b46ec573
Reviewed-on: https://go-review.googlesource.com/c/go/+/529118
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This patch makes a small enhancement to call result scoring, to make
it more independent of param value heuristics. For this pair of
functions:
func caller() {
v := callee(10) <<-- this callsite
if v > 101 {
...
}
}
func callee(x int) {
if x < 0 {
G = 1
}
return 9
}
The score for the specified call site above would be adjusted only
once, for the "pass constant to parameter that feeds 'if' statement"
heuristic, which didn't reflect the fact that doing the inline enables
not one but two specific deadcode opportunities (first for the code
inside the inlined routine body, then for the "if" downstream of the
inlined call).
This patch changes the call result scoring machinery to use a separate
set of mask bits, so that we can more accurately handle the case
above.
Change-Id: I700166d0c990c037215b9f904e9984886986c600
Reviewed-on: https://go-review.googlesource.com/c/go/+/529117
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The code that analyzes function return values checks for cases where a
function F always returns the same inlinable function, e.g.
func returnsFunc() func(*int, int) { return setit }
func setit(p *int, v int) { *p = v }
The check for inlinability was being done by looking at "fn.Inl !=
nil", which is probably not what we want, since it includes functions
whose cost value is between 80 and 160 and may only be inlined if lots
of other heuristics kick in.
This patch changes the "always returns same inlinable func" heuristic
to ensure that the func in question has a size of 80 or less, so as to
restrict this case to functions that have a high likelihood of being
inlined.
Change-Id: I06003bca1c56c401df8fd51c922a59c61aa86bea
Reviewed-on: https://go-review.googlesource.com/c/go/+/529116
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Previously, a Perl script was used to test the net/http/cgi package.
This sometimes led to hidden failures as these tests were not run
on builders without Perl.
Also, this approach posed maintenance difficulties for those
unfamiliar with Perl.
We have now replaced Perl-based tests with a Go handler to simplify
maintenance and ensure consistent testing environments.
It's part of our ongoing effort to reduce reliance on Perl throughout
the Go codebase (see #20032,#25586,#25669,#27779),
thus improving reliability and ease of maintenance.
Fixes#63800Fixes#63828
Change-Id: I8d554af93d4070036cf0cc3aaa9c9b256affbd17
GitHub-Last-Rev: a8034083d8
GitHub-Pull-Request: golang/go#63869
Reviewed-on: https://go-review.googlesource.com/c/go/+/538861
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: qiulaidongfeng <2645477756@qq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Commit-Queue: Bryan Mills <bcmills@google.com>
Fix#63955
parseIndVar, prove and maybe more are on the assumption that the loop header
is a single block. This can be wrong, ensure we don't match theses cases we
don't know how to handle.
In the future we could update them so that they know how to handle such cases
but theses cases seems rare so I don't think the value would be really high.
We could also run a loop canonicalization pass first which could handle this.
The repro case looks weird because I massaged it so it would crash with the
previous compiler.
Change-Id: I4aa8afae9e90a17fa1085832250fc1139c97faa6
Reviewed-on: https://go-review.googlesource.com/c/go/+/539977
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The writeBarrier "needed" struct member has the exact same
value as "enabled", and used interchangeably.
I'm not sure if we plan to make a distinction between the
two at some point, but today they are effectively the same,
so dedup it and keep only "enabled".
Change-Id: I65e596f174e1e820dc471a45ff70c0ef4efbc386
GitHub-Last-Rev: f8c805a916
GitHub-Pull-Request: golang/go#63814
Reviewed-on: https://go-review.googlesource.com/c/go/+/538495
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
On Windows, A root local device path is a path which begins with
\\?\ or \??\. A root local device path accesses the DosDevices
object directory, and permits access to any file or device on the
system. For example \??\C:\foo is equivalent to common C:\foo.
The Clean, IsAbs, IsLocal, and VolumeName functions did not
recognize root local device paths beginning with \??\.
Clean could convert a rooted path such as \a\..\??\b into
the root local device path \??\b. It will now convert this
path into .\??\b.
IsAbs now correctly reports paths beginning with \??\
as absolute.
IsLocal now correctly reports paths beginning with \??\
as non-local.
VolumeName now reports the \??\ prefix as a volume name.
Join(`\`, `??`, `b`) could convert a seemingly innocent
sequence of path elements into the root local device path
\??\b. It will now convert this to \.\??\b.
In addition, the IsLocal function did not correctly
detect reserved names in some cases:
- reserved names followed by spaces, such as "COM1 ".
- "COM" or "LPT" followed by a superscript 1, 2, or 3.
IsLocal now correctly reports these names as non-local.
Fixes#63713
Fixes CVE-2023-45283
Fixes CVE-2023-45284
Change-Id: I446674a58977adfa54de7267d716ac23ab496c54
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2040691
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/540277
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
Currently, http.ServeContent returns invalid Content-Length header if:
* Request is a range request.
* Content is encoded (e.g., gzip compressed).
* Content-Length of the encoded content has been set before calling
http.ServeContent, as suggested in https://github.com/golang/go/issues/19420.
Example:
w.Header().Set("Content-Type", "application/json")
w.Header().Set("Content-Length", strconv.Itoa(len(compressedJsonBody)))
w.Header().Set("Content-Encoding", "gzip")
w.Header().Set("Etag", etag)
http.ServeContent(
w, req, "", time.Time{},
bytes.NewReader(compressedJsonBody),
)
The issue is that http.ServeContent currently sees Content-Length as
something optional when Content-Encoding is set, but that is a problem
with range request which can send a payload of different size. So this
reverts https://go.dev/cl/4538111 and makes Content-Length be set
always to the number of bytes which will actually be send (both for
range and non-range requests).
Without this fix, this is an example response:
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Encoding: gzip
Content-Length: 351
Content-Range: bytes 100-350/351
Content-Type: application/json; charset=UTF-8
Etag: "amCTP_vgT5PQt5OsAEI7NFJ6Hx1UfEpR5nIaYEInfOA"
Date: Sat, 29 Jan 2022 14:42:15 GMT
As you see, Content-Length is invalid and should be 251.
Change-Id: I4d2ea3a8489a115f92ef1f7e98250d555b47a94e
GitHub-Last-Rev: 3aff9126f5
GitHub-Pull-Request: golang/go#50904
Reviewed-on: https://go-review.googlesource.com/c/go/+/381956
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: t hepudds <thepudds1460@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
ReadMetricsSlow was updated to call the core of readMetrics on the
systemstack to prevent issues with stat skew if the stack gets moved
between readmemstats_m and readMetrics. However, readMetrics calls into
the map implementation, which has race instrumentation. The system stack
typically has no racectx set, resulting in crashes.
Donate racectx to g0 like the tracer does, so that these accesses don't
crash.
For #60607.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-race
Change-Id: Ic0251af2d9b60361f071fe97084508223109480c
Reviewed-on: https://go-review.googlesource.com/c/go/+/539695
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently it's possible (and even probable, with mayMoreStackMove mode)
for a stack allocation to occur between readmemstats_m and readMetrics
in ReadMetricsSlow. This can cause tests to fail by producing metrics
that are inconsistent between the two sources.
Fix this by breaking out the critical section of readMetrics and calling
that from ReadMetricsSlow on the systemstack. Our main constraint in
calling readMetrics on the system stack is the fact that we can't
acquire the metrics semaphore from the system stack. But if we break out
the critical section, then we can acquire that semaphore before we go on
the system stack.
While we're here, add another readMetrics call before readmemstats_m.
Since we're being paranoid about ways that metrics could get skewed
between the two calls, let's eliminate all uncertainty. It's possible
for readMetrics to allocate new memory, for example for histograms, and
fail while it's reading metrics. I believe we're just getting lucky
today with the order in which the metrics are produced. Another call to
readMetrics will preallocate this data in the samples slice. One nice
thing about this second read is that now we effectively have a way to
check if readMetrics really will allocate if called a second time on the
same samples slice.
Fixes#60607.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: If6ce666530903239ef9f02dbbc3f1cb6be71e425
Reviewed-on: https://go-review.googlesource.com/c/go/+/539117
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 233437 added a redactedURL field to proxyRepo, a struct that already
had a field named 'url'. Neither fields were documented, so the similar
names suggest the most natural interpretation that proxyRepo.redactedURL
is equivalent to proxyRepo.url.Redacted() rather than something else.
That's possibly why it was joined with the module version in CL 406675.
It turns out the two URLs differ in more than just redaction: one is the
base proxy URL with (escaped) module path joined, the other is just the
base proxy URL, in redacted form.
Document and rename the fields to make the distinction more clear, and
include all 3 of base module proxy URL + module path + module version
in the reported URL, rather than just the first and third bits as seen
in the errors at https://go.dev/issue/51323#issuecomment-1735812250.
For #51323.
Updates #38680.
Updates #52727.
Change-Id: Ib4b134b548adeec826ee88fe51a2cf580fde0516
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/532035
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
CL 520535 added the new OID type, and the Certificate field Policies to
replace PolicyIdentifiers. During review I missed three problems: (1)
the marshaling of Certificate didn't take into account the case where
both fields were populated with the same OIDs (which would be the case
if you parsed a certificate and used it as a template), (2)
buildCertExtensions only generated the certificate policies extension if
PolicyIdentifiers was populated, and (3) how we would marshal an empty
OID (i.e. OID{}).
This change makes marshaling a certificate with an empty OID an error,
and only adds a single copy of any OID that appears in both Policies and
PolicyIdentifiers to the certificate policies extension. This should
make the round trip behavior for certificates reasonable.
Additionally this change documents that CreateCertificate uses the
Policies field from the template, and fixes buildCertExtensions to
populate the certificate policies extension if _either_
PolicyIdentifiers or Policies is populated, not just PolicyIdentifiers.
Fixes#63909
Change-Id: I0fcbd3ceaab7a376e7e991ff8b37e2145ffb4a61
Reviewed-on: https://go-review.googlesource.com/c/go/+/539297
Reviewed-by: Mateusz Poliwczak <mpoliwczak34@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The latest version of Wasmtime, 14.0.4 as of writing this, offers a new
CLI while also supporting the old CLI. Since this is known and tracked
in issue #63718, silence the warning that otherwise causes many tests
to fail.
Since Wasmtime 13 and older don't pay attention to WASMTIME_NEW_CLI,
this change increases compatibility of the script, letting it work
with Wasmtime 9.0.1 as currently tested by the old cmd/coordinator, and
with Wasmtime 14.0.4 as currently tested in the new LUCI infrastructure.
The rest of the transition is left as future work.
For #63718.
For #61116.
Change-Id: I77d4f74cc1d34a657e48dcaaceb6fbda7d1e9428
Cq-Include-Trybots: luci.golang.try:gotip-wasip1-wasm_wasmtime
Reviewed-on: https://go-review.googlesource.com/c/go/+/538699
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Tests in rlimit_test.go exist to test the behavior of automatically
bumping RLIMIT_NOFILE on Unix implemented in rlimit.go (issue #46279),
with darwin-specific behavior split out into rlimit_darwin.go and
the rest left empty in rlimit_stub.go.
Since the behavior happens only on Unix, it doesn't make sense to test
it on other platforms. Copy rlimit.go's 'unix' build constraint to
rlimit_test.go to accomplish that.
Also simplify the build constraint in rlimit_stub.go while here,
so that its maintenance is easier and it starts to match all
non-darwin Unix GOOS values (previously, 'hurd' happened to be missed).
In particular, this fixes a problem where TestOpenFileLimit was
failing in some environments when testing the wasip1/wasm port.
The RLIMIT_NOFILE bumping behavior isn't implemented there, so
the test was testing the environment and not the Go project.
Updates #46279.
For #61116.
Change-Id: Ic993f9cfc021d4cda4fe3d7fed8e2e180f78a2ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/539435
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
When selecting the hottest edge to use for PGO-based devirtualization,
edges are order by:
1. Edge weight
2. If weights are equal, prefer the edge with IR available in the
package.
3. Otherwise, simply sort lexicographically.
The existing logic for (2) is incomplete.
If the hottest edge so far is missing IR, but the new edge has IR, then
it works as expected and selects the new edge.
But if the hottest edge so far has IR and the new edge is missing IR, we
want to always keep the hottest edge so far, but this logic will fall
through and use lexicographical ordering instead.
Adjust the check to always make an explicit choice when IR availability
differs.
Change-Id: Ia7fcc286aa9a62ac209fd978cfce60463505f4cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/539475
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Go 1.21 and earlier do not understand this line, causing
"go mod vendor" of //go:build go1.22-tagged code that
uses this feature to fail.
The solution is to include the go/build change to skip over
the line in Go 1.22 (making "go mod vendor" from Go 1.22 onward
work with this change) and then wait to deploy the cgo change
until Go 1.23, at which point Go 1.21 and earlier will be unsupported.
For #56378.
Fixes#63293.
Change-Id: Ifa08b134eac5a6aa15d67dad0851f00e15e1e58b
Reviewed-on: https://go-review.googlesource.com/c/go/+/539235
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Since CL 226138, TestNohup has a bit of a strange construction: it wants
to run the "uncaught" subtests in parallel with each other, and the
"nohup" subtests in parallel with each other, but also needs join
between "uncaught" and "nohop" so it can Stop notifying for SIGHUP.
It achieves this by doing `go t.Run` with a WaitGroup rather than using
`t.Parallel` in the subtest (which would make `t.Run` return immediately).
However, this makes things more difficult to understand than necessary.
As noted on https://pkg.go.dev/testing#hdr-Subtests_and_Sub_benchmarks,
a second layer of subtest can be used to join parallel subtests.
Switch to this form, which makes the test simpler to follow
(particularly the cleanup that goes with "uncaught").
For #63799.
Change-Id: Ibfce0f439508a7cfca848c7ccfd136c9c453ad8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/538899
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This is a port of CL 538856 from the syntax parser to go/parser.
As part of the port, make more portions of parseParameterList
matching the equivalent paramList method (from the syntax parser).
As a result, this now also produces a better error message in cases
where the missing piece might not be a type parameter name but a
constraint (this fixes a TODO in a test).
Improve comments in the code and adjust the corresponding comments
in the syntax parser.
Change references to issues to use the format go.dev/issue/ddddd.
For #60812.
Change-Id: Ia243bd78161ed8543d3dc5deb20ca4a215c5b1e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/538858
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
OpenBSD 6.3 is more than five years old and has not been supported for
the last four years (only 7.3 and 7.4 are currently supported). As such,
remove special handling of MAP_STACK for 6.3 and earlier.
Change-Id: I1086c910bbcade7fb3938bb1226813212794b587
Reviewed-on: https://go-review.googlesource.com/c/go/+/538458
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Aaron Bieber <aaron@bolddaemon.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
Prior to CL 460595, Lstat reported most reparse points as regular
files. However, reparse points can in general implement unusual
behaviors (consider IO_REPARSE_TAG_AF_UNIX or IO_REPARSE_TAG_LX_CHR),
and Windows allows arbitrary user-defined reparse points, so in
general we must not assume that an unrecognized reparse tag represents
a regular file; in CL 460595, we began marking them as irregular.
As it turns out, the Data Deduplication service on Windows Server runs
an Optimization job that turns regular files into reparse files with
the tag IO_REPARSE_TAG_DEDUP. Those files still behave more-or-less
like regular files, in that they have well-defined sizes and support
random-access reads and writes, so most programs can treat them as
regular files without difficulty. However, they are still reparse
files: as a result, on servers with the Data Deduplication service
enabled, files could arbitrarily change from “regular” to “irregular”
without explicit user intervention.
Since dedup files are converted in the background and otherwise behave
like regular files, this change adds a special case to report DEDUP
reparse points as regular.
Fixes#63429.
No test because to my knowledge we don't have any Windows builders
that have the deduplication service enabled, nor do we have a way to
reliably guarantee the existence of an IO_REPARSE_TAG_DEDUP file.
(In theory we could add a builder with the service enabled on a
specific volume, write a test that encodes knowledge of that volume,
and use the GO_BUILDER_NAME environment variable to run that test only
on the specially-configured builders. However, I don't currently have
the bandwidth to reconfigure the builders in this way, and given the
simplicity of the change I think it is unlikely to regress
accidentally.)
Change-Id: I649e7ef0b67e3939a980339ce7ec6a20b31b23a1
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/537915
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
When parsing a declaration of the form
type a [b[c]]d
where a, b, c, d stand for identifiers, b[c] is parsed as a type
constraint (because an array length must be constant and an index
expression b[c] is never constant, even if b is a constant string
and c a constant index - this is crucial for disambiguation of the
various possibilities).
As a result, the error message referred to a missing type parameter
name and not an invalid array declaration.
Recognize this special case and report both possibilities (because
we can't be sure without type information) with the new error:
"missing type parameter name or invalid array length"
ALso, change the previous error message
"type parameter must be named"
to
"missing type parameter name"
which is more fitting as the error refers to an absent type parameter
(rather than a type parameter that's somehow invisibly present but
unnamed).
Fixes#60812.
Change-Id: Iaad3b3a9aeff9dfe2184779f3d799f16c7500b34
Reviewed-on: https://go-review.googlesource.com/c/go/+/538856
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Have nil checks return a pointer that is known non-nil. Users of
that pointer can use the result, ensuring that they are ordered
after the nil check itself.
The order dependence goes away after scheduling, when we've fixed
an order. At that point we move uses back to the original pointer
so it doesn't change regalloc any.
This prevents pointer arithmetic on nil from being spilled to the
stack and then observed by a stack scan.
Fixes#63657
Change-Id: I1a5fa4f2e6d9000d672792b4f90dfc1b7b67f6ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/537775
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
On some platforms (notably OpenBSD), stacks must be specifically allocated
and marked as being stack memory. Allocate the crash stack using stackalloc,
which ensures these requirements are met, rather than using a global Go
variable.
Fixes#63794
Change-Id: I6513575797dd69ff0a36f3bfd4e5fc3bd95cbf50
Reviewed-on: https://go-review.googlesource.com/c/go/+/538457
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We do the same elsewhere (e.g. in parser.name when a name is missing).
This ensures functions have a (dummy) name and a non-nil type.
Avoids a crash in the type-checker (verified manually).
A test was added here (rather than the type checker) because type-
checker tests are shared between types2 and go/types and error
recovery in this case is different.
Fixes#63835.
Change-Id: I1460fc88d23d80b8d8c181c774d6b0a56ca06317
Reviewed-on: https://go-review.googlesource.com/c/go/+/538059
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
pkgsite and go doc print the doc comment *after* the code, resulting in:
const (
LevelDebug Level = -4
...
)
Many paragraphs...
Names for common levels.
The "Names for common levels." feels out of place and confusing at the bottom.
This is also consistent with the recommendation for the first sentence in doc comments to be the "summary".
Change-Id: I656e85e27d2a4b23eaba5f2c1f4f811a88848c83
GitHub-Last-Rev: d9f7ee9b94
GitHub-Pull-Request: golang/go#61943
Reviewed-on: https://go-review.googlesource.com/c/go/+/518537
Reviewed-by: Alan Donovan <alan@alandonovan.net>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: qiulaidongfeng <2645477756@qq.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
The compiler is currently sign extending 32 bit signed integers to
64 bits before right shifting them using a 64 bit shift instruction.
There's no need to do this as RISC-V has instructions for right
shifting 32 bit signed values (sraw and sraiw) which sign extend
the result of the shift to 64 bits. Change the compiler so that
it uses sraw and sraiw for shifts of signed 32 bit integers reducing
in most cases the number of instructions needed to perform the shift.
Here are some examples of code sequences that are changed by this
patch:
int32(a) >> 2
before:
sll x5,x10,0x20
sra x10,x5,0x22
after:
sraw x10,x10,0x2
int32(v) >> int(s)
before:
sext.w x5,x10
sltiu x6,x11,64
add x6,x6,-1
or x6,x11,x6
sra x10,x5,x6
after:
sltiu x5,x11,32
add x5,x5,-1
or x5,x11,x5
sraw x10,x10,x5
int32(v) >> (int(s) & 31)
before:
sext.w x5,x10
and x6,x11,63
sra x10,x5,x6
after:
and x5,x11,31
sraw x10,x10,x5
int32(100) >> int(a)
before:
bltz x10,<target address calls runtime.panicshift>
sltiu x5,x10,64
add x5,x5,-1
or x5,x10,x5
li x6,100
sra x10,x6,x5
after:
bltz x10,<target address calls runtime.panicshift>
sltiu x5,x10,32
add x5,x5,-1
or x5,x10,x5
li x6,100
sraw x10,x6,x5
int32(v) >> (int(s) & 63)
before:
sext.w x5,x10
and x6,x11,63
sra x10,x5,x6
after:
and x5,x11,63
sltiu x6,x5,32
add x6,x6,-1
or x5,x5,x6
sraw x10,x10,x5
In most cases we eliminate one instruction. In the case where
we shift a int32 constant by a variable the number of instructions
generated is identical. A sra is simply replaced by a sraw. In the
unusual case where we shift right by a variable anded with a constant
> 31 but < 64, we generate two additional instructions. As this is
an unusual case we do not try to optimize for it.
Some improvements can be seen in some of the existing benchmarks,
notably in the utf8 package which performs right shifts of runes
which are signed 32 bit integers.
| utf8-old | utf8-new |
| sec/op | sec/op vs base |
EncodeASCIIRune-4 17.68n ± 0% 17.67n ± 0% ~ (p=0.312 n=10)
EncodeJapaneseRune-4 35.34n ± 0% 34.53n ± 1% -2.31% (p=0.000 n=10)
AppendASCIIRune-4 3.213n ± 0% 3.213n ± 0% ~ (p=0.318 n=10)
AppendJapaneseRune-4 36.14n ± 0% 35.35n ± 0% -2.19% (p=0.000 n=10)
DecodeASCIIRune-4 28.11n ± 0% 27.36n ± 0% -2.69% (p=0.000 n=10)
DecodeJapaneseRune-4 38.55n ± 0% 38.58n ± 0% ~ (p=0.612 n=10)
Change-Id: I60a91cbede9ce65597571c7b7dd9943eeb8d3cc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/535115
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: M Zhuo <mzh@golangcn.org>
Reviewed-by: David Chase <drchase@google.com>
Int31 -> Int32
Int31n -> Int32N
Int63 -> Int64
Int63n -> Int64N
Intn -> IntN
The 31 and 63 are pedantic and confusing: the functions should
be named for the type they return, same as all the others.
The lower-case n is inconsistent with Go's usual CamelCase
and especially problematic because we plan to add 'func N'.
Capitalize the n.
For #61716.
Change-Id: Idb1a005a82f353677450d47fb612ade7a41fde69
Reviewed-on: https://go-review.googlesource.com/c/go/+/516857
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TestPGOHash may rebuild dependencies as we pass -trimpath to the
go command. This CL makes it pass -trimpath compiler flag to only
the current package instead, as we only need the current package
to have a stable source file path.
Also refactor buildPGOInliningTest to only take compiler flags,
not go flags, to avoid accidental rebuild.
Should fix#63733.
Change-Id: Iec6c4e90cf659790e21083ee2e697f518234c5b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/535915
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Error like "morestack on g0" is one of the errors that is very
hard to debug, because often it doesn't print a useful stack trace.
The runtime doesn't directly print a stack trace because it is
a bad stack state to call print. Sometimes the SIGABRT may trigger
a traceback, but sometimes not especially in a cgo binary. Even if
it triggers a traceback it often does not include the stack trace
of the bad stack.
This CL makes it explicitly print a stack trace and throw. The
idea is to have some space as an "emergency" crash stack. When the
stack is in a really bad state, we switch to the crash stack and
do a traceback.
Currently only implemented on AMD64 and ARM64.
TODO: also handle errors like "morestack on gsignal" and bad
systemstack. Also handle other architectures.
Change-Id: Ibfc397202f2bb0737c5cbe99f2763de83301c1c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/419435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Pull in CL 500335. It teaches modfile.IsDirectoryPath to recognize all
relative paths that begin with a "." or ".." path element as a valid
directory path (rather than a module path). This allows removing the
path == "." check that CL 389298 added to modload.ToDirectoryPath.
go get golang.org/x/mod@6e58e47c # CL 500335
go mod tidy
go mod vendor
Updates #51448.
Fixes#60572.
Change-Id: Ide99c728c8dac8fd238e13f6d6a0c3917d7aea2d
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/500355
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
After CL 527715, needm uses callbackUpdateSystemStack to set the stack
bounds for g0 on an M from the extra M list. Since
callbackUpdateSystemStack is also used for recursive cgocallback, it
does nothing if the stack is already in bounds.
Currently, the stack bounds in an extra M may contain stale bounds from
a previous thread that used this M and then returned it to the extra
list in dropm.
Typically a new thread will not have an overlapping stack with an old
thread, but because the old thread has exited there is a small chance
that the C memory allocator will allocate the new thread's stack
partially or fully overlapping with the old thread's stack.
If this occurs, then callbackUpdateSystemStack will not update the stack
bounds. If in addition, the overlap is partial such that SP on
cgocallback is close to the recorded stack lower bound, then Go may
quickly "overflow" the stack and crash with "morestack on g0".
Fix this by clearing the stack bounds in dropm, which ensures that
callbackUpdateSystemStack will unconditionally update the bounds in
needm.
For #62440.
Change-Id: Ic9e2052c2090dd679ed716d1a23a86d66cbcada7
Reviewed-on: https://go-review.googlesource.com/c/go/+/537695
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.com>
As spotted by staticcheck, the body did keep track of errors by sharing
a single err variable, but its last value was never used as the function
simply finished by returning nil.
To prevent postDecode from erroring on empty profiles,
which breaks TestEmptyProfile, add a check at the top of the function.
Update the runtime/pprof test accordingly,
since the default units didn't make sense for an empty profile anyway.
Change-Id: I188cd8337434adf9169651ab5c914731b8b20f39
Reviewed-on: https://go-review.googlesource.com/c/go/+/483137
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This implements the approach I described in
https://go-review.git.corp.google.com/c/go/+/494057/1#message-5c9773bded2f89b4058848cb036b860aa6716de3.
Specifically:
- Each level of test atomically records the cumulative number of races
seen as of the last race-induced test failure.
- When a subtest fails, it logs the race error, and then updates its
parents' counters so that they will not log the same error.
- We check each test or benchmark for races before it starts running
each of its subtests or sub-benchmark, before unblocking parallel
subtests, and after running any cleanup functions.
With this implementation, it should be the case that every test that
is running when a race is detected reports that race, and any race
reported for a subtest is not redundantly reported for its parent.
The regression tests are based on those added in CL 494057 and
CL 501895, with a few additions based on my own review of the code.
Fixes#60083.
Change-Id: I578ae929f192a7a951b31b17ecb560cbbf1ef7a1
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-amd64-longtest-race,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/506300
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The goroutine profile has close to three code paths for adding a
goroutine record to the goroutine profile: one for the goroutine that
requested the profile, one for every other goroutine, plus some special
handling for the finalizer goroutine. The first of those captured the
goroutine stack, but neglected to include that goroutine's labels.
Update the tests to check for the inclusion of labels for all three
types of goroutines, and include labels for the creator of the goroutine
profile.
For #63712
Change-Id: Id5387a5f536d3c37268c240e0b6db3d329a3d632
Reviewed-on: https://go-review.googlesource.com/c/go/+/537515
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Rhys Hiltner <rhys@justin.tv>
Reviewed-by: David Chase <drchase@google.com>
The new noescape and nocallback directives can be used instead of the C
wrapper functions that are there just to avoid some parameters being
escaped to the heap.
This CL also helps demonstrate the use of the new directives in real
code.
I've added some benchmarks to demonstrate that this CL doesn't
introduce new heap allocations when using boringcrypto:
```
goos: linux
goarch: amd64
pkg: crypto/aes
cpu: AMD EPYC 7763 64-Core Processor
BenchmarkGCMSeal-32 8378692 143.3 ns/op 111.65 MB/s 0 B/op 0 allocs/op
BenchmarkGCMOpen-32 8383038 142.7 ns/op 112.11 MB/s 0 B/op 0 allocs/op
```
Change-Id: Ifd775484eb9a105afc5c3d4e75a6c6655cbadc53
Reviewed-on: https://go-review.googlesource.com/c/go/+/525035
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 473415 allowed 5 more threads in TestWindowsStackMemory, to cover
sysmon and any new threads in future. However, during go1.22 dev cycle,
the test becomes flaky again, failing in windows-386 builder a couple of
times in CL 535975 and CL 536175 (and maybe others that haven't caught).
This CL increases the extra threads from 5 to 10, hopefully to make the
test stable again for windows-386. The theory is that Go process load a
bunch of DLLs, which may start their own threads. We could investigate
more deeply if the test still be flaky with 10 extra threads.
Fixes#58570
Change-Id: I255d0d31ed554859a5046fa76dfae1ba89a89aa3
Reviewed-on: https://go-review.googlesource.com/c/go/+/536058
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Refactor maskgen into decodeMask32. This is derived from
from combining encodePPC64RotateMask and isWordRotateMask.
Also, truncate me returned from decodeMask32/64 to
be within range of [0,32/64).
Change-Id: Ie9efff93d400b3066ac85276b1ad3c57c2fcf31b
Reviewed-on: https://go-review.googlesource.com/c/go/+/536298
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
RtlGenRandom is a semi-undocumented API, also known as
SystemFunction036, which we use to generate random data on Windows.
It's definition, in cryptbase.dll, is an opaque wrapper for the
documented API ProcessPrng. Instead of using RtlGenRandom, switch to
using ProcessPrng, since the former is simply a wrapper for the latter,
there should be no practical change on the user side, other than a minor
change in the DLLs we load.
Change-Id: Ie6891bf97b1d47f5368cccbe92f374dba2c2672a
Reviewed-on: https://go-review.googlesource.com/c/go/+/536235
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
One of the remaining uses of the old +build syntax was in the bundled
copy of golang.org/x/net/http2 in net/http. Pull in a newer version of
bundle with CL 536075 that drops said +build syntax line. Also pull in
newer x/sys and other golang.org/x modules where old +build lines were
recently dropped.
Generated with:
go install golang.org/x/build/cmd/updatestd@latest
go install golang.org/x/tools/cmd/bundle@latest
updatestd -goroot=$(pwd) -branch=master
For #36905.
For #41184.
For #60268.
Change-Id: Ia18d1ce9eadce85b38176058ad1fe38562b004e9
Cq-Include-Trybots: luci.golang.try:gotip-linux-386-longtest,gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/536575
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Most of the test cases in the test directory use the new go:build syntax
already. Convert the rest. In general, try to place the build constraint
line below the test directive comment in more places.
For #41184.
For #60268.
Change-Id: I11c41a0642a8a26dc2eda1406da908645bbc005b
Cq-Include-Trybots: luci.golang.try:gotip-linux-386-longtest,gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/536236
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL separates running shell commands and doing shell-like
operations out of the Builder type and into their own, new Shell type.
Shell is responsible for tracking output streams and the Action that's
running commands. Shells form a tree somewhat like Context, where new
Shells can be derived from a root shell to adjust their state.
The primary intent is to support "go build -json", where we need to
flow the current package ID down to the lowest level of command output
printing. Shell gives us a way to easily flow that context down.
However, this also puts a clear boundary around how we run commands,
removing this from the rather large Builder abstraction.
For #62067.
Change-Id: Ia9ab2a2d7cac0269ca627bbb316dbd9610bcda44
Reviewed-on: https://go-review.googlesource.com/c/go/+/535016
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Currently, Builder.fmtcmd can read scriptDir without taking the output
lock. This introduces a potential data race between the read in fmtcmd
and the write in Showcmd. There's also a logical race here: because
fmtcmd doesn't know when its output is going to be printed, Showcmd
may print a "cd" command between when fmtcmd is called and when its
output is printed. As a result, it doesn't make sense to just lock
around the access in fmtcmd.
Instead, move the entire scriptDir substitution to Showcmd. This will
generally result in the same output. In the cases where Builder.run is
called with a non-empty desc, it means we may print a full path in the
comment line above output rather than substituting the script
directory. I think this is okay.
This lets us undo the workaround in CL 536355.
Change-Id: I617fe136eaafcc9bbb7e701b427d956aeab8a2b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/536376
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Currently, cmdError makes a somewhat fuzzy attempt to ensure the
package import path is part of the printed error, using a string
prefix check. Also, if it decides it does need to add the import path,
it prints it as a "go build" line, which could be misleading because
it can happen outside of "go build".
Clean up the whole code path by explicitly checking the provided error
description against Package.Desc(), and instead of emitting "go build"
in the error message, print it as "# importPath" just like we do in
the common case.
Change-Id: Idb61ac8ffd6920a3d2d282697f4d7d5555ebae0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/534655
Auto-Submit: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
CL 529219 made an existing race with accessing Builder.scriptDir from
Builder.fmtcmd (and now also Builder.Showcmd) much more likely by
dropping a theoretically unnecessary condition from the call from
Builder.run to Builder.fmtcmd.
For an example race report, see
https://build.golang.org/log/c3cad62d0fc33a8381d2091661c685ea1fc525c4
The race is between
(*Builder).cover2() -> (*Builder).run() -> (*Builder).fmtcmd()
and various other call paths of the form
(*Builder).build() -> (*gcToolchain).* (*Builder).Showcmd() -> (*Builder).fmtcmd()
The race can be reproduced with
go install -race cmd/go
stress -p 1 go test -x -cover -a log
Return this race to its existing likelihood by putting the condition
back. This isn't a "correct" solution because the race could still
happen if the "cover" tool invoked by Builder.cover2 emits output. But
this will do for a temporary fix.
Change-Id: Ifd811dea07f05e1422fd02b63cd958627727aa12
Reviewed-on: https://go-review.googlesource.com/c/go/+/536355
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The documentation of readvarintUnsafe claims itself and readvarint are
duplicated. However, two implementation are not in synced, since when
readvarint got some minor improvements in CL 43150.
Updating readvarintUnsafe to match readvarint implementation to gain a
bit of speed. While at it, also updating its documentation to clarify
the main difference.
name time/op
ReadvarintUnsafe/old-8 6.04ns ± 2%
ReadvarintUnsafe/new-8 5.31ns ± 3%
Change-Id: Ie1805d0747544f69de88f6ba9d1b3960f80f00e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/535815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The funcdata is encoded as varint, with the upper limit set to 1e9.
However, the stack offsets could be up to 1<<30. Thus emitOpenDeferInfo
will trigger an ICE for function with large frame size.
By using binary.PutUvarint, the frame offset could be encoded correctly
for value larger than 1<<35, allow the compiler to report the error.
Further, the runtime also do validation when reading in the funcdata
value, so a bad offset won't likely cause mis-behavior.
Fixes#52697
Change-Id: I084c243c5d24c5d31cc22d5b439f0889e42b107c
Reviewed-on: https://go-review.googlesource.com/c/go/+/535077
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
In the PPC64 ISA, the instruction to do an 'and' operation
using an immediate constant is only available in the form that
also sets CR0 (i.e. clobbers the condition register.) This means
CR0 is being clobbered unnecessarily in many cases. That
affects some decisions made during some compiler passes
that check for it.
In those cases when the constant used by the ANDCC is a right
justified consecutive set of bits, a shift instruction can
be used which has the same effect if CR0 does not need to be
set. The rule to do that has been added to the late rules file
after other rules using ANDCCconst have been processed in the
main rules file.
Some codegen tests had to be updated since ANDCC is no
longer generated for some cases. A new test case was added to
verify the ANDCC is present if the results for both the AND
and CR0 are used.
Change-Id: I304f607c039a458e2d67d25351dd00aea72ba542
Reviewed-on: https://go-review.googlesource.com/c/go/+/531435
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Jayanth Krishnamurthy <jayanth.krishnamurthy@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
CL 529219 tweaked the list_pkgconfig_error script test currently to
expect pkg-config to fail with "Package .* not found$", but on several
OSes (at least OpenBSD, AIX, and Solaris), pkg-config prints "Package
libnot-a-valid-cgo-library was not found in the pkg-config search
path". Fix the test on these OSes by dropping the "$" so the test
doesn't require the line to end with "not found".
Change-Id: I40c577521f34c360a1d62355596958f6f969eb54
Reviewed-on: https://go-review.googlesource.com/c/go/+/536195
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
There are several functions that take both an Action argument and a
Package argument. It takes a decent amount of work to determine that
in all cases the value of the Package argument is just Action.Package.
This makes these Package arguments both redundant and potentially
confusing because it makes these APIs look like they have more
flexibility than they actually do.
Drop these unnecessary Package arguments.
For #62067.
Change-Id: Ibd3295cf6a79d95ceb421d60671f87e023517f8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/536095
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, fmtcmd may have the side effect of updating
Builder.scriptDir, the logical working directory of the printed
script. If it does so, it also returns a two line command consisting
of both a "cd" into the new scriptDir and the original command.
When fmtcmd is used as part of Showcmd, that's fine, but fmtcmd is
also used in a handful of places to construct command descriptions
that are ultimately passed to Builder.reportCmd. In these cases, it's
surprising that fmtcmd has any side effects, but the bigger problem is
that reportCmd isn't expecting a two-line description and will print
it wrong in the output.
One option is to fix printing multi-line descriptions in reportCmd,
but we can fix the surprise side effect too by instead moving the
working directory update to Showcmd. With this CL, fmtcmd merely
consults the working directory to shorten it in the output and does
not update it.
For #62067.
Change-Id: I7808b279a430551f4ba51545417adf0bb132f931
Reviewed-on: https://go-review.googlesource.com/c/go/+/534857
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>
The general pattern is to replace
if len(cmdOut) > 0 {
output := b.processOutput(cmdOut)
if err != nil {
err = formatOutput(b.WorkDir, dir, p.ImportPath, desc, output)
} else {
b.showOutput(a, dir, desc, output)
}
}
if err != nil {
return err
}
with
if err := b.reportCmd(a, p, desc, dir, cmdOut, err); err != nil {
return err
}
However, there is a fair amount of variation between call sites. The
most common non-trivial variation is sites where errors are an
expected outcome. In this case, often we simply pass "nil" for the
error to trigger only the printing behavior of reportCmd.
For #62067, but also a nice cleanup on its own.
Change-Id: Ie5f918017c02d8558f23ad4c38261077c0fa4ea3
Reviewed-on: https://go-review.googlesource.com/c/go/+/529219
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Many uses of showOutput, formatOutput, and processOutput follow a very
similar (somewhat complex) pattern. Places that diverge from this
pattern are often minor bugs. Furthermore, the roles of formatOutput
and processOutput have somewhat blurred over time; e.g., formatOutput
performs directory shortening, while processOutput performs cgo
demangling.
This CL consolidates all of this logic into a single, new function:
Builder.reportCmd.
In the following CL, we'll replace all calls of the three original
functions with reportCmd.
In addition to being a nice cleanup, this puts us in a much better
position to change how build output is formatted in order to support
`go build -json`.
For #62067.
Change-Id: I733162825377d82d0015c8aae2820e56a1b32958
Reviewed-on: https://go-review.googlesource.com/c/go/+/529218
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The current output for empty declarations such as var, const, import
results in "var", "const", "import" respectively. These are not valid
and the parser will promptly reject them as invalid syntax.
This CL updates this behavior by adding "()" to the output of empty
decls so the syntax becomes valid, e.g "var ()" instead of "var".
Fixes#63566
Change-Id: I571b182d9ccf71b159360c8de003ad55d0ff3443
GitHub-Last-Rev: 2720419e36
GitHub-Pull-Request: golang/go#63593
Reviewed-on: https://go-review.googlesource.com/c/go/+/535995
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com>
We need to track the brace depth for each individual nested expression,
since a string interpolation expression may be nested inside of an
object.
e.g. `${ {1:`${}`}}` has brace depths [1, 0] when inside of the inner
${} expression. When we exit the inner expression, we need to reset to
the previous brace depth (1) so that we know that the following } closes
the object, but not the outer expression.
Note that if you write a broken expression (i.e. `${ { }`) escaping will
clearly not work as expected (or depending on your interpretation, since
it is broken, it will work as expected). Since the JS parser doesn't
catch syntax errors, it's up to the user to write a valid template.
Updates #61619
Change-Id: I4c33723d12aff49facdcb1134d9ca82b7a0dffc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/532995
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Construction of Profile is getting more complex. Currently, we construct
a partial Profile and then use methods to slowly complete the structure.
This can hide dependencies and make refactoring fragile as the
requirements and outputs of the methods is not clearly specified.
Refactor construction to build the Profile only once all of the parts
are complete. The intermediate states explicitly pass input and outputs
as arguments.
Additionally, rename Profile.NodeMap to NamedEdgeMap to make its
contents more clear (edges, specified by caller/callee name rather than
IR). Remove the node flat/cumulative weight from this map; they are
unused.
Change-Id: I2079cd991daac6398d74375b04dfe120b473d908
Reviewed-on: https://go-review.googlesource.com/c/go/+/529558
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Today, the PGO IR graph only contains entries for ir.Func loaded into
the package. This can include functions from transitive dependencies,
but only if they happen to be referenced by something in the current
package. If they are not referenced, noder never bothers to load them.
This leads to a deficiency in PGO devirtualization: some callee methods
are available in transitive dependencies but do not devirtualize because
they happen to not get loaded from export data.
Resolve this by adding an explicit lookup from export data of callees
mentioned in the profile.
I have chosen to do this during loading of the profile for simplicity:
the PGO IR graph always contains all of the functions we might need.
That said, it isn't strictly necessary. PGO devirtualization could do
the lookup lazily if it decides it actually needs a method. This saves
work at the expense of a bit more complexity, but I've chosen the
simpler approach for now as I measured the cost of this as significantly
less than the rest of PGO loading.
For #61577.
Change-Id: Ieafb2a549510587027270ee6b4c3aefd149a901f
Reviewed-on: https://go-review.googlesource.com/c/go/+/497175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If trampolines may be required, the current text addressing second
pass resets all assigned addresses, before assigning addresses and
laying down trampolines in a linear fashion. However, this approach
means that intra-package calls are to a symbol that has not yet
been assigned an address, when the symbol is ahead of the current
function.
In the case of RISC-V the JAL instruction is limited to +/-1MiB.
As such, if a call is to a symbol with no address currently assigned,
we have to assume that a trampoline will be required. During the
relocation phase we can fix up and avoid trampolines in some cases,
however this results in unused trampolines that are still present
in the binary (since removing them would change text addresses).
In order to significantly reduce the number of unused trampolines,
assign temporary addresses to functions within the same package,
based on the maximum number of trampolines that may be required by
a function. This allows for better decisions to be made regarding
the requirement for intra-package trampolines, as we reset the
addressing for a function, assign its final address and lay down
any resulting trampolines.
This results in ~2,300 unused trampolines being removed from the
Go binary and ~5,600 unused trampolines being removed from the
compile binary, on linux/riscv64.
This reapplies CL 349650, however does not pass big to assignAddress
when assigning temporary addresses, as this can result in side
effects such as section splitting.
Change-Id: Id7febdb65d962d6b1297a91294a8dc27c94d8696
Reviewed-on: https://go-review.googlesource.com/c/go/+/534760
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The system stack often starts with a stack transition function
like "systemstack" or "mcall", which is marked as SPWRITE. When
unwinding a system stack for printing, we want the traceback stop
at the stack switching frame, but not print the "unexpected
SPWRITE" message.
Previously before CL 525835, we don't print the "unexpected
SPWRITE" message if unwindPrintErrors is set, i.e. printing a
stack trace. This CL restores this behavior.
Another possibility is not printing the message only on the system
stack. We don't expect a stack transition function to appear in a
user G.
Change-Id: I173e89ead2cd4fbf1f0f8cca225f28718b5baebe
Reviewed-on: https://go-review.googlesource.com/c/go/+/531815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
When computing function cost, hairyVisitor.doNode has two primary cases
for determining the cost of a call inside the function:
* Normal calls are simply cost 57.
* Calls that can be inlined have the cost of the inlined function body,
since that body will end up in this function.
Determining which "calls can be inlined" is where this breaks down.
doNode simply assumes that any function with `fn.Inl != nil` will get
inlined. However, this are more complex in mkinlcall, which has a
variety of cases where it may not inline.
For standard builds, most of these reasons are fairly rare (recursive
calls, calls to runtime functions in instrumented builds, etc), so this
simplification isn't too build.
However, for PGO builds, any function involved in at least one inlinable
hot callsite will have `fn.Inl != nil`, even though mkinlcall will only
inline at the hot callsites. As a result, cold functions calling hot
functions will use the (potentially very large) hot function inline body
cost in their call budget. This could make these functions too expensive
to inline even though they won't actually inline the hot function.
Handle this case plus the other inlinability cases (recursive calls,
etc) by consolidating mkinlcall's inlinability logic into
canInlineCallExpr, which is shared by doNode.
mkinlcall and doNode now have identical logic, except for one case: we
check for recursive cycles via inlined functions by looking at the
inline tree. Since we haven't actually done any inlining yet when in
doNode, we will miss those cases.
This CL doesn't change any inlining decisions in a standard build of the
compiler.
In the new inliner, the inlining decision is also based on the call
site, so this synchronization is also helpful.
Fixes#59484
Change-Id: I6ace66e37d50526535972215497ef75cd71f8b9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/483196
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
var p *[2]uint32 = ...
p[0] = 0
p[1] = 0
When we combine these two 32-bit stores into a single 64-bit store,
use the line number of the first store, not the second one.
This differs from the default behavior because usually with the combining
that the compiler does, we use the line number of the last instruction
in the combo (e.g. load+add, we use the line number of the add).
This is the same behavior that gcc does in C (picking the line
number of the first of a set of combined stores).
Change-Id: Ie70bf6151755322d33ecd50e4d9caf62f7881784
Reviewed-on: https://go-review.googlesource.com/c/go/+/521678
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
In CL 163624 we added an atomic store in noteclear on AIX only.
In the discussion on issue #63384 we think we figured out that the
real problem was in the implementation of compare-and-swap on ppc64.
That is fixed by CL 533118, so the atomic store is no longer required.
For #30189
For #63384
Change-Id: I60f4f2fac75106f2bee51a8d9663259dcde2029c
Reviewed-on: https://go-review.googlesource.com/c/go/+/534517
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Currently, set_crosscall2 takes the address of crosscall2 without
using the GOT, which, on some architectures, results in a
PC-relative relocation (e.g. R_AARCH64_ADR_PREL_PG_HI21 on ARM64)
to the crosscall2 symbol. But crosscall2 is dynamically exported,
so the C linker thinks it may bind to a symbol from a different
DSO. Some C linker may not like a PC-relative relocation to such a
symbol. Using a local trampoline to avoid taking the address of a
dynamically exported symbol.
It may be possible to not dynamically export crosscall2. But this
CL is safer for backport. Later we may remove the trampolines
after unexport crosscall2, if they are not needed.
Fixes#62556.
Change-Id: Id28457f65ef121d3f87d8189803abc65ed453283
Reviewed-on: https://go-review.googlesource.com/c/go/+/533535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This CL changes ppc64 atomic compare-and-swap (cas). Before this CL,
if the cas failed--if the value in memory was not the value expected
by the cas call--the atomic function would not synchronize memory.
In the note code in runtime/lock_sema.go, used on BSD systems,
notesleep and notetsleep first try a cas on the key. If that cas fails,
something has already called notewakeup, and the sleep completes.
However, because the cas did not synchronize memory on failure,
this meant that notesleep/notetsleep could return to a core that was
unable to see the memory changes that the notewakeup was reporting.
Fixes#30189Fixes#63384
Change-Id: I9b921de5c1c09b10a37df6b3206b9003c3f32986
Reviewed-on: https://go-review.googlesource.com/c/go/+/533118
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Currently, the two places that run the cover tool manually construct a
terse command description. However, this actually prevents Builder.run
from constructing a more detailed description from the actual command
being run. Fix this by passing "" as the description to get the
default behavior.
Change-Id: I27d42cb1fda9bba70c631dc43417a03b8bddec92
Reviewed-on: https://go-review.googlesource.com/c/go/+/534157
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
If trampolines may be required, the current text addressing second
pass resets all assigned addresses, before assigning addresses and
laying down trampolines in a linear fashion. However, this approach
means that intra-package calls are to a symbol that has not yet
been assigned an address, when the symbol is ahead of the current
function.
In the case of RISC-V the JAL instruction is limited to +/-1MiB.
As such, if a call is to a symbol with no address currently assigned,
we have to assume that a trampoline will be required. During the
relocation phase we can fix up and avoid trampolines in some cases,
however this results in unused trampolines that are still present
in the binary (since removing them would change text addresses).
In order to significantly reduce the number of unused trampolines,
assign temporary addresses to functions within the same package,
based on the maximum number of trampolines that may be required by
a function. This allows for better decisions to be made regarding
the requirement for intra-package trampolines, as we reset the
addressing for a function, assign its final address and lay down
any resulting trampolines.
This results in ~2,300 unused trampolines being removed from the
Go binary and ~5,600 unused trampolines being removed from the
compile binary, on linux/riscv64.
Change-Id: I8a9cf035dea82e1e1e66ae5b1093dce78e4ff0d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/349650
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The Builder returned by work.NewBuilder is already setup to print to
os.Stderr, so it's not necessary for runRun to set b.Print to a
different function that does exactly the same thing.
This b.Print assignment was introduced in CL 5591045. At the time, the
builder type defaulted to printing to os.Stdout, so this was necessary
to make "go run" print build errors to stderr.
Change-Id: I0c07984616c5efc37ba681f4cf69e83542566bab
Reviewed-on: https://go-review.googlesource.com/c/go/+/522796
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Before range over integer, types2 leaves constant expression in RHS of
non-constant shift untyped, so idealType do the validation to ensure
that constant value must be an int >= 0.
With range over int, the range expression can also be left untyped, and
can be an negative integer, causing the validation false.
Fixing this by relaxing the validation in idealType, and moving the
check to Unified IR reader.
Fixes#63378
Change-Id: I43042536c09afd98d52c5981adff5dbc5e7d882a
Reviewed-on: https://go-review.googlesource.com/c/go/+/532835
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
It is tricky to use those types directly, because the layout of those
types in the compiler may not be the same as the layout of those
types in target binary (typically because of 32 vs 64 bit differences).
Instead, translate an internal/abi type into a cmd/compile/internal/types
type, which will then be laid out for the target machine.
Along with the translation, keep track of where all the bits of the
type are so we can reference their locations symbolically instead of
hardcoding them.
Change-Id: I2694c58968d4dc7ead63a2b1b29adfedd90ddd2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/532155
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Lowering for OpConvert was removed for all architectures in CL#108496,
prior to the riscv64 port being upstreamed. Remove lowering of OpConvert
on riscv64, which brings it inline with all other architectures. This
results in 1,600+ instructions being removed from the riscv64 go binary.
Change-Id: Iaaf1f8b397875926604048b66ad8ac91a98c871e
Reviewed-on: https://go-review.googlesource.com/c/go/+/533335
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
As observed in https://go.dev/issue/61666#issuecomment-1739476954,
if a -run flag value matches no tests, dist test output doesn't do much
to help users notice that was what happened. It is valid and sometimes
intended¹ to match no tests, so I want to reserve failed status with
exit code 1 to the actionable outcome where at least 1 test failed.
But it seems reasonable to extend the existing "some were excluded"
mechanism of reporting partial testing to be more helpful.
In non-JSON mode, which is more likely to be used manually by humans,
print a special² last line that will hopefully be easier to notice when
matching no tests wasn't intended. Change nothing for -json mode since
that's likely used by machines and they can make sense of 0 JSON events.
The go test command already has this behavior, so this brings dist test
closer³ to it. (Slightly unfortunate duplicate maintenance for us, and
the need for the rare dist test users to learn its CLI quirks; oh well.)
¹ It might seem counter-intuitive at first: what's the point of calling
dist test and asking it to run no tests? One possible answer is that
it permits writing code capable of running N intended tests, where N
is 0 or higher. That is, it allows for 0 to not be a special case that
the caller would have no choice but handle differently.
² I initially considered making it say something like "N of M tests were
excluded", but decided to leave it alone since the current coordinator
code still has that text hardcoded and I don't want to break it. Hence
the new status that I expect only humans will see. And it seems better
this way anyway.
³ In particular, the "matched no tests" and "no tests to run" phrases
were selected precisely because they're already used in cmd/go output.
Change-Id: I6768d9932587195ae6dbc6e2c4742479e265733b
Reviewed-on: https://go-review.googlesource.com/c/go/+/532115
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Convert expand calls into a smaller number of focused
recursive rewrites, and rely on an enhanced version of
"decompose" to clean up afterwards.
Debugging information seems to emerge intact.
Change-Id: Ic46da4207e3a4da5c8e2c47b637b0e35abbe56bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/507295
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The branch taken by the bytealg.Count algorithm used to process a single
32 bytes block per loop iteration. Throughput of the algorithm can be
improved by unrolling two iterations per loop: the lack of data
dependencies between each iteration allows for better utilization of the
CPU pipeline. The improvement is most significant on medium size payloads
that fit in the L1 cache; beyond the L1 cache size, memory bandwidth is
likely the bottleneck and the change does not show any measurable
improvements.
goos: linux
goarch: amd64
pkg: bytes
cpu: Intel(R) Xeon(R) CPU @ 2.60GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
CountSingle/10 4.800n ± 0% 4.811n ± 0% +0.23% (p=0.000 n=10)
CountSingle/32 5.445n ± 0% 5.430n ± 0% ~ (p=0.085 n=10)
CountSingle/4K 81.38n ± 1% 63.12n ± 0% -22.43% (p=0.000 n=10)
CountSingle/4M 133.0µ ± 7% 130.1µ ± 4% ~ (p=0.280 n=10)
CountSingle/64M 4.079m ± 1% 4.070m ± 3% ~ (p=0.796 n=10)
geomean 1.029µ 973.3n -5.41%
│ old.txt │ new.txt │
│ B/s │ B/s vs base │
CountSingle/10 1.940Gi ± 0% 1.936Gi ± 0% -0.22% (p=0.000 n=10)
CountSingle/32 5.474Gi ± 0% 5.488Gi ± 0% ~ (p=0.075 n=10)
CountSingle/4K 46.88Gi ± 1% 60.43Gi ± 0% +28.92% (p=0.000 n=10)
CountSingle/4M 29.39Gi ± 7% 30.02Gi ± 4% ~ (p=0.280 n=10)
CountSingle/64M 15.32Gi ± 1% 15.36Gi ± 3% ~ (p=0.796 n=10)
geomean 11.75Gi 12.42Gi +5.71%
Change-Id: I1098228c726a2ee814806dcb438b7e92febf4370
Reviewed-on: https://go-review.googlesource.com/c/go/+/532457
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 469555 changed Compact to use append instead of bytes.Buffer.
appendCompact iterates over input src slice and performs escaping
of certain characters.
To optimize copying it does not copy characters one by one
but keeps track of the start offset of the data to copy when
it reaches next character to escape or the end of the input.
This start offset may become greater than input character offset
so copying of preceding data should check this condition.
CL 469555 removed boundary checks for copying data preceding
escaped characters and this change restores them.
Fixes https://github.com/golang/go/issues/63379
Change-Id: I5b7856239f256c67faf58834705675c0aea08cc2
GitHub-Last-Rev: 661576fb54
GitHub-Pull-Request: golang/go#63400
Reviewed-on: https://go-review.googlesource.com/c/go/+/533275
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
It is currently slightly better to pass the whole interface to these
functions, so that we don't need to spill/restore the data word across
the function call.
I'm adding a cache in front of these calls, which means we'll no longer
need a spill/restore in the common case, so it is better to just pass
the itab word.
It also makes unifying the logic between I2I and I2I2 versions easier.
Change-Id: I3c3e9fbb1e54890482840d76a1df79f4325bb5bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/528075
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
That way we don't need to call into the runtime when the type being
switched on has been seen many times before.
The cache is just a hash table of a sample of all the concrete types
that have been switched on at that source location. We record the
matching case number and the resulting itab for each concrete input
type.
The caches seldom get large. The only two in a run of all.bash that
get more than 100 entries, even with the sampling rate set to 1, are
test/fixedbugs/issue29264.go, with 101
test/fixedbugs/issue29312.go, with 254
Both happen at the type switch in fmt.(*pp).handleMethods, perhaps
unsurprisingly.
name old time/op new time/op delta
SwitchInterfaceTypePredictable-24 25.8ns ± 2% 2.5ns ± 3% -90.43% (p=0.000 n=10+10)
SwitchInterfaceTypeUnpredictable-24 37.5ns ± 2% 11.2ns ± 1% -70.02% (p=0.000 n=10+10)
Change-Id: I4961ac9547b7f15b03be6f55cdcb972d176955eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/526658
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
For type switches where the targets are interface types,
call into the runtime once instead of doing a sequence
of assert* calls.
name old time/op new time/op delta
SwitchInterfaceTypePredictable-24 26.6ns ± 1% 25.8ns ± 2% -2.86% (p=0.000 n=10+10)
SwitchInterfaceTypeUnpredictable-24 39.3ns ± 1% 37.5ns ± 2% -4.57% (p=0.000 n=10+10)
Not super helpful by itself, but this code organization allows
followon CLs that add caching to the lookups.
Change-Id: I7967f85a99171faa6c2550690e311bea8b54b01c
Reviewed-on: https://go-review.googlesource.com/c/go/+/526657
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
The change that keeps on giving. Only track brace depth in tJS if we are
already inside of a template literal. If we start tracking depth outside
of nested literals it can cause the parser to think we're still in a JS
context when we've actually closed the string interp.
I believe this _mostly_ captures the expected parsing, but since the
JS parser does not implement proper lexical goal symbols, it may not
be entirely accurate. At some point in the future we may be able to
significantly reduce the complexity of this implementation by
implementing a lexical parser that more closely follows the ECMAScript
specification, and structuring escaping rules based on which symbol an
action appears in. This would also allow us to catch errors, which
we currently cannot reasonable do (although perhaps this is beyond the
scope of what html/template _should_ be doing).
Updates #61619
Change-Id: I56e1dbc0d0705ef8fb7a5454ebe2421d4e162ef6
Reviewed-on: https://go-review.googlesource.com/c/go/+/532595
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
The Windows unhandled exception mechanism fails to call the callback
set in SetUnhandledExceptionFilter if the stack can't be correctly
unwound.
Some cgo glue code was not properly chaining the frame pointer, making
the stack unwind to fail in case of an exception inside a cgo call.
This CL fix that and adds a test case to avoid regressions.
Fixes#50951
Change-Id: Ic782b5257fe90b05e3def8dbf0bb8d4ed37a190b
Reviewed-on: https://go-review.googlesource.com/c/go/+/525475
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
As of CL 495447 we now synthesize coverage data (including coverage
profiles) for packages that have no tests, if they are included in a
"go test -cover" run. The code that set up the "run" actions for such
tests wasn't setting the objdir for the action, which meant that the
coverage profile temp file fragment ("_cover_.out") was being created
in the dir where the test was run, and in addition the same fragment
could be written to by more than one package (which could lead to a
corrupted file). This CL updates the code to properly set the objdir,
and to create the dir when needed.
Updates #24570.
Fixes#63356.
Change-Id: Iffe131cf50f07ce91085b816a039308e0ca84776
Reviewed-on: https://go-review.googlesource.com/c/go/+/532555
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For cgo callbacks, currently cgocallbackg locks the OS thread and
then call cgocallbackg1, which invokes the actual callback, and
then unlocks the OS thread in a deferred call. cgocallback then
continues assuming we are on the same M. This assumes there is no
preemption point between the deferred unlockOSThread and returning
to the caller (cgocallbackg). But this is not always true. E.g.
when open defer is not used (e.g. PIE or shared build mode on 386),
there is a preemption point in deferreturn after invoking the
deferred function (when it checks whether there are still defers
to run).
Instead of relying on and requiring the defer implementation has
no preemption point, we move the unlockOSThread to the caller, and
ensuring no preemption by setting incgo to true before unlocking.
This doesn't cover the panicking path, so we also adds an
unlockOSThread there. There we don't need to worry about preemption,
because we're panicking out of the callback and we have unwound the
g0 stack, instead of reentering cgo.
Fixes#62102.
Change-Id: I0e0b9f9091be88d01675c0acb7339b81402545be
Reviewed-on: https://go-review.googlesource.com/c/go/+/532615
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Uses ,ABI instead of <ABI> because of problems with shell escaping
and windows file names, however if someone goes to all the trouble
of escaping the linker syntax and uses that instead, that works too.
Examples:
```
GOSSAFUNC=runtime.exitsyscall go build main.go
\# runtime
dumped SSA for exitsyscall,0 to ../../src/loopvar/ssa.html
dumped SSA for exitsyscall,1 to ../../src/loopvar/ssa.html
GOSSADIR=`pwd` GOSSAFUNC=runtime.exitsyscall go build main.go
\# runtime
dumped SSA for exitsyscall,0 to ../../src/loopvar/runtime.exitsyscall,0.html
dumped SSA for exitsyscall,1 to ../../src/loopvar/runtime.exitsyscall,1.html
GOSSAFUNC=runtime.exitsyscall,0 go build main.go
\# runtime
dumped SSA for exitsyscall,0 to ../../src/loopvar/ssa.html
GOSSAFUNC=runtime.exitsyscall\<1\> go build main.go
\# runtime
dumped SSA for exitsyscall,1 to ../../src/loopvar/ssa.html
```
Change-Id: Ia1138b61c797d0de49dbfae702dc306b9650a7f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/532475
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: David Chase <drchase@google.com>
For constant signed values which require 34b to represent,
the assembler will generate a pli instruction on
linux/power10/PPC64 instead of loading a constant.
Similarly, ADD is extended to support 34b signed constants.
On linux/power10/PPC64, this generates a paddi instruction.
For assembler consistency, a second form is added if paddi
cannot be used. The second form is provided for assembly
writers.
Change-Id: I98144306af766b02fbbe36b72856a23cdf51d247
Reviewed-on: https://go-review.googlesource.com/c/go/+/528317
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
This enables publicationBarrier to be used as an intrinsic
on riscv64, optimizing the required function call and return
instructions for invoking the "runtime.publicationBarrier"
function.
This function is called by mallocgc. The benchmark results for malloc tested on Lichee-Pi-4A(TH1520, RISC-V 2.0G C910 x4) are as follows.
goos: linux
goarch: riscv64
pkg: runtime
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Malloc8-4 92.78n ± 1% 90.77n ± 1% -2.17% (p=0.001 n=10)
Malloc16-4 156.5n ± 1% 151.7n ± 2% -3.10% (p=0.000 n=10)
MallocTypeInfo8-4 131.7n ± 1% 130.6n ± 2% ~ (p=0.165 n=10)
MallocTypeInfo16-4 186.5n ± 2% 186.2n ± 1% ~ (p=0.956 n=10)
MallocLargeStruct-4 1.345µ ± 1% 1.355µ ± 1% ~ (p=0.093 n=10)
geomean 216.9n 214.5n -1.10%
Change-Id: Ieab6c02309614bac5c1b12b5ee3311f988ff644d
Reviewed-on: https://go-review.googlesource.com/c/go/+/531719
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: M Zhuo <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
I recently reviewed some code that did time calculations using
`time.UnixMicro(0).UTC()`. I commented that because time calculations
are independent of the location, they should drop the `.UTC()`, and they
replied that it made their tests fail.
I looked into it and eventually discovered it was because they were
using AddDate. Dramatically simplified, their code did something like:
orig := time.Date(2013, time.March, 23, 12, 00, 0, 0, time.UTC)
want := time.Date(2013, time.March, 23, 0, 0, 0, 0, time.UTC)
epoch := time.UnixMicro(0)
days := int(orig.Sub(epoch).Hours() / 24)
got := epoch.AddDate(0, 0, days)
if !got.Equal(want) {
t.Errorf("ay caramba: %v vs %v", got.UTC(), want.UTC())
}
The issue is that their tests run in Pacific time, which is currently
PST (UTC-8) but was PDT (UTC-7) in January 1970.
It turns out they were implementing some business policy that really
cares abut calendar days so AddDate is correct, but it's certainly a bit
confusing!
The idea with this change is to remove the risk that readers make a
false shortcut in their mind: "Locations do not affect time
calculations". To do this we remove some text from the core time.Time
doc and shift it to the areas of the library that deal with these
intrinsically confusing operations.
Change-Id: I8200e9edef7d1cdd8516719e34814eb4b78d30a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/526676
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
[[ is a compound command part of the language with structure,
whereas [ is simply a standard program with string arguments.
The former has a few significant advantages over the latter:
* Better syntax, e.g. && and || rather than -a and -o,
as well as == rather than = for comparisons
* No need for fork+exec to evaluate each conditional
* Forgetting the closing token is an early parse error
The only advantage of [ over [[ is that [[ is Bash syntax,
whereas [ and "test" are portable POSIX Shell utilities.
However, this is a Bash script, so that is not a concern.
Change-Id: I8a4bdd16845bd67bf67a348d7d96d45d5b131d85
Reviewed-on: https://go-review.googlesource.com/c/go/+/531875
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 531516 converted origRlimitNofile from an atomic.Value to
atomic.Pointer[Rlimit]. i.e., it changed from storing a value to storing
a pointer.
After storing a pointer to lim, the remainder of this function
immediately modifies it, thus mutating the value pointer to by
origRlimitNofile (and thus defeating the point of origRlimitNofile).
This broke the android-amd64-emu builder because it is (apparently) the
only builder where the original RLIMIT_NOFILE Cur != Max.
TestRlimitRestored is skipped on every other builder.
Change-Id: I12076350eeddfd221823ad651e7e7eca59d2bdcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/532100
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add the GODEBUG setting httpmuxgo121.
When set to "1", ServeMux behaves exactly like it did in Go 1.21.
Implemented by defining a new, unexported type, serveMux121, that
uses the original code.
Updates #61410.
Change-Id: I0a9d0fe2a2286e442d680393e62895ab50683cea
Reviewed-on: https://go-review.googlesource.com/c/go/+/530461
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
This change undoes the restrictions added in CL 482079, which added a
blanket ban on using actions within JS template literal strings, and
adds logic to support actions while properly applies contextual escaping
based on the correct context within the literal.
Since template literals can contain both normal strings, and nested JS
contexts, logic is required to properly track those context switches
during parsing.
ErrJsTmplLit is deprecated, and the GODEBUG flag jstmpllitinterp no
longer does anything.
Fixes#61619
Change-Id: I0338cc6f663723267b8f7aaacc55aa28f60906f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/507995
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Previously, the built-in handlers assumed a group was empty if and
only if it had no attributes. But a ReplaceAttr function that
returned an empty Attr could produce an empty group even if the group
had attrs prior to replacement.
The obvious solution, doing the replacement first and then checking,
would require allocating storage to hold the replaced Attrs. Instead,
we write to the buffer, and if no attributes were written, we back up
to before the group name.
Fixes#62512.
Change-Id: I140e0901f4b157e36594d8d476f1ab326f8f2c2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/529855
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Relocate the 'covcmd' package from .../internal/coverage to
.../cmd/internal/cov, to reflect the fact that the definitions in this
package are used only in cmd, not in std.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I65bcc34736d1d0a23134a6c91c17ff138cd45431
Reviewed-on: https://go-review.googlesource.com/c/go/+/526595
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This patch fixes some problems with how "go test -cover" was handling
tests involving A) multiple package tests and B) multiple packages
matched by "-coverpkg". In such scenarios the expectation is that the
percent statements covered metric for each package needs to be
relative to all statements in all packages matched by the -coverpkg
arg (this aspect of the reporting here was broken as part of
GOEXPERIMENT=coverageredesign).
The new scheme works as follows. If -coverpkg is in effect and is
matching multiple packages, and we have multiple test targets, then:
- each time a package is built for coverage, capture a meta-data
file fragment corresponding to just the meta-data for that package.
- create a new "writeCoverMeta" action, and interpose it between the
build actions for the covered packages and the run actions. The
"writeCoverMeta" action at runtime will emit a file
"metafiles.txt" containing a table mapping each covered package
(by import path) to its corresponding meta-data file fragment.
- pass in the "metafiles.txt" file to each run action, so that
when the test finishes running it will have an accurate picture
of _all_ covered packages, permitting it to calculate the correct
percentage.
Concrete example: suppose we have a top level directory with three
package subdirs, "a", "b", and "c", and from the top level, a user
runs "go test -coverpkg=./... ./...". This will result in (roughly)
the following action graph:
build("a") build("b") build("c")
| | |
link("a.test") link("b.test") link("c.test")
| | |
run("a.test") run("b.test") run("c.test")
| | |
print print print
With the new scheme, the action graph is augmented with a
writeCoverMeta action and additional dependence edges to form
build("a") build("b") build("c")
| \ / | / |
| v v | / |
| writecovmeta<-|-------------+ |
| ||| | |
| ||\ | |
link("a.test")/\ \ link("b.test") link("c.test")
| / \ +-|--------------+ |
| / \ | \ |
| v v | v |
run("a.test") run("b.test") run("c.test")
| | |
print print print
A note on init functions: prior to GOEXPERIMENT=coverageredesign
the "-coverpkg=..." flag was implemented by force-importing
all packages matched by "-coverpkg" into each instrumented package.
This meant that for the example above, when executing "a.test",
the init function for package "c" would fire even if package "a"
did not ordinarily import package "c". The new implementation
does not do this sort of forced importing, meaning that the coverage
percentages can be slightly different between 1.21 and 1.19 if
there are user-written init funcs.
Fixes#58770.
Updates #24570.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I7749ed205dce81b96ad7f74ab98bc1e90e377302
Reviewed-on: https://go-review.googlesource.com/c/go/+/495452
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This patch improves the way the go command handles coverage testing
of packages that have functions but don't have any test files. Up to
this point if you ran "go test -cover" on such a package, you would
see:
? mymod/mypack [no test files]
While "no test files" is true, it is also very unhelpful; if the
package contains functions, it would be better instead to capture the
fact that these functions are not executed when "go test -cover" is
run on the package.
With this patch, for the same no-test package "go test -cover" will
output:
mymod/mypack coverage: 0.0% of statements
The inclusion of such packages in coverage reporting also extends to
"-coverprofile" as well (we'll see entries for the "mypack" functions
in this case.
Note that if a package has no functions at all, then we'll still fall
back to reporting "no test files" in this case; it doesn't make sense
to report "0.0% statements covered" if there are no statements.
Updates #27261.
Updates #58770.
Updates #18909.
Fixes#24570.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I8e916425f4f2beec65861df78265e93db5ce001a
Reviewed-on: https://go-review.googlesource.com/c/go/+/495447
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL is a roll-forward (tweaked slightly) of CL 467715, which
turned on text section splitting for GOARCH=arm. The intent is to
avoid recurrent problems with external linking where there is a
disagreement between the Go linker and the external linker over
whether a given branch will reach. In the past our approach has been
to tweak the reachability calculations slightly to try to work around
potential linker problems, but this hasn't proven to be very robust;
section splitting seems to offer a better long term fix.
Fixes#58425.
Change-Id: I7372d41abce84097906a3d0805b6b9c486f345d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/531795
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The end-to-end asm tests reinitialize the assembler using different
GOPPC64 values. This caused duplicate entries to amass from the
prefix and generated optab entries. This bug only affects the
asm end-to-end tests.
On reinitialization, optab contains the previous prefixedOptab
and optabGen entries, not just the initial values. Rework the
initialization to avoid the stale optab entries.
Change-Id: I310499915a5272ed0174ed8135d60788e6b4b716
Reviewed-on: https://go-review.googlesource.com/c/go/+/528316
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
createEnvBlock currently allocates multiple times: at least one to
convert the slice of strings into a NULL separated slice of bytes, and
then again to encode it as UTF-16. The logic to do so is also quite
complex.
This CL simplifies the logic by allocating only once by encoding the
slice of strings into UTF-16 directly using utf16.AppendRune.
goos: windows
goarch: amd64
pkg: syscall
cpu: Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
CreateEnvBlock-12 37.92µ ± 24% 21.36µ ± 8% -43.66% (p=0.000 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
CreateEnvBlock-12 109.12Ki ± 0% 26.62Ki ± 0% -75.60% (p=0.000 n=10)
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
CreateEnvBlock-12 4.000 ± 0% 1.000 ± 0% -75.00% (p=0.000 n=10)
Change-Id: If35f62c3926b486d5253a9ae23a33b979b2f02c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/531355
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TestBuildForTvOS currently runs only on darwin/amd64. It can also
run on darwin/arm64, if the SDK is installed. Unskip the test.
Also add logging for the build commands it runs.
For #63203.
Change-Id: Id41d2e1879f5d39d239f0586d836d33accf5efbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/531555
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In CL 197062, many errors related to go.sum were changed from base.Fatal
to error returns. The malformed go.sum error was lost in the process.
Currently, when go encounters a malformed go.sum file, go will read the
well-formed part of the file and then silently ignore the rest.
The motivation behind moving away from base.Fatal was to make the errors
show up in -json output. Simply propagating the malformed go.sum error
would not achieve this:
- For an argument-less 'go mod download -json' with a go>=1.17 module,
a malformed go.sum causes an error during LoadModGraph already, before
go ever starts downloading modules and printing their JSON.
- In other cases, a malformed go.sum would be reported as Error for one
of the modules (presumably the one which gets downloaded first) but
none of the others.
- In either case, 'go mod download' manages to download enough data to
succeed on a re-run, making the error look intermittent.
Switch the error back to a Fatal one, but give 'go mod tidy' an
exception to let it fix broken go.sum files.
Fixes#62345
Change-Id: I066482b242165bcc6cbba0b2dab64901fad8619f
GitHub-Last-Rev: feae7696d6
GitHub-Pull-Request: golang/go#62588
Reviewed-on: https://go-review.googlesource.com/c/go/+/527575
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 525556 started using timeRE regexp to match time output from JSON
handler, and relaxed it to allow arbitrary (rather than fixed 3 digit)
precision.
What it missed is in JSON handler the fractional part is omitted
entirely (together with the decimal dot) when the nanoseconds field is
0.
As a result, there are occasional CI failures in js/wasm (which, I guess,
has better chances to return zero nanoseconds).
To fix the flaky test, let's use two different regular expressions,
tailored to text and JSON.
Change-Id: Ie98990fcf278bb0916ab31c9177e6b22a523062a
Reviewed-on: https://go-review.googlesource.com/c/go/+/530675
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Andy Pan <panjf2000@gmail.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
The ReplaceAttr function should not see groups, only leaf attributes.
Previously, we checked an Value for being a group, then resolved it,
then called ReplaceAttr. We neglected to see if it was a group
after resolving it.
Now we resolve first, then check.
Fixes#62731.
Change-Id: I2fc40758e77c445f82deb2c9de8cae7a3b0e22cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/530478
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In CL 475375 the Go command started to generate the "preferlinkext"
token file for "strange/dangerous" compiler flags. This serves as a hint
to the Go linker whether to call the external linker or not.
Permit compiler flags used by bazel and bazelbuild/rules_go during
compilation of cgo code to not prefer external linking. This restores
the behavior of previous versions of Go.
As a side effect, it also allows these flags to appear
in #cgo directives in source code. We don't know of any cases
where that is actually useful, but it appears to be harmless
and simplifies the implementation of the internal linking change.
Fixes#60865
Change-Id: I176a6a2a2cf36293dd9aed24be928f98fa2fb6d9
GitHub-Last-Rev: 071e915b8e
GitHub-Pull-Request: golang/go#60868
Reviewed-on: https://go-review.googlesource.com/c/go/+/504335
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
When parsing patterns and matching, split the path into segments at
slashes, then unescape each segment.
This behaves as most people would expect:
- The pattern "/%61" matches the paths "/a" and "/%61".
- The pattern "/%7B" matches the path "/{". (If we did not unescape
patterns, there would be no way to write that pattern: because "/{"
is a parse error because it is an invalid wildcard.)
- The pattern "/user/{u}" matches "/user/john%2Fdoe" with u set to
"john/doe".
- The unexpected redirections of #21955 will not occur.
A later CL will restore the old behavior behind a GODEBUG setting.
Updates #61410.
Fixes#21955.
Change-Id: I99025e149021fc94bf87d351699270460db532d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/530575
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
When running crypto/tls tests with GOEXPERIMENT=boringcrypto, some
tests are embedded with unreadable hexadecimal values:
=== RUN TestBoringServerSignatureAndHash/5053...3536
This corresponds to a string representation of SignatureScheme as it
implements fmt.Stringer. With this change, the above will be printed
as:
=== RUN TestBoringServerSignatureAndHash/PSSWithSHA256
Change-Id: I953c0bb35c68e77a7f01e7f1fceda203c272faf7
GitHub-Last-Rev: 19700d53a8
GitHub-Pull-Request: golang/go#63175
Reviewed-on: https://go-review.googlesource.com/c/go/+/530715
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
I found the documentation for Pinner itself to contain too little information.
Rewrite it to give a summary and redirect to the relevant methods.
Also reformat the ragged comment for Pin.
Change-Id: I9c786817f43dfc9c72178127c141c35dae221104
Reviewed-on: https://go-review.googlesource.com/c/go/+/528855
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
When reviewing https://go-review.googlesource.com/c/go/+/522435,
Cherry Mui cherryyz@google.com noticed that the implementation of
StructOf was broken, and produced junk if an interface was embedded
into a struct. For example, StructOf messed up the calling convention
for methods of the embedded interface:
> The main problem is that the method wrappers created by reflect.MakeFunc
> expects to be called with a closure calling convention, with a closure
> context passed in the context register. But methods are called with
> a different calling convention, without setting the closure register,
> because (besides this case) all methods are top level functions.
> So there is no way to pass that makefunc closure context.
It is curious that StructOf did not break in go 1.17 which introduced
the regabi. I've tried to run the following example program, and it
fails even in 1.7 which introduced StructOf.
As the embedding of interfaces has been broken since forever,
let us not perpetuate the complexity that this feature brings,
and just remove the support for embedding altogether.
The test program:
package main
import (
"fmt"
"reflect"
)
type I interface {
F()
}
type T int
func (t T) F() { println(t) }
func main() {
var i I
t := reflect.StructOf([]reflect.StructField{
{
Anonymous: true,
Name: "I",
Type: reflect.TypeOf(&i).Elem(),
},
})
v := reflect.New(t).Elem()
v.Field(0).Set(reflect.ValueOf(T(42)))
fmt.Println(v)
v.Interface().(interface{ F() }).F() // fatal error
}
Change-Id: I7b2115c22d66ea4ed746f0f9d22b2c94f604e185
Reviewed-on: https://go-review.googlesource.com/c/go/+/526075
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Windows APIs are normally not arch-specific, so it's better to
implement them in Go instead of assembly.
It was previously implemented in assembly because it was the only way
to support calls without a valid g. This CL defines a new function,
stdcall_no_g, that can be used in such cases.
While here, I've also replaced the use of the deprecated syscall
NtWaitForSingleObject with WaitForSingleObject. The former may
give the illusion of being more accurate, as it takes a higher
resolution timeout, but it's not. Windows time resolution is 15.6ms,
and can be as high as 1ms when using a high resolution timer, which
WaitForSingleObject supports.
Change-Id: I903400220ade4d4ccc15685c8da47182430f8686
Reviewed-on: https://go-review.googlesource.com/c/go/+/526477
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Windows APIs are normally not arch-specific, so it's better to
implement them in Go instead of assembly.
It was previously implemented in assembly because it was the only way
to support calls without a valid g. This CL defines a new function,
stdcall_no_g, that can be used in such cases.
Change-Id: I26a223b918c6c462b06ac256bdacf9ddb78752bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/526476
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
In case of a handshake timeout, the goroutine running addTLS
closes the underlying connection, which should unblock the call
to tlsConn.HandshakeContext. However, it didn't then wait for
HandshakeContext to actually return.
I thought this might have something to do with #57602, but as
far as I can tell it does not. Still, it seems best to avoid the leak:
if tracing is enabled we emit a TLSHandshakeDone event, and it seems
misleading to produce that event when the handshake is still in
progress.
For #57602.
Change-Id: Ibfc0cf4ef8df2ccf11d8897f23d7d79ee482d5fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/529755
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Commit-Queue: Bryan Mills <bcmills@google.com>
Currently, for the shared build mode, we don't generate the module
inittasks. Instead, we rely on the main executable to do the
initialization, for both the executable and the shared library.
But, with the model as of CL 478916, the main executable only
has relocations to packages that are directly imported. It won't
see the dependency edges between packages within a shared library.
Therefore indirect dependencies are not included, and thus not
initialized. E.g. main imports a, which imports b, but main
doesn't directly import b. a and b are in a shared object. When
linking main, it sees main depends on a, so it generates main's
inittasks to run a's init before main's, but it doesn't know b,
so b's init doesn't run.
This CL makes it initialize all packages in a shared library when
the library is loaded, as any of them could potentially be
imported, directly or indirectly.
Also, in the runtime, when running the init functions, make sure
to go through the DSOs in dependency order. Otherwise packages
can be initialized in the wrong order.
Fixes#61973.
Change-Id: I2a090336fe9fa0d6c7e43912f3ab233c9c47e247
Reviewed-on: https://go-review.googlesource.com/c/go/+/520375
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
We don't index multis, so a corpus full of them will take quadratic
time to check for conflicts. How slow is that going to be in practice?
This benchmark indexes and checks a thousand multi patterns, all disjoint.
It runs in about 35ms.
Change-Id: Id27940ab19ad003627bd5c43c53466e01456b796
Reviewed-on: https://go-review.googlesource.com/c/go/+/529477
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Replace the fuzz test with one that enumerates all relevant patterns
up to a certain length.
For conflict detection, we don't need to check every possible method,
host and segment, only a few that cover all the possibilities. There
are only 2400 distinct patterns in the corpus we generate, and the
test generates, indexes and compares them all in about a quarter of a
second.
Change-Id: I9fde88e87cec07b1b244306119e4e71f7205bb77
Reviewed-on: https://go-review.googlesource.com/c/go/+/529556
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
[This is an unmodified redo of CL 527056.]
Standard Ms set g0.stackguard1 to the same value as stackguard0 in
mstart0. For consistency, extra Ms should do the same for their g0. Do
this in needm -> callbackUpdateSystemStack.
Background: getg().stackguard1 is used as the stack guard for the stack
growth prolouge in functions marked //go:systemstack [1]. User Gs set
stackguard1 to ^uintptr(0) so that the check always fail, calling
morestackc, which throws to report a //go:systemstack function call on a
user stack.
g0 setting stackguard1 is unnecessary for this functionality. 0 would be
sufficient, as g0 is always allowed to call //go:systemstack functions.
However, since we have the check anyway, setting stackguard1 to the
actual stack bound is useful to detect actual stack overflows on g0
(though morestackc doesn't detect this case and would report a
misleading message about user stacks).
[1] cmd/internal/obj calls //go:systemstack functions AttrCFunc. This is
a holdover from when the runtime contained actual C functions. But since
CL 2275, it has simply meant "pretend this is a C function, which would
thus need to use the system stack". Hence the name morestackc. At this
point, this terminology is pretty far removed from reality and should
probably be updated to something more intuitive.
Change-Id: If315677217354465fbbfbd0d406d79be20db0cc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/527716
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add an index so that pattern registration isn't always quadratic.
If there were no index, then every pattern that was registered would
have to be compared to every existing pattern for conflicts. This
would make registration quadratic in the number of patterns, in every
case.
The index in this CL should help most of the time. If a pattern has a
literal segment, it will weed out all other patterns that have a
different literal in that position.
The worst case will still be quadratic, but it is unlikely that a set
of such patterns would arise naturally.
One novel (to me) aspect of the CL is the use of fuzz testing on data
that is neither a string nor a byte slice. The test uses fuzzing to
generate a byte slice, then decodes the byte slice into a valid
pattern (most of the time). This test actually caught a bug: see
https://go.dev/cl/529119.
Change-Id: Ice0be6547decb5ce75a8062e4e17227815d5d0b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/529121
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
The riscv64 assembler and linker generate three types of calls.
Most calls are made via a single JAL instruction, however this is
limited to +/-1MB of text. In the case where a call target is
unreachable (or unknown), the JAL targets an AUIPC+JALR trampoline.
All other cases use AUIPC+JALR pairs, including the case where a
single function exceeds 1MB in text size, potentially making it
impossible to reach trampolines.
Currently, the single instruction JAL call is marked with R_RISCV_CALL
and the two instruction AUIPC+JALR call is marked with
R_RISCV_PCREL_ITYPE, which is also used for memory load instructions.
This means that we have no way to identify that the latter is a call.
Switch to using R_RISCV_CALL to mark the AUIPC+JALR pair (aligning
somewhat with the elf.R_RISCV_CALL, which is deprecated in favour of
elf.R_RISCV_CALL_PLT). Add R_RISCV_JAL and use this to mark the single
instruction JAL direct calls. This is clearer and allows us to map
elf.R_RISCV_CALL_PLT to Go's R_RISCV_CALL.
Add all three types to IsDirectCall, so that direct calls are correctly
identified when a function exceeds 1MB of text.
Fixes#62465
Change-Id: Id3eea09688a2b7d6e481eae9ed0aa0d1f9a3a48f
Reviewed-on: https://go-review.googlesource.com/c/go/+/520095
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Than McIntosh <thanm@google.com>
Previously the test used an unbuffered channel, but testConn.Close
sends to it with a select-with-default, so the send would be dropped
if the test goroutine happened not to have parked on the receive yet.
To make this kind of bug less likely in future tests, use a
newTestConn helper function instead of constructing testConn channel
literals in each test individually.
Fixes#62622.
Change-Id: I016cd0a89cf8a2a748ed57a4cdbd01a178f04dab
Reviewed-on: https://go-review.googlesource.com/c/go/+/529475
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
combineRelationships was wrong on one case: if one part of a pattern
overlaps and the other is disjoint, the result is disjoint, not overlaps.
For example:
/a/{x}/c
/{x}/b/d
Here the prefix consisting of the first two segments overlaps, but the
third segments are disjoint. The patterns as a whole are disjoint.
comparePaths was wrong in a couple of ways:
First, the loop shouldn't exit early when it sees an overlap,
for the reason above: later information may change that.
Once the loop was allowed to continue, we had to handle the "overlaps"
case at the end. The insight there, which generalized the existing
code, is that if the shorter path ends in a multi, that multi matches
the remainder of the longer path and more. (It must be "and more": the
longer path has at least two segments, so it couldn't match one
segment while the shorter path's multi can.) That means we can treat
the result as the combination moreGeneral and the relationship of the
common prefix.
Change-Id: I11dab2c020d820730fb38296d9d6b072bd2a5350
Reviewed-on: https://go-review.googlesource.com/c/go/+/529119
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The afterFuncContext type, used only in tests, contains a
set of registered afterfuncs indexed by an arbitrary unique key.
That key is currently a *struct{}. Unfortunately, all
*struct{} pointers are equal to each other, so all registered
funcs share the same key. Fortunately, the tests using this
type never register more than one afterfunc.
Change the key to a *byte.
Change-Id: Icadf7d6f258e328f6e3375846d29ce0f98b60924
Reviewed-on: https://go-review.googlesource.com/c/go/+/526655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
While it is possible to embed a GNU build ID into the linked
executable by passing `-B 0xBUILDID` to the linker, the build ID will
need to be precomputed by the build system somehow. This makes it
unnecessarily complex to generate a deterministic build ID as it
either requires the build system to hash all inputs manually or to
build the binary twice, once to compute its hash and once with the GNU
build ID derived from that hash. Despite being complex, it is also
inefficient as it requires the build system to duplicate some of the
work that the Go linker already performs anyway.
Introduce a new argument "gobuildid" that can be passed to `-B` that
causes the linker to automatically derive the GNU build ID from the Go
build ID. Given that the Go build ID is deterministically computed
from all of its inputs, the resulting GNU build ID should be
deterministic in the same way, which is the desired behaviour.
Furthermore, given that the `-B` flag currently requires a "0x" prefix
for all values passed to it, using "gobuildid" as value is a backwards
compatible change.
An alternative would be to unconditionally calculate the GNU build ID
unless otherwise specified. This would require some larger rework
though because building the Go toolchain would not converge anymore
due the GNU build ID changing on every stage, which in turn would
cause the Go build ID to change as well.
Fixes#41004
Change-Id: I707c5fc321749c00761643d6cc79d44bf2cd744d
GitHub-Last-Rev: 5483305a85
GitHub-Pull-Request: golang/go#61469
Reviewed-on: https://go-review.googlesource.com/c/go/+/511475
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Clang 14+ introduced a warning when using mixed packed and unpacked structs.
This can cause problems when taking an address of the unpacked struct, which
may end up having a different alignment than expected.
This is not a problem in cgo, which does not take pointers from the packed
struct.
Updated version of https://go.dev/cl/526915, which includes
"-Wunknown-warning-option" for compilers that do not have the specific flag.
Fixes#62480
Change-Id: I788c6604d0ed5267949f4367f148fa26d2116f51
Reviewed-on: https://go-review.googlesource.com/c/go/+/528935
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Change immIFits to return an error in the case that it does not fit.
This allows for deduplication and consistency of error messages.
Additionally, since we've already calculated the min and max values,
we can easily include these in the message. Also provide and use
immEven, for the same reasons.
Change-Id: Ie680558744f3e9bc19d6913c4144ce9ddbd0429c
Reviewed-on: https://go-review.googlesource.com/c/go/+/523458
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Run-TryBot: M Zhuo <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: M Zhuo <mzh@golangcn.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
If the call to ReadString returns an error, the closure in
testServerGracefulClose will return an error and retry the test with a
longer timeout. If that happens, we need to wait for the conn.Write
goroutine to complete so that we don't leak connections across tests.
Updates #57084.
Fixes#62643.
Change-Id: Ia86c1bbd0a5e5d0aeccf4dfeb994c19d1fb10b00
Reviewed-on: https://go-review.googlesource.com/c/go/+/528398
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
If the rotate argument is the constant 0, rlwnm may be generated
instead of rlwinm. In all reasonable cases, this is OK as R0 should
hold 0. However, this could be problematic in some cases when
writing PPC64 assembly.
This consolidates the RLWNM and RLWMI optab entries. Invalid RLWMI
usage is still rejected, however the error will be be slightly
different. The invalid usage will be caught in oprrr instead of oplook.
Change-Id: I9958bd24660fea5f8fc9e3e50d51daa7349e3206
Reviewed-on: https://go-review.googlesource.com/c/go/+/527275
Reviewed-by: Heschi Kreinick <heschi@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Add a post-processing pass that updates the scores on callsites based
on how their results are used. This is similar to the "param feeds
unmodified into <XXX>" heuristics, but applies to returned results
instead: if we know that function F always returns a constant, and we
can see that the result from a given call feeds unmodified into an
if/switch, then decrease the score on the call to encourage inlining.
Change-Id: If513765c79d868cbdf672facbff9d92ad24f909e
Reviewed-on: https://go-review.googlesource.com/c/go/+/521819
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Make use of the "never returns" flag bit in ir.Func when computing
function properties: update the bit when we're done looking at a given
function, and read the bit from imported functions during flag
analysis. The advantage of using the ir.Func flag is that it will get
set (and will propagate through to export data) for all functions,
nost just those that are inline candidates.
Change-Id: I7002364b2c4ff5424ed70748fad87fad1a9e4786
Reviewed-on: https://go-review.googlesource.com/c/go/+/518257
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Add a new debug flag "-d=dumpinlcallsitescores" that dumps out a
summary of all callsites in the package being compiled with info on
inlining heuristics, for human consumption. Sample output lines:
Score Adjustment Status Callee CallerPos ScoreFlags
...
115 40 DEMOTED cmd/compile/internal/abi.(*ABIParamAssignment).Offset expand_calls.go:1679:14|6 panicPathAdj
...
76 -5 PROMOTED runtime.persistentalloc mcheckmark.go:48:45|3 inLoopAdj
...
201 0 --- PGO unicode.DecodeRuneInString utf8.go:312:30|1
...
7 -5 --- PGO internal/abi.Name.DataChecked type.go:625:22|0 inLoopAdj
Here "Score" is the final score calculated for the callsite,
"Adjustment" is the amount added to or subtracted from the original
hairyness estimate to form the score. "Status" shows whether anything
changed with the site -- did the adjustment bump it down just below
the threshold ("PROMOTED") or instead bump it above the threshold
("DEMOTED") or did nothing happen as a result of the heuristics
("---"); "Status" also shows whether PGO was involved. "Callee" is the
name of the function called, "CallerPos" is the position of the
callsite, and "ScoreFlags" is a digest of the specific properties we
used to make adjustments to callsite score via heuristics.
Change-Id: Iea4b1cbfee038bc68df6ab81e9973f145636300b
Reviewed-on: https://go-review.googlesource.com/c/go/+/513455
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Introduce a new mode of execution for instrumenting packages that have
no test files. Instead of just skipping packages with no test files
(during "go test -cover" runs), the go command will invoke cmd/cover
on the package passing in an option in the config file indicating that
it should emit a coverage meta-data file directly for the package (if
the package has no functions, an empty file is emitted). Note that
this CL doesn't actually wire up this functionality in the Go command,
that will come in a later patch.
Updates #27261.
Updates #58770
Updates #24570.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I01e8a3edb62441698c7246596e4bacbd966591c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/495446
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This patch changes the inliner to use callsite scores when deciding to
inline as opposed to looking only at callee cost/hairyness.
For this to work, we have to relax the inline budget cutoff as part of
CanInline to allow for the possibility that a given function might
start off with a cost of N where N > 80, but then be called from a
callsites whose score is less than 80. Once a given function F in
package P has been approved by CanInline (based on the relaxed budget)
it will then be emitted as part of the export data, meaning that other
packages importing P will need to also need to compute callsite scores
appropriately.
For a function F that calls function G, if G is marked as potentially
inlinable then the hairyness computation for F will use G's cost for
the call to G as opposed to the default call cost; for this to work
with the new scheme (given relaxed cost change described above) we
use G's cost only if it falls below inlineExtraCallCost, otherwise
just use inlineExtraCallCost.
Included in this patch are a bunch of skips and workarounds to
selected 'errorcheck' tests in the <GOROOT>/test directory to deal
with the additional "can inline" messages emitted when the new inliner
is turned on.
Change-Id: I9be5f8cd0cd8676beb4296faf80d2f6be7246335
Reviewed-on: https://go-review.googlesource.com/c/go/+/519197
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This suppresses the race reported in #62638.
I am not 100% certain how that race happens, but here is my theory.
The increment of reqNum happens before the server writes the response
headers, and the server necessarily writes the headers before the
client receives them. However, that write/read pair occurs through I/O
syscalls rather than Go synchronization primitives, so it doesn't
necessarily create a “happens before” relationship as defined by the
Go memory model: although we can establish a sequence of events, that
sequence is not visible to the race detector, nor to the compiler.
Fixes#62638.
Change-Id: I90d66ec3fc32b9b8e1f9bbf0bc2eb289b964b99b
Reviewed-on: https://go-review.googlesource.com/c/go/+/528475
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
When slog.Record.Add(args) is called, with enough args to cause the
Record.back []Attr to be created, it is being created 1 too small, which
results in it immediately being grown again by append before the function
exits (needless allocation and copying).
This is because it is created with a capacity equal to countAttrs(args),
but forgets that there is an additional attribute to be appended: a
(args is just the remaining unconsumed attributes).
This PR fixes that by adding 1 to the capacity to account for the `a` attribute.
Additionally, when Record.back already exists, it will most likely be at
max capacity already. Rather than append to it and risk having it grown
multiple times, or grow too large, this adds a slices.Grow call to set it
to the right capacity, similar to what is already done in the
Record.AddAttrs(attrs) function.
Change-Id: Ic4bcf45909fe4436c586ccd2b8d61f24606b6be8
GitHub-Last-Rev: 4c924b610a
GitHub-Pull-Request: golang/go#62388
Reviewed-on: https://go-review.googlesource.com/c/go/+/524618
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Also log verbose information when -test.v is set.
We need an arbitrary delay when checking that a signal is *not*
delivered, but when we expect the signal to arrive we don't need to
set an arbitrary limit on how long that can take.
Fixes#61264.
Change-Id: If3bbbf78e3c22694bf825d90d7ee9564ce8daedd
Reviewed-on: https://go-review.googlesource.com/c/go/+/509636
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Several methods return a (*types.Pkg, *types.Sym) pair instead of just
a *types.Sym, because we used to need to preserve the *types.Pkg for
certain types so that we could write out export data for go/types to
use (which exposes these through its APIs).
But now that we write export data from the types2 representation
directly, there's no need for the rest of the compiler to be
concerned about that.
Change-Id: I6ac81a6db71b8e0795ff2f33399b839871564eb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/528416
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL clarifies the order of evaluation of the binary logical
operators, && and ||. The clarified semantics matches what cmd/compile
and x/tools/go/ssa already implement, and prohibit some optimizations
that are arguably allowed today but risk surprising users.
First, it specifies that the left operand is evaluated before the
right operand. This prohibits "(f() || true) && *p" from evaluating
"*p" before "f()".
Second, it specifies that binary logical operations are also ordered
lexically left-to-right with regard to function calls and receive
operations. This prohibits "h(*p || true || f(), g())" from evaluating
"*p" after "g()".
Finally, the "order of evaluation of [...] is not specified" wording
in the example is clarified to acknowledge that there are still some
other orderings that are implied lexically; e.g., x must be evaluated
and indexed before g(), and z now must be evaluated before h(). (Note:
Whether z is evaluated before or after f() remains unspecified, as
there's no lexical dependency.)
Change-Id: I9d316a7f1fbc83be663e116380a2cc7a4ace623d
Reviewed-on: https://go-review.googlesource.com/c/go/+/522938
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add Request.PathValue and Request.SetPathValue,
and the fields on Request required to support them.
Populate those fields in ServeMux.ServeHTTP.
Updates #61410.
Change-Id: Ic88cb865b0d865a30d3b35ece8e0382c58ef67d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/528355
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
As far as I can tell, some flakiness is unavoidable in tests
that race a large client request write against a server's response
when the server doesn't read the full request.
It does not appear to be possible to simultaneously ensure that
well-behaved clients see EOF instead of ECONNRESET and also prevent
misbehaving clients from consuming arbitrary server resources.
(See RFC 7230 §6.6 for more detail.)
Since there doesn't appear to be a way to cleanly eliminate
this source of flakiness, we can instead work around it:
we can allow the test to adjust the hard-coded delay if it
sees a plausibly-related failure, so that the test can retry
with a longer delay.
As a nice side benefit, this also allows the tests to run more quickly
in the typical case: since the test will retry in case of spurious
failures, we can start with an aggressively short delay, and only back
off to a longer one if it is really needed on the specific machine
running the test.
Fixes#57084.
Fixes#51104.
For #58398.
Change-Id: Ia4050679f0777e5eeba7670307a77d93cfce856f
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-race,gotip-linux-amd64-race,gotip-windows-amd64-race
Reviewed-on: https://go-review.googlesource.com/c/go/+/527196
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Modify ServeMux to handle patterns with methods and wildcards.
Remove the map and list of patterns. Instead patterns
are registered and matched using a routing tree.
We also reorganize the code around "trailing-slash redirection,"
the feature whereby a trailing slash is added to a path
if it doesn't match an existing one. The existing code
checked the map of paths twice, but searching the tree
twice would be needlessly expensive. The rewrite
searches the tree once, and then again only if a
trailing-slash redirection is possible.
There are a few omitted features in this CL, indicated
with TODOs.
Change-Id: Ifaef59f6c8c7b7131dc4a5d0f101cc22887bdc74
Reviewed-on: https://go-review.googlesource.com/c/go/+/528039
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
This reapplies CL 512155, which was previously reverted in CL 527337.
The race that prompted the revert should be fixed by CL 527820,
which will be submitted before this one.
For #36768.
Updates #62596.
Change-Id: I3c3cd92470254072901b6ef91c0ac52c8071e0a2
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-race,gotip-windows-amd64-race,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/528038
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
- Ignore empty entries in PATH, like PowerShell does.
- If we resolve a path using an explicit relative entry in PATH,
treat it the same as we do for the implicit "." search path,
by allowing a later (absolute) PATH entry that resolves to the
same executable to return the absolute version of its path.
- If the requested path does not end with an extension matching
PATHEXT, return ErrNotFound (indicating that we potentially searched
for multiple alternatives and did not find one) instead of
ErrNotExist (which would imply that we know the exact intended path
but couldn't find it).
Fixes#61493.
Change-Id: I5b539d8616e3403825749d8eccf46725fa808a17
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-race,gotip-windows-amd64-race,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/528037
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
If the -R flag (the segment alignment) is specified but the -T
flag (start address) is not, currently the default start address
may be under-aligned, and some math in the linker may be broken.
Round up the start address to align it.
Fixes#62064.
Change-Id: I3b98c9d0cf7d3cd944b9436a36808899d2e52572
Reviewed-on: https://go-review.googlesource.com/c/go/+/527822
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the WebAssembly version of these operators we avoid using
a CAS loop since the Go wasm implementation is single-threaded.
A new test file has been added that has build tags in order to
only test this feature on implemented architectures.
This is part of a series of CLs aimed to add the primitives
for And/Or atomic operations that will be used by the public
sync/atomic apis.
For #61395
Change-Id: Ic67ffefc9cfb626915ea86b6b21b500117710327
GitHub-Last-Rev: bbec3a5f35
GitHub-Pull-Request: golang/go#62517
Reviewed-on: https://go-review.googlesource.com/c/go/+/526656
Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
False sharing observed inside mheap struct, between arenas and preceding
variables.Pad mheap.arenas and preceding variables to avoid false sharing
This false-sharing getting worse and impact performance on multi core
system and frequent memory allocate workloads. While running MinIO On a
2 socket system(56 Core per socket) and GOGC=1000, we observed HITM>8%
(perf c2c) on this cacheline.
After resolve this false-sharing issue, we got performance 17% improved.
Improvement verified on MinIO:
Server: https://github.com/minio/minio
Client: https://github.com/minio/warp
Config: Single node MinIO Server with 6 ramdisk, without TLS enabled,
Run warp GET request, 128KB object and 512 concurrent
Fixes#62472
Signed-off-by: Li Gang<gang.g.li@intel.com>
Change-Id: I9a4a3c97f5bc8cd014c627f92d59d9187ebaaab5
Reviewed-on: https://go-review.googlesource.com/c/go/+/525955
Reviewed-by: Heschi Kreinick <heschi@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Now that types can self-report how many registers they need, it's much
easier to determine whether a parameter will fit into the available
registers: simply compare the number of registers needed against the
number of registers still available.
This also eliminates the need for the NumParamRegs cache.
Also, the new code in NumParamRegs is stricter in only allowing it to
be called on types that can actually be passed in registers, which
requires a test to be corrected for that. While here, change mkstruct
to a variadic function, so the call sites require less boilerplate.
Change-Id: Iebe1a0456a8053a10e551e5da796014e5b1b695b
Reviewed-on: https://go-review.googlesource.com/c/go/+/527339
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
- Use the test binary itself for printing paths instead of building a
separate binary and running it through additional subprocesses.
- Factor out a common chdir helper.
- Use t.Setenv where appropriate.
- Reduce indirection in test helpers.
- Set NoDefaultCurrentDirectoryInExePath consistently in the
environment.
Also add a test case demonstrating an interesting behavior for
relative paths that may interact with #62596.
Fixes#62594.
For #62596.
Change-Id: I19b9325034edf78cd0ca747594476cd7432bb451
Reviewed-on: https://go-review.googlesource.com/c/go/+/528035
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For ELF targets, the code in the go linker that generates the
".shstrtab" section was using a loader symbol to accumulate the
contents of the section, then setting the section type to
sym.SELFROSECT. This resulted in a section whose offset indicated that
it fell into a loadable ELF segment, which is not how the .shstrtab is
supposed to work (it should be outside of all loadable segments,
similar to .strtab and .symtab). The peculiar .shstrtab caused
confusion in third party tools that operate on ELF files, notably
llvm-strip.
This patch rewrites the .shstrtab generation code to avoid using a
loader.Symbol and instead accumulate the contents of the section into
a regular byte slice, then emit the section's data in the same way
that .strtab is handled.
Fixes#62600.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: Ie54020d7b2d779d3ac9f5465fd505217d0681f79
Reviewed-on: https://go-review.googlesource.com/c/go/+/528036
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL adds a new 'Tips' section to the cmd/compile README.
The primary intent is to help new-ish contributors.
It includes some basics on getting started, testing changes,
viewing coverage, juggling different compiler versions,
some links to additional tools, and so on.
Updates #30074
Change-Id: I393bf1137db9d2bb851f7e254b08455273ccad8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/503895
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: t hepudds <thepudds1460@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Saw this failing on windows like this:
--- FAIL: TestRenameCaseDifference (2.96s)
--- FAIL: TestRenameCaseDifference/dir (1.64s)
testing.go:1226: TempDir RemoveAll cleanup: remove C:\Users\gopher\AppData\Local\Temp\1\TestRenameCaseDifferencedir1375918868\001: The process cannot access the file because it is being used by another process.
--- FAIL: TestRenameCaseDifference/file (1.32s)
testing.go:1226: TempDir RemoveAll cleanup: remove C:\Users\gopher\AppData\Local\Temp\1\TestRenameCaseDifferencefile3272269402\001: The process cannot access the file because it is being used by another process.
FAIL
The reason might be the directory fd is not closed. This may be
mitigated by retries in removeAll function from testing package,
but apparently it does not succeed all the time.
A link to the failed run which made me look into this: https://ci.chromium.org/ui/p/golang/builders/try/gotip-windows-386/b8770439049015378129/overview
Change-Id: Ibebe94958d1aef8d1d0eca8a969675708cd27a7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/527175
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Rob Pike <r@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This CL implements a decision tree for efficient routing.
The tree holds all the registered patterns. To match
a request, we walk the tree looking for a match.
Change-Id: I7ed1cdf585fc95b73ef5ca2f942f278100a90583
Reviewed-on: https://go-review.googlesource.com/c/go/+/527315
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Our goal for the new ServeMux patterns is to match the routing
performance of the existing ServeMux patterns. To achieve that
we needed to optimize lookup for small maps.
This CL introduces a simple data structure called a mapping that
optimizes lookup by using a slice for small collections of key-value
pairs, switching to a map when the collection gets large.
Mappings are a core part of the routing algorithm, which uses a
decision tree to match path elements. The children of a tree node are
held in a mapping.
Change-Id: I923b3ad1376ace2c3e3421aa9b802ad12d47c871
Reviewed-on: https://go-review.googlesource.com/c/go/+/526617
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
[This is a redo of CL 525455 with the test fixed on darwin by defining
_XOPEN_SOURCE, and disabled with android, musl, and openbsd, which do
not provide getcontext.]
Since CL 495855, Ms are cached for C threads calling into Go, including
the stack bounds of the system stack.
Some C libraries (e.g., coroutine libraries) do manual stack management
and may change stacks between calls to Go on the same thread.
Changing the stack if there is more Go up the stack would be
problematic. But if the calls are completely independent there is no
particular reason for Go to care about the changing stack boundary.
Thus, this CL allows the stack bounds to change in such cases. The
primary downside here (besides additional complexity) is that normal
systems that do not manipulate the stack may not notice unintentional
stack corruption as quickly as before.
Note that callbackUpdateSystemStack is written to be usable for the
initial setup in needm as well as updating the stack in cgocallbackg.
Fixes#62440.
For #62130.
Change-Id: I0fe0134f865932bbaff1fc0da377c35c013bd768
Reviewed-on: https://go-review.googlesource.com/c/go/+/527715
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This patch fixes an inconsistency in compiler flag handling introduced
accidentally in CL 521699. In the compiler we have both base.Flag.N
(which records whether the user has supplied the "-N" flag to disable
optimization) and base.Ctxt.Flag_optimize (which tracks whether
optimization is turned on). In this case Flag.N was updated without a
corresponding change to Ctxt.Flag_optimize, which led to problems with
DWARF generation for the runtime.
This CL doesn't include a regression test; a test will be added later
in the x/debug repo in a subsequent CL.
Updates #62523.
Change-Id: I0c383bb43ec0a0e7c12e7e2852c0590731416d6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/527319
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, linking a Go c-shared object with C code using Apple's
new linker, it fails with
% cc a.c go.so
ld: segment '__DWARF' filesize exceeds vmsize in 'go.so'
Apple's new linker has more checks for unmapped segments. It is
very hard to make it accept a Mach-O shared object with an
additional DWARF segment.
We may want to stop combinding DWARF into the shared object (see
also #62577). For now, disable DWARF by default in c-shared mode
on darwin. (One can still enable it with -ldflags=-w=0, which will
contain DWARF, but it will need the old C linker to link against
with.)
For #61229.
Change-Id: I4cc77da54fac10e2c2cbcffa92779cba82706d75
Reviewed-on: https://go-review.googlesource.com/c/go/+/527415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The "eface" in OEFACE suggests it's only for empty interfaces, and the
documentation suggests that too. But it's actually used for both empty
and non-empty interfaces, so rename to OMAKEFACE and adjust docs
accordingly.
Also, remove OCONVIDATA. This was used by the 1.18 frontend for
constructing interfaces containing derived types, but the unified
frontend always uses OCONVIFACE instead, so this is unused now.
Change-Id: I6ec5c62f909b26027f2804e5b3373b7a00029246
Reviewed-on: https://go-review.googlesource.com/c/go/+/527336
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This reverts CL 512155.
Reason for revert: CL 512155 introduced a race in that it caused
cmd.Start to set cmd.Path. Previously it was fine if code looked
at cmd.Path in one goroutine while calling cmd.Start in a different
goroutine.
A test case for this race is in CL 527495.
Change-Id: Ic18fdadf6763727f8ea748280d5f0e601b9bf374
Reviewed-on: https://go-review.googlesource.com/c/go/+/527337
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Previously, the unified frontend implemented unsafe.Sizeof, etc that
involved derived types by constructing a normal OSIZEOF, etc
expression, including fully instantiating their argument. (When
unsafe.Sizeof is applied to a non-generic type, types2 handles
constant folding it.)
This worked, but involves unnecessary work, since all we really need
to track is the argument type (and the field selections, for
unsafe.Offsetof).
Further, the argument expression could generate temporary variables,
which would then go unused after typecheck replaced the OSIZEOF
expression with an OLITERAL. This results in compiler failures after
CL 523315, which made later passes stricter about expecting the
frontend to not construct unused temporaries.
Fixes#62515.
Change-Id: I37baed048fd2e35648c59243f66c97c24413aa94
Reviewed-on: https://go-review.googlesource.com/c/go/+/527097
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Currently, cmd/compile optimizes `var a = true; var b = a` into `var a
= true; var b = true`. But this may not be safe if we need to
initialize any other global variables between `a` and `b`, and the
initialization involves calling a user-defined function that reassigns
`a`.
This CL changes staticinit to keep track of the initialization
expressions that we've seen so far, and to stop applying the
staticcopy optimization once we've seen an initialization expression
that might have modified another global variable within this package.
To help identify affected initializers, this CL adds a -d=staticcopy
flag to warn when a staticcopy is suppressed and turned into a dynamic
copy.
Currently, `go build -gcflags=all=-d=staticcopy std` reports only four
instances:
```
encoding/xml/xml.go:1600:5: skipping static copy of HTMLEntity+0 with map[string]string{...}
encoding/xml/xml.go:1869:5: skipping static copy of HTMLAutoClose+0 with []string{...}
net/net.go:661:5: skipping static copy of .stmp_31+0 with poll.ErrNetClosing
net/http/transport.go:2566:5: skipping static copy of errRequestCanceled+0 with ~R0
```
Fixes#51913.
Change-Id: Iab41cf6f84c44f7f960e4e62c28a8aeaade4fbcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/395541
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Currently, package runtime runs `osinit` before dynamic initialization
of package-scope variables; but on GOOS=linux, `osinit` involves
mutating `sigsetAllExiting`.
This currently works because cmd/compile and gccgo have
non-spec-conforming optimizations that statically initialize
`sigsetAllExiting`, but disabling that optimization causes
`sigsetAllExiting` to be dynamically initialized instead. This in turn
causes the mutations in `osinit` to get lost.
This CL moves the initialization of `sigsetAllExiting` from `osinit`
into its initialization expression, and then removes the special case
for continuing to perform the static-initialization optimization for
package runtime.
Updates #51913.
Change-Id: I3be31454277c103372c9701d227dc774b2311dad
Reviewed-on: https://go-review.googlesource.com/c/go/+/405549
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This was missed earlier, because NewConstAt is only used now to
construct the predeclared "true" and "false" constants. But these
constants are no longer actually accessed with unified IR.
For constant expressions, types2 (and go/types) sets
TypeAndValue.Value for the expression to the appropriate constant
value. The unified writer recognizes when expressions are constants,
and simply writes the underlying value, regardless of the original
expression. As a result, we never end up actually referencing the
*named* "true" and "false" constants; we just always construct
anonymous constant "true" and "false" values.
However, a manually constructed tree that includes an *ir.Name that
"Uses" the predeclared true/false Const Objects, yet doesn't set
TypeAndValue.Value will instead end up trying to use named constants
constructed with NewConstAt.
Thanks to Russ for reporting the issue on CL 510541, and to Cuong for
identifying the fix.
Change-Id: I0614105379d63ea76d7244ebd1e4db5c239d4670
Reviewed-on: https://go-review.googlesource.com/c/go/+/524357
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When creating the struct type to hold variables captured by a function
literal, we currently reuse the captured variable names as fields.
However, there's no particular reason to do this: these struct types
aren't visible to users, and it adds extra complexity in making sure
fields belong to the correct packages.
Further, it turns out we were getting that subtly wrong. If two
function literals from different packages capture variables with
identical names starting with an uppercase letter (and in the same
order and with corresponding identical types) end up in the same
function (e.g., due to inlining), then we could end up creating
closure struct types that are "different" (i.e., not types.Identical)
yet end up with equal LinkString representations (which violates
LinkString's contract).
The easy fix is to just always use simple, exported, generated field
names in the struct. This should allow further struct reuse across
packages too, and shrink binary sizes slightly.
Fixes#62498.
Change-Id: I9c973f5087bf228649a8f74f7dc1522d84a26b51
Reviewed-on: https://go-review.googlesource.com/c/go/+/527135
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Standard Ms set g0.stackguard1 to the same value as stackguard0 in
mstart0. For consistency, extra Ms should do the same for their g0. Do
this in needm -> callbackUpdateSystemStack.
Background: getg().stackguard1 is used as the stack guard for the stack
growth prolouge in functions marked //go:systemstack [1]. User Gs set
stackguard1 to ^uintptr(0) so that the check always fail, calling
morestackc, which throws to report a //go:systemstack function call on a
user stack.
g0 setting stackguard1 is unnecessary for this functionality. 0 would be
sufficient, as g0 is always allowed to call //go:systemstack functions.
However, since we have the check anyway, setting stackguard1 to the
actual stack bound is useful to detect actual stack overflows on g0
(though morestackc doesn't detect this case and would report a
misleading message about user stacks).
[1] cmd/internal/obj calls //go:systemstack functions AttrCFunc. This is
a holdover from when the runtime contained actual C functions. But since
CL 2275, it has simply meant "pretend this is a C function, which would
thus need to use the system stack". Hence the name morestackc. At this
point, this terminology is pretty far removed from reality and should
probably be updated to something more intuitive.
Change-Id: I8d0e5628ce31ac6a189a7d7a4124be85aef89862
Reviewed-on: https://go-review.googlesource.com/c/go/+/527056
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Since CL 495855, Ms are cached for C threads calling into Go, including
the stack bounds of the system stack.
Some C libraries (e.g., coroutine libraries) do manual stack management
and may change stacks between calls to Go on the same thread.
Changing the stack if there is more Go up the stack would be
problematic. But if the calls are completely independent there is no
particular reason for Go to care about the changing stack boundary.
Thus, this CL allows the stack bounds to change in such cases. The
primary downside here (besides additional complexity) is that normal
systems that do not manipulate the stack may not notice unintentional
stack corruption as quickly as before.
Note that callbackUpdateSystemStack is written to be usable for the
initial setup in needm as well as updating the stack in cgocallbackg.
Fixes#62440.
For #62130.
Change-Id: I7841b056acea1111bdae3b718345a3bd3961b4a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/525455
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The new inliner tries to de-prioritize inlining of call sites on panic
paths, e.g. for a call such as the one to "foo" below, the inliner
will use a much lower size threshold when deciding whether to inline,
since the path is very likely to be "cold".
if mumble() {
foo() <<-- here
panic("bad")
}
This patch reworks one of the traceback tests is relying on the old
inliner's "inline F everywhere if F inlinable" strategy by tweaking
the code slightly (no change in test functionality).
Change-Id: I83a686b0cc4d94a6cfc63d1e84e45455c1afd5b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/519196
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Assign scores to callsites based on previously computed function
properties and callsite properties. This currently works by taking the
size score for the function (as computed by CanInline) and then making
a series of adjustments, positive or negative based on various
function and callsite properties.
NB: much work also remaining on deciding what are the best score
adjustment values for specific heuristics. I've picked a bunch of
arbitrary constants, but they will almost certainly need tuning and
tweaking to arrive at something that has good performance.
Updates #61502.
Change-Id: I887403f95e76d7aa2708494b8686c6026861a6ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/511566
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add code to detect call sites that are nested in loops, call sites
that are on an unconditional path to panic/exit, and call sites within
"init" functions. The panic-path processing reuses some of the
logic+state already present for the function flag version of "calls
panic/exit".
Updates #61502.
Change-Id: I1d728e0763282d3616a9cbc0a07c5cda115660f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/511565
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Build up a table of (potentially) inlinable call sites during inline
heuristic analysis, and introduce a framework for analyzing each call
site to collect applicable flags (for example, is call nested in
loop). This patch doesn't include any of the flag analysis, just the
machinery to collect the callsites and a regression test harness.
Updates #61502.
Change-Id: Ieaf4a008ac9868e9762c63f5b59bd264dc71ab30
Reviewed-on: https://go-review.googlesource.com/c/go/+/511564
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Extend the code that computes various properties and parameter flags
to incorporate information from export data in addition to things we
can get from the current package. Specifically:
- when deciding whether the current function always calls panic/exit,
check to see whether it has an unconditional call to some other
function that has that flag.
- when computing "parameter feeds" properties, look not just for
cases where a parameter feeds an interesting construct (if/switch,
indirect/interface call, etc) but where it feeds a call whose
corresponding param has that flag.
- when computing return properties, if a given return is always the
results of a call to X, then set the return properties to those
of X.
Updates #61502.
Change-Id: I6472fe98759cccad05b8eed58e4fc568201d88ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/511563
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Augment the ir.Inline container to include an entry for function
properties (currently serialized as a string), and if
GOEXPERIMENT=newinliner is set, compute and store function
properties for all inline candidates processed by the inliner.
The idea here is that if the function properties are going to drive
inlining decisions, we'd like to have the same info from non-local /
imported functions as for local / in-package functions, hence we need
to include the properties in the export data.
Hand testing on the compiler itself and with k8s kubelet shows that
this increases the size of export data overall by about 2-3 percent,
so a pretty modest increase.
Updates #61502.
Change-Id: I9d1c311aa8418d02ffea3629c3dd9d8076886d15
Reviewed-on: https://go-review.googlesource.com/c/go/+/511562
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Add code to analyze properties of function params, specifically
heuristics to look for cases where unmodified params feed into "if"
and "switch" statements in ways that might enable constant folding
and/or dead code elimination if the call were inlined at a callsite
that passes a constant to the correct param. We also look for cases
where a function parameter feeds unmodified into an interface method
call or indirect call.
Updates #61502.
Change-Id: Iaf7297e19637daeabd0ec72be88d654b545546ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/511561
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Clang 14+ introduced a warning when using mixed packed and unpacked structs.
This can cause problems when taking an address of the unpacked struct, which
may end up having a different alignment than expected.
This is not a problem in cgo, which does not take pointers from the packed
struct.
Fixes#62480
Change-Id: If5879eea5e1b77bc6dc7430f68f8c916bff9b090
Reviewed-on: https://go-review.googlesource.com/c/go/+/526915
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
withTCPConnPair is supposed to return only when both peer functions
have completed. However, due to the use of "defer" it was closing the
peers' connections after the synchronization point instead of before.
Fixes#62542.
Change-Id: I3e06c78984664172ff2d28b0fc582b8182f710f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/526977
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Commit-Queue: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This is an implementation of proposal #61758.
It adds a function to slogtest that runs each test case in a subtest,
instead of running them all at once.
That allows the caller to control which cases are run.
Fixes#61706.
Fixes#61758.
Change-Id: I95108b7b753675203ca7f0f00ccbc242bd9c2a9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/516076
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
This method is only used to find the path of the function being
compiled for hash debugging, but it was instead returning the path of
the package being compiled. These are typically the same, but can be
different for certain functions compiled across package boundaries
(e.g., method value wrappers and generic functions).
It's redundant either with f.fe.Func().Sym().Pkg.Path (package path of
the function being compiled) or f.Config.ctxt.Pkgpath (package path of
the compilation unit), so just remove it instead.
Change-Id: I1daae09055043d0ecb1fcc874a0b0006a6f8bddf
Reviewed-on: https://go-review.googlesource.com/c/go/+/526516
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
One of the more tedious quirks of the original frontend (i.e.,
typecheck) to preserve was that it preserved the original
representation of constants into the backend. To fit into the unified
IR model, I ended up implementing a fairly heavyweight workaround:
simply record the original constant's string expression in the export
data, so that diagnostics could still report it back, and match the
old test expectations.
But now that there's just a single frontend to support, it's easy
enough to just update the test expectations and drop this support for
"raw" constant expressions.
Change-Id: I1d859c5109d679879d937a2b213e777fbddf4f2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/526376
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Currently, for non-cgo programs, the g0 stack size is 8 KiB on
most platforms. With PGO which could cause aggressive inlining in
the runtime, the runtime stack frames are larger and could
overflow the 8 KiB g0 stack. Increase it to 16 KiB. This is only
one per OS thread, so it shouldn't increase memory use much.
Fixes#62120.
Fixes#62489.
Change-Id: I565b154517021f1fd849424dafc3f0f26a755cac
Reviewed-on: https://go-review.googlesource.com/c/go/+/526995
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 513779 added crude skips for tests that couldn't work when run under
'unshare --net --map-root-user' as used by the current iteration of the
no-network check in LUCI. Bryan suggested a more targeted way to detect
when the environment is insufficient, which makes it possible to remove
the builder-specific skip and its slightly incorrect explaining comment.
Updates #30612.
Change-Id: I0de79f44ab94d7f1018384c2e959ca7df3a1b0ae
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-amd64-longtest-race
Reviewed-on: https://go-review.googlesource.com/c/go/+/526835
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL adds support for debugger function calls on linux ppc64le
platform. The protocol is basically the same as in CL 395754, except for
the following differences:
1, The abi differences which affect parameter passing and frame layout.
2, The closure register is R11.
3, Minimum framesize on pp64le is 32 bytes
4, Added functions to return parent context structure for general purpose
registers in order to work with the way these structures are defined in
ppc64le
Change-Id: I58e01fedad66a818ab322e2b2d8f5104cfa64f39
Reviewed-on: https://go-review.googlesource.com/c/go/+/512575
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Archana Ravindar <aravinda@redhat.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add PidFD support, so that if the PidFD pointer in SysProcAttr is not
nil, ForkExec (and thus all its users) obtains a pidfd from the kernel
during clone(), and writes the result (or -1, if the functionality
is not supported by the kernel) into *PidFD.
The functionality to get pidfd is implemented for both clone3 and clone.
For the latter, an extra argument to rawVforkSyscall is needed, thus the
change in asm files.
Add a trivial test case checking the obtained pidfd can be used to send
a signal to a process, using pidfd_send_signal. To test clone3 code path,
add a flag available to tests only.
Updates #51246.
Change-Id: I2212b69e1a657163c31b4a6245b076bc495777a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/520266
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
Right now debuggers like Delve rely on the new goroutine created to run
a debugcall function to run on the same thread it started on, up until
it hits itself with a SIGINT as part of the debugcall protocol.
That's all well and good, except debugCallWrap1 isn't particularly
careful about not growing the stack. For example, if the new goroutine
happens to have a stale preempt flag, then it's possible a stack growth
will cause a roundtrip into the scheduler, possibly causing the
goroutine to switch to another thread.
Previous attempts to just be more careful around debugCallWrap1 were
helpful, but insufficient. This change takes everything a step further
and always locks the debug call goroutine and the new goroutine it
creates to the OS thread.
For #61732.
Change-Id: I038f3a4df30072833e27e6a5a1ec01806a32891f
Reviewed-on: https://go-review.googlesource.com/c/go/+/515637
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If a program imports the plugin package, the mechanisms in place for
detecting and deleting unused global map variables are no longer safe,
since it's possibly for a given global map var to be unreferenced in
the main program but referenced by a plugin. This patch changes the
linker to test for plugin use and to avoid removing any unused global
map variables if the main program could possibly load up a plugin.
Fixes#62430.
Change-Id: Ie00b18b681cb0d259e3c859ac947ade5778cd6c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/526115
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is part of a series of CLs that aim to reduce how often
interface arguments escape for the print functions in fmt.
Prior to this change, one reason arguments escape is because
printValue calls reflect.Value.Slice, which causes its
value argument to escape (though at this CL, that is
shrouded in the fmt escape analysis logs by other
printValue escape reasons).
This CL avoids that usage by calling f.Bytes instead,
which is possible because we know f is a slice of bytes
or an addressable array of bytes.
Arguments still escape for other reasons.
Change-Id: Ic3f064117a364007e1dd3197cef9d641abbf784a
Reviewed-on: https://go-review.googlesource.com/c/go/+/524940
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: t hepudds <thepudds1460@gmail.com>
This is part of a series of CLs that aim to reduce how often
interface arguments escape for the print functions in fmt.
Prior to this change, one reason arguments escape is because
fmtPointer calls reflect.Value.Pointer:
./print.go:551:39: parameter value leaks to <heap> for (*pp).fmtPointer with derefs=0:
./print.go:551:39: flow: <heap> ← value:
./print.go:551:39: from reflect.Value.Pointer(value) (call parameter) at ./print.go:555:20
printValue also has its value argument escape for this reason,
among others.
This CL changes those uses to reflect.Value.UnsafePointer instead,
which does not cause an escape.
Arguments still escape for other reasons.
Change-Id: I81c4f737f11fe835c5ccb122caee40a39b553451
Reviewed-on: https://go-review.googlesource.com/c/go/+/524939
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: t hepudds <thepudds1460@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The test function fi is used in TestEscape, and the intent of fi
seems to be to leak its argument, but fi is currently
sensitive to changes in escape analysis regarding interface receivers.
Make fi less sensitive by directly leaking its argument.
Change-Id: I16cc3d3a6bd7b08a08c8fc292b0b99c9a54d68d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/524943
Run-TryBot: t hepudds <thepudds1460@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Add a flag to ir.Func's flags field to record whether a given function
is deemed to never return (e.g. always calls exit or panic or
equivalent on all control paths). So as to not increase the amount of
flag storage, this new flag replaces the existing "ExportInline" flag,
which is currently unused.
Change-Id: Idd336e47381048cfc995eda05faf8b62f06ba206
Reviewed-on: https://go-review.googlesource.com/c/go/+/518256
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The HTML specification has incredibly complex rules for how to handle
"<!--", "<script", and "</script" when they appear within literals in
the script context. Rather than attempting to apply these restrictions
(which require a significantly more complex state machine) we apply
the workaround suggested in section 4.12.1.3 of the HTML specification [1].
More precisely, when "<!--", "<script", and "</script" appear within
literals (strings and regular expressions, ignoring comments since we
already elide their content) we replace the "<" with "\x3C". This avoids
the unintuitive behavior that using these tags within literals can cause,
by simply preventing the rendered content from triggering it. This may
break some correct usages of these tags, but on balance is more likely
to prevent XSS attacks where users are unknowingly either closing or not
closing the script blocks where they think they are.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for
reporting this issue.
Fixes#62197
Fixes CVE-2023-39319
[1] https://html.spec.whatwg.org/#restrictions-for-contents-of-script-elements
Change-Id: Iab57b0532694827e3eddf57a7497ba1fab1746dc
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1976594
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/526157
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Add code to compute whether a given function appears to
unconditionally call panic or exit, as a means of driving inlining
decisions. Note that this determination is based on
heuristics/guesses, as opposed to strict safety analysis; in some
cases we may miss a function that does indeed always panic, or mark a
function as always invoking panic when it doesn't; the intent is get
the right answer in "most" cases.
Updates #61502.
Change-Id: Ibba3e60c06c2e54cf29b3ffa0f816518aaacb9a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/511558
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Generate RLDIC[LR] instead of MOVD mask, Rx; AND Rx, Ry, Rz.
This helps reduce code size, and reduces the latency caused
by the constant load.
Similarly, for smaller-than-register values, truncate constants
which exceed the range of the value's type to avoid needing to
load a constant.
Change-Id: I6019684795eb8962d4fd6d9585d08b17c15e7d64
Reviewed-on: https://go-review.googlesource.com/c/go/+/515576
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Prior to CL 458218, gentraceback ignored the SPWrite function flag on
the innermost frame when doing a precise traceback on the assumption
that precise tracebacks could only be started from the morestack
prologue, and that meant that the innermost function could not have
modified SP yet.
CL 458218 rearranged this logic a bit and unintentionally lost this
particular case. As a result, if traceback starts in an assembly
function that modifies SP (either as a result of stack growth or stack
scanning during a GC preemption), traceback stop at the SPWrite
function and then crash with "traceback did not unwind completely".
Fix this by restoring the earlier special case for when the innermost
frame is SPWrite.
This is a fairly minimal change that should be easy to backport. I
think a more robust change would be to encode this per-PC in the
spdelta table, so it would be clear that we're unwinding from the
morestack prologue and wouldn't rely on a complicated and potentially
fragile set of conditions.
Fixes#62326.
Change-Id: I34f38157631890d33a79d0bd32e32c0fcc2574e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/525835
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Use ^ and $ in the -run flag regular expression value when the intention
is to invoke a single named test. This removes the reliance on there not
being another similarly named test to achieve the intended result.
In particular, package syscall has tests named TestUnshareMountNameSpace
and TestUnshareMountNameSpaceChroot that both trigger themselves setting
GO_WANT_HELPER_PROCESS=1 to run alternate code in a helper process. As a
consequence of overlap in their test names, the former was inadvertently
triggering one too many helpers.
Spotted while reviewing CL 525196. Apply the same change in other places
to make it easier for code readers to see that said tests aren't running
extraneous tests. The unlikely cases of -run=TestSomething intentionally
being used to run all tests that have the TestSomething substring in the
name can be better written as -run=^.*TestSomething.*$ or with a comment
so it is clear it wasn't an oversight.
Change-Id: Iba208aba3998acdbf8c6708e5d23ab88938bfc1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/524948
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Kirill Kolyshkin <kolyshkin@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL is to add assembly instruction mnemonics for the following instructions, mainly used in crypto packages.
* KMA - cipher message with authentication
* KMCTR - cipher message with counter
Fixes#61163
Change-Id: Iff9a69911aeb4fab4bca8755b23a106eaebb2332
Reviewed-on: https://go-review.googlesource.com/c/go/+/515195
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
This is tiny optimization for growslice, which is probably too small to
measure easily.
Move the for loop to avoid multiple checks inside the loop.
Also, use >> 2 instead of /4, which generates fewer instructions.
Change-Id: I9ab09bdccb56f98ab22073f23d9e102c252238c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/493795
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Egon Elbre <egonelbre@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
There is not a great reason to hide the alphabet used
for StdEncoding, HexEncoding, and URLEncoding.
Although this is specified in RFC 4748,
showing it in GoDoc saves an extra click from going
to the RFC itself to see the alphabet being used.
Also, split exported and unexported constants apart
so that GoDoc renders more cleanly.
Fixes#55126
Change-Id: I03bfa607fb6c3df7f757e33fc0f4ec2b233de1a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/525296
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
The upcoming built-in zero value provides an idiomatic way
to test for zero by comparing to the zero literal: v == zero.
The reflect package is meant to provide a programmatic way to perform
operations that the Go language itself provides.
Thus, it seems prudent that reflect.ValueOf(&v).Elem().IsZero() is
identical to v == zero.
This change alters the behavior of Value.IsZero in two concrete ways:
* negative zero is identical to zero
* blank fields in a struct are ignored
Prior to this change, we were already in an inconsistent state
due to a regression introduced by CL 411478.
The new behavior was already the case for comparable composite types.
This change makes it consistent for all other types
(in particular incomparable composite types and standalone numbers).
Updates #61372Fixes#61827
Change-Id: Id23fb97eb3b8921417cc75a1d3ead963e22dc3d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/517777
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Rather than making these two different types, we can type alias them
together. This will ease converting cmd/internal/dwarf to use generics
in a subsequent CL.
The one unfortunate quirk is that while we'd currently like loader.Sym
to be the authoritative type, to break the cycle we have to instead
make loader.Sym an alias of sym.LoaderSym.
Change-Id: I6dde0d492ca89a478c2470c426bb4eed3393d680
Reviewed-on: https://go-review.googlesource.com/c/go/+/525195
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The old Go object file format used linker symbols like "gofile..foo"
to record references to the filename "foo". But the current object
file format has a dedicated section for file names, so we don't need
these useless prefixes anymore.
Also, change DWARF generation to pass around the src.Pos directly,
rather than the old file symbols, which it just turned back into a
file index before writing out anyway.
Finally, directly record the FileIndex into src.PosBase, so that we
can skip the map lookups.
Change-Id: Ia4a5ebfa95da271f2522e45befdb9f137c16d373
Reviewed-on: https://go-review.googlesource.com/c/go/+/523378
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
The time granularity on windows is large enough that setting even an
implausibly small timeout still gives ConnectEx enough time to succeed
before the timeout expires. That causes TestDialTimeout to sometimes
flake, because it expects to be able to provoke a timeout using some
nonzero duration.
This change takes a two-pronged approach to address the problem:
1. We can set a deadline on the FD more aggressively. (If the Context
has already expired, or the deadline is already known, we can go ahead
and set it on the fd without waiting for a background goroutine to get
around to it.)
2. We can reintroduce a test hook to ensure that Dial takes a
measurable amount of time before it completes, so that setting an
implausibly short deadline sets that deadline in the past instead of
the future.
Together, these reduce the flake rate on a windows-amd64-longtest
gomote from around 1-in-10 to less than 1-in-2000.
For #62377.
Change-Id: I03975c32f61fffa9f6f84efb3c474a01ac5a0d1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/524936
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Now we have two cases when we want to keep methods with a specific name:
calls to generic interface methods and MethodByName("Foo"). Both use
the same relocation type, so let us give it a name that is not limited
to the implementation of generic interfaces.
Also, introduce staticdata.StrSymNoCommon(). It creates a symbol that
does not appear in the final binary and only communicates arguments
to the linker.
Change-Id: Icc9f49febfde1f31a4455b5acb903e8838d1c0af
Reviewed-on: https://go-review.googlesource.com/c/go/+/523016
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Normally, a call to MethodByName() disables the DCE because the linker
assumes that any method can be accessed this way. This pessimises
the code generation for k8s.io/apimachinery which needs MethodByName()
to verify whether or not a struct implements DeepCopyInto(). It cannot
cast a struct to `interface { DeepCopyInto() Foo }` because the return
type may vary. Instead, it does the following:
if m := reflect.ValueOf(obj).MethodByName("DeepCopyInto"); ... {
In this case there is no need to disable the DCE altogether. It
suffices to add a relocation to keep methods named DeepCopyInto().
Fixes#62257.
Change-Id: I583c2f04d8309a8807de75cd962c04151baeeb1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/522436
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The check in prepareCgroupFD tried to find out if clone3 with
CLONE_INTO_CGROUP flag is supported, by supplying arguments in
SysProcAttr that will make ForkExec use clone3 with CLONE_INTO_CGROUP
and fail.
CL 456375 inadvertently broke the above check by adding more errno
values to ignore. As a result, TestUseCgroupFD is always skipped, even
when the test could in fact be run.
Fix by removing the check entirely, instead let's use the functionality
and figure out from the errno if this has failed because of unsupported
syscall, lack of permissions, or other reason.
Change-Id: I108b27b6cfeec390ebd3f161ac39e8597569b666
Reviewed-on: https://go-review.googlesource.com/c/go/+/520265
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
In inexact unification, when a named type matches against an inferred
unnamed type, we change the previously inferred type to the named type.
This preserves the type name and assignability.
We have to do the same thing when encountering a directional channel:
a bidirectional channel can always be assigned to a directional channel
but not the other way around. Thus, if we see a directional channel, we
must choose the directional channel.
This CL extends the previously existing logic for named types to
directional channels and also makes the code conditional on inexact
unification. The latter is an optimization - if unification is exact,
type differences don't exist and updating an already inferred type has
no effect.
Fixes#62157.
Change-Id: I807e3b9f9ab363f9ed848bdb18b2577b1d680ea7
Reviewed-on: https://go-review.googlesource.com/c/go/+/521500
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
TestDialTimeout has historically been very flaky
(#11872, #13144, #22896, and now #56876),
apparently in part due to implementation details of the socktest
package it relies on.
In reviewing CL 467335, I noticed that TestDialTimeout is the last
remaining use of testHookDialChannel (added for #5349), and that that
hook no longer has any effect for Unix and Windows.
As an experiment, I tried removing both that hook and the call to
time.Sleep in the socktest filter, and to my surprise the test
continued to pass. That greatly undermined my confidence in the test,
since it appears that the “timeout” behavior it observes is caused by
the socktest filter injecting an error rather than anything in the net
package proper actually timing out.
To restore confidence in the test, I think it should be written
against only the public API of the net package, and should test the
publicly-documented behaviors. This change implements that approach.
Notably, when a timeout is set on a Dial call, that does not guarantee
that the listener will actually call Accept on the connection before
the timeout occurs: the kernel's network stack may preemptively accept
and buffer the connection on behalf of the listener. To avoid test
flakiness, the test must tolerate (and leave open) those spurious
connections: when the kernel has accepted enough of them, it will
start to block new connections until the buffered connections have
been accepted, and the expected timeout behavior will occur.
This also allows the test to run much more quickly and in parallel:
since we are relying on real timeouts instead of injected calls to
time.Sleep, we can set the timeouts to be much shorter and run
concurrently with other public-API tests without introducing races.
Fixes#56876.
Change-Id: I90dcb2ed70976e70857ca29c253ed760cb078a4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/524055
TryBot-Bypass: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
The object file format now has an explicit section for tracking which
packages were imported, so we don't need to write out importpath
symbols for all directly imported packages anymore.
However, keep the logic for writing out individual importpath symbols,
because it's still relevant to runtime type descriptor generation.
Change-Id: I184ff320e894ba43ca0f8a3d2678e4b2bbbe6da5
Reviewed-on: https://go-review.googlesource.com/c/go/+/523875
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
We don't actually depend on Inl.Body anywhere, except it implicitly
serves to indicate whether Inl.Dcl has been populated. So replace it
with a boolean so we don't need to keep a useless copy of every
inlinable function body in memory.
While here, also add some Fatalfs to make sure there are no unused
local variables. The unified frontend now omits unreachable code
during export data writing, so there shouldn't be unused local
variables.
Also, since unified IR uses the same code/data to construct the
original function as inlined and/or imported functions, the Dcl list
should always be the same, which addresses the real root issue (i.e.,
that export/import could skew the Dcl lists).
Change-Id: I6e3435f3a0352f6efbae787344006efac1891e84
Reviewed-on: https://go-review.googlesource.com/c/go/+/523315
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
cmd/asm and cmd/compile now always create symbols with the appropriate
package prefixes, so cmd/internal/dwarf and cmd/internal/obj can stop
worrying about qualifying names itself.
Change-Id: I9aee5d759bf0d41a61722c777e7f66fce957e79e
Reviewed-on: https://go-review.googlesource.com/c/go/+/523338
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL changes cmd/internal/obj to also implicitly set
ArgsPointerMaps and ArgInfo for assembly functions that are explicitly
package qualified (e.g., "pkg·name", not just "·name"). This is a
prerequisite for changing cmd/asm to stop emitting `"".`-prefixed
symbol names.
Change-Id: I4e14bc24c87cf4d7114a7aed9beaf0c8d1f9c07f
Reviewed-on: https://go-review.googlesource.com/c/go/+/523335
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Several of the tests in crypto/des were using the unexported
desCipher type and other unexported functions to test the package,
leaving desCipher.Encrypt and desCipher.Decrypt only partially tested.
This CL changes the tests to use the public API, except for
TestInitialPermute and TestFinalPermute, which are testing
implementation details on purpose.
Change-Id: I0bc13cea06b79b29425412b9bf36b997871518ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/520495
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Internally the security model for the image package has always been,
if you don't call DecodeConfig before Decode, you cannot complain if
Decode attempts to create an arbitrarily large image (with the
assumption that DecodeConfig would've told you this information). This
should be explicitly documented.
Change-Id: I5c37b91131d6352637e725fe415f37a28f12f66d
Reviewed-on: https://go-review.googlesource.com/c/go/+/523578
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
StructOf() calls reflect.Type.Method(), but looks up only methods
accessible via interfaces. DCE does not remove such methods, so
there is no need to disable the DCE if StructOf() is used.
There is a dependency chain between struct rtype and StructOf():
(*rtype).Method() -> FuncOf() -> initFuncTypes() -> StructOf().
Thus, any use of (*rtype).Method() or (*rtype).MethodByName()
disables the DCE in the linker. This is not an issue just yet
because all users of Method() and MethodByName() are flagged
as ReflectMethods. A subsequent patch avoids this flag on callers
of MethodByName(string literal). When that patch is applied,
it becomes important to have no ReflectMethods down the call
chain of MethodByName().
Change-Id: I9b3e55c495c122ed70ef31f9d978c0e2e0573799
Reviewed-on: https://go-review.googlesource.com/c/go/+/522435
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
We have obj.Link.Pkgpath, so we don't need to pass it redundantly in
places where we already have an *obj.Link.
Also, renaming the parser's "compilingRuntime" field to "allowABI", to
match the "AllowAsmABI" name used by objabi.LookupPkgSpecial.
Finally, push the handling of GOEXPERIMENT_* flags up to cmd/asm's
main entry point, by simply appending them to flags.D.
Change-Id: I6ada134522b0cbc90d35bcb145fbe045338fefb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/523297
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously, the frame pointer wouldn't be restored at all, which could
cause panics during frame pointer unwinding. As of CL 516157, the frame
pointer is restored, but it's restored incorrectly on arm64: on arm64,
the frame pointer points one word below SP, but here it's one below
panic.fp which is the stack pointer of the caller's frame (nothing to do
with the architectural bp).
For #61766.
Change-Id: I86504b85a4d741df5939b51c914d9e7c8d6edaad
Reviewed-on: https://go-review.googlesource.com/c/go/+/523697
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Implement better classification for load and store pair operations. This in
turn allows us to avoid using pool literals when the offset fits in a 24 bit
unsigned immediate. In this case, the offset can be calculated using two
add immediate instructions, rather than loading the offset from the pool
literal and then adding the offset to the base register. This requires the
same number of instructions, however avoids a load from memory and does
not require the offset to be stored in the literal pool.
Updates #59615
Change-Id: I316ec3d54f1d06ae9d930e98d0c32471775fcb26
Reviewed-on: https://go-review.googlesource.com/c/go/+/515615
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joedian Reid <joedian@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The edwards25519 tests can be quite slow on platforms without a
well-optimized implementation, especially if the race detector is also
enabled. Since these tests aren't checking for specific inputs anyway,
the extra coverage of a more aggressive quick.Config does not seem
worth wasting extra time on slow CI builders and TryBots.
For #60109.
Change-Id: I530e75a0b76725585df5a2f5ded6705ab1b9da51
Reviewed-on: https://go-review.googlesource.com/c/go/+/522715
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
case: passing a single Go string object to C function.
result: 87 ns vs 61 ns.
BenchmarkCgoCall/string-pointer-escape
BenchmarkCgoCall/string-pointer-escape-12 67731663 87.02 ns/op
BenchmarkCgoCall/string-pointer-noescape
BenchmarkCgoCall/string-pointer-noescape-12 99424776 61.30 ns/op
For #56378
Change-Id: Iff5c69d8deedfa248f5d7399e1921a5cb0dc8b16
GitHub-Last-Rev: fc67d5ad7a
GitHub-Pull-Request: golang/go#62297
Reviewed-on: https://go-review.googlesource.com/c/go/+/522939
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Code examples sometimes mistakenly use curvy quotes,
leading to hard-to-spot invalid token errors.
This change makes the error message explicit.
(An alternative change would be to accept them in place
of "abc" and emit an error, but the extra check would
likely add an unacceptable dynamic cost to string scanning.)
Fixes#61450
Change-Id: Ie2b18c958c6f8f71a56ac193a94a8d16eea839db
Reviewed-on: https://go-review.googlesource.com/c/go/+/512855
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In CL 522879, I moved the logic for setting Addrtaken from typecheck's
markAddrOf and ComputeAddrtaken directly into ir.NewAddrExpr. However,
I took the logic from markAddrOf, and failed to notice that
ComputeAddrtaken also set Addrtaken on the canonical ONAME.
The result is that if the only address-of expressions were within a
function literal, the canonical variable never got marked Addrtaken.
In turn, this could cause the consistency check in ir.Reassigned to
fail. (Yay for consistency checks turning mistakes into ICEs, rather
than miscompilation.)
Fixes#62313.
Change-Id: Ieab2854cd7fcc1b6c5d1e61de66453add9890a4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/523375
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change removes the per GOOS hostLookupOrder wrappers.
passes the correct hostname to hostLookupOrder (windows,
plan9), so that the netdns+2 GODEBUG doesn't show empty
hostnames.
Uses the mustUseGoResolver instead of hostLookupOrder,
hostLookupOrder should only be used for hostname resolution,
not for lookups that do only DNS.
Change-Id: I18bbff06957910ae25c2bc78dfa9a46da76529fd
GitHub-Last-Rev: a27545dc25
GitHub-Pull-Request: golang/go#61525
Reviewed-on: https://go-review.googlesource.com/c/go/+/512215
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Mateusz Poliwczak <mpoliwczak34@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Setting LD_LIBRARY_PATH when running "go test" for a package that uses
SWIG dates back to the initial introduction of SWIG support in
CL 5845071 in 2012. Back then SWIG worked by creating a shared library,
but in CL 6851 in 2015 we changed SWIG to generate cgo input files,
and no shared library was used. Since we no longer use a shared library,
we no longer need to set LD_LIBRARY_PATH.
Change-Id: I31ecc03c6c52f4efdf2ef6fb3ebeab35adc325aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/522035
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The check for fragmentary post-handshake messages in QUICConn.HandleData
was reversed, resulting in a potential panic when HandleData receives
a partial message.
In addition, HandleData wasn't checking the size of buffered
post-handshake messages. Produce an error when a post-handshake
message is larger than maxHandshake.
TestQUICConnectionState was using an onHandleCryptoData hook
in runTestQUICConnection that was never being called.
(I think it was inadvertently removed at some point while
the CL was in review.) Fix this test while making the hook
more general.
Fixes#62266
Change-Id: I210b70634e50beb456ab3977eb11272b8724c241
Reviewed-on: https://go-review.googlesource.com/c/go/+/522595
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Marten Seemann <martenseemann@gmail.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This is a temporary workaround for issue #62277, to get the longtest
builders passing again. As mentioned on the issue, the underlying
issue was present even before CL 522318; it just now affects inlined
closures in initialization expressions too, not just explicit init
functions.
This CL can and should be reverted once that issue is fixed properly.
Change-Id: I612a501e131d1b5eea648aafeb1a3a3fe8fe8c83
Reviewed-on: https://go-review.googlesource.com/c/go/+/522935
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
When passing pointers of Go objects from Go to C, the cgo command generate _Cgo_use(pN) for the unsafe.Pointer type arguments, so that the Go compiler will escape these object to heap.
Since the C function may callback to Go, then the Go stack might grow/shrink, that means the pointers that the C function have will be invalid.
After adding the #cgo noescape annotation for a C function, the cgo command won't generate _Cgo_use(pN), and the Go compiler won't force the object escape to heap.
After adding the #cgo nocallback annotation for a C function, which means the C function won't callback to Go, if it do callback to Go, the Go process will crash.
Fixes#56378
Change-Id: Ifdca070584e0d349c7b12276270e50089e481f7a
GitHub-Last-Rev: f1a17b08b0
GitHub-Pull-Request: golang/go#60399
Reviewed-on: https://go-review.googlesource.com/c/go/+/497837
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
It isn't obvious that request bodies can be closed asynchronously,
and it's easy to overlook the documentation of this fact in
RoundTripper, which is a fairly low-level interface.
Change-Id: I3b825c505418af7e1d3f6ed58f3704e55cf16901
Reviewed-on: https://go-review.googlesource.com/c/go/+/523036
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
This test can return with a Transport still processing
an in-flight request, resulting in a test failure due
to the leaked Transport.
Avoid this by waiting for the Transport to close the
request body before returning.
Fixes#60264
Change-Id: I8d8b54f633c2e28da2b1bf1bc01ce09dd77769de
Reviewed-on: https://go-review.googlesource.com/c/go/+/522695
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Instead of constructing an untyped basic literal IR node, having
typecheck convert it and return a new one, only to extract the
constant.Value; just have typecheck export the underlying value
conversion function, so we can call it directly.
Change-Id: Ie98f5362b3926a728d80262b0274a0b4fd023eaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/522878
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
ErrorfVers used to be used by typecheck to report when new language
functionality was used, but the -lang flag (from go.mod) was set to an
older version. However, all of the callers have been since removed,
now that this is handled by types2.
And for the same reason, we can stop changing base.Flag.Lang. This was
previously a workaround so that the unified frontend could generate
arbitrary IR without upsetting typecheck, at a time when typecheck was
itself a real frontend. Now it's just a glorified desugaring pass.
Change-Id: I1c0316dbfe2e08ba089acd50fdfe20b17176be25
Reviewed-on: https://go-review.googlesource.com/c/go/+/522877
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
There are no changes to what is being tested.
No test cases were removed or added.
Changes made:
* Use a local implementation of test case position marking. See #52751.
* Use consistent names for all test tables and variables.
* Generally speaking, follow modern Go style guide for tests.
* Move global tables local to the test function if possible.
* Make every table entry run in a distinct testing.T.Run.
The purpose of this change is to make it easier to perform
v1-to-v2 development where we want v2 to support close to
bug-for-bug compatibility when running in v1 mode.
Annotating each test case with the location of the test data
makes it easier to jump directly to the test data itself
and understand why this particular case is failing.
Having every test case run in its own t.Run makes it easier
to isolate a particular failing test and work on fixing the code
until that test case starts to pass again.
Unfortunately, many tests are annotated with an empty name.
An empty name is better than nothing, since the testing framework
auto assigns a numeric ID for duplicate names.
It is not worth the trouble to give descriptive names to each
of the thousands of test cases.
Change-Id: I43905f35249b3d77dfca234b9c7808d40e225de8
Reviewed-on: https://go-review.googlesource.com/c/go/+/522880
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Optimize marshaling of maps by using slices.SortFunc.
This drops an unnecessary field from reflectWithString,
which also reduces the cost of each swap operation.
benchmark old ns/op new ns/op delta
BenchmarkMarshalMap-10 228 139 -39.24%
benchmark old allocs new allocs delta
BenchmarkMarshalMap-10 11 8 -27.27%
benchmark old bytes new bytes delta
BenchmarkMarshalMap-10 432 232 -46.30%
Change-Id: Ic2ba7a1590863c7536305c6f6536372b26ec9b0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/515176
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Load large constants into vector registers from rodata, instead of placing them
in the literal pool. This treats VMOVQ/VMOVD/VMOVS the same as FMOVD/FMOVS and
makes use of the existing mechanism for storing values in rodata. Two additional
instructions are required for a load, however these instructions are used
infrequently and already have a high latency.
Updates #59615
Change-Id: I54226730267689963d73321e548733ae2d66740e
Reviewed-on: https://go-review.googlesource.com/c/go/+/515617
Reviewed-by: Eric Fang <eric.fang@arm.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL arranges for package-scope initialization statements to be
constructed directly into their eventual "init" function, so we can
eliminate the roundabout solution of using InitTodoFunc.
While here, somewhat simplify and generalize the logic for outlining
map initialization statements.
Change-Id: I8aff042e6b266f7024de436424ec6711b8b69129
Reviewed-on: https://go-review.googlesource.com/c/go/+/522318
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
[This is a reattempt of go.dev/cl/520611.]
This CL reorganizes the top-level functions for handling package-level
declarations, runtime type descriptors, and SSA compilation to work in
a loop. This generalizes the loop that previously existed in dumpdata.
Change-Id: I7502798a8662b3cec92d3001169f3af4f804df2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/522339
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 23005 (back in 2016!) added logic to promote C compiler warnings to
errors when running on the Go builders.
CL 437298 kept the logic to promote warnings to errors on the
builders, but dropped the explanatory message, I believe
unintentionally. Indeed, now there isn't even a comment in the code
explaining what's going on.
This CL adds back an explanatory message to the printed output, which
also serves as a explanation in the code as to why we're checking
$GO_BUILDER_NAME.
Change-Id: I769c55d213f96f73d20a41ab926fb91e71a5a22c
Reviewed-on: https://go-review.googlesource.com/c/go/+/522775
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
TestUnshareMountNameSpaceChroot attempts to build a statically-linked
binary to run in a chroot, and sets CGO_ENABLED=0 in order to do so.
Rather than trying to figure out some other way to coax the linker
into building a static binary, let's just skip the test on Linux
platforms that require external linking (namely android/arm).
This should fix the build failure reported in
https://build.golang.org/log/1ea245a9c2e916c81043db177be76778bab00058.
While we're here, let's also fix the failure logging to make the text
readable!
Updates #46330.
Change-Id: I4fa07640ce012ac141bf4698bc3215a7f146062c
Reviewed-on: https://go-review.googlesource.com/c/go/+/522182
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test passes "-linkmode=external" to 'go run' to link the binary
using the system C linker.
CGO_ENABLED=0 explicitly tells cmd/go not to use the C toolchain,
so the test should not be run in that configuration.
Updates #46330.
Change-Id: I16ac66aac91178045f9decaeb28134061e9711f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/522495
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
We've added Unparen to go/ast, so add syntax.Unparen to be
consistent (and because it's similarly useful).
Also, types2 and noder both have similar functions for unpacking
ListExprs, so might as well add a common implementation in package
syntax too.
Finally, addressing the TODO: UnpackListExpr is small enough to be
inlined (when default optimizations are enabled), and for typical uses
of UnpackListExpr (e.g., "range UnpackListExpr(x)") the single-element
slice result is stack allocated in the caller. This CL adds a test
using testing.AllocsPerRun to ensure this remains so in the future.
Change-Id: I96a5591d202193ed5bf1ce6f290919107e3dc01b
Reviewed-on: https://go-review.googlesource.com/c/go/+/522336
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
According to RFC 8259, there are exactly 5 control characters
that have a shorter escape sequence than the generic \uXXXX format.
Over the years, we added ad-hoc support for the short sequences:
* https://go.dev/cl/4678046 supports \r and \n
* https://go.dev/cl/162340043 supports \t
This CL completes the set by supporting \b and \f.
This may change the encoding of strings in relatively rare cases,
but is a permissible change since the Go 1 compatibility document does
not guarantee that "json" produces byte-for-byte identical outputs.
In fact, we have made even more observable output changes in the past
such as with https://go.dev/cl/30371 which changes the representation
of many JSON numbers.
This change is to prepare the path forward for a potential
v2 "json" package, which has more consistent encoding of JSON strings.
Change-Id: I11102a0602dfb1a0c14eaad82ed23e8df7553c6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/521675
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Bryan Mills <bcmills@google.com>
On Unix platforms, testenv.Command sends SIGQUIT to stuck commands
before the test times out. For subprocesses that are written in Go,
that causes the runtime to dump running goroutines, and in other
languages it triggers similar behavior (such as a core dump).
If the subprocess is stuck due to a bug (such as #57999), that may
help to diagnose it.
For #57999.
Change-Id: I00f381b8052cbbb1a7eea90e7f102a3f68c842d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/521817
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
In go.dev/cl/517775, I moved the frontend's deadcode elimination pass
into unified IR. But I also made a small enhancement: a branch like
"if x || true" is now detected as always taken, so the else branch can
be eliminated.
However, the inliner also has an optimization for delaying the
introduction of the result temporary variables when there's a single
return statement (added in go.dev/cl/266199). Consequently, the
inliner turns "if x || true { return true }; return true" into:
if x || true {
~R0 := true
goto .i0
}
.i0:
// code that uses ~R0
In turn, this confuses phi insertion, because it doesn't recognize
that the "if" statement is always taken, and so ~R0 will always be
initialized.
With this CL, after inlining we instead produce:
_ = x || true
~R0 := true
goto .i0
.i0:
Fixes#62211.
Change-Id: Ic8a12c9eb85833ee4e5d114f60e6c47817fce538
Reviewed-on: https://go-review.googlesource.com/c/go/+/522096
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Currently it's impossible to identify in profiles where gcDrain-related
time is coming from. More specifically, what kind of worker. Create
trivial wrappers for each worker so that the difference shows up in
stack traces.
Also, clarify why gcDrain disables write barriers.
Change-Id: I966e3c0b1c583994e691f486bf0ed8cabb91dbbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/521815
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Make it possible to internally link cgo on riscv64, which also adds
support for SDYNIMPORT calls without external linking being required.
This reduces the time of an ./all.bash run on a Sifive Hifive Unleashed by
approximately 20% (~140 minutes down to ~110 minutes).
Change-Id: I43f1348de31672718ae8676cc82f6fdc1dfee054
Reviewed-on: https://go-review.googlesource.com/c/go/+/431104
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Than McIntosh <thanm@google.com>
For large interface -> concrete type switches, we can use a jump
table on some bits of the type hash instead of a binary search on
the type hash.
name old time/op new time/op delta
SwitchTypePredictable-24 1.99ns ± 2% 1.78ns ± 5% -10.87% (p=0.000 n=10+10)
SwitchTypeUnpredictable-24 11.0ns ± 1% 9.1ns ± 2% -17.55% (p=0.000 n=7+9)
Change-Id: Ida4768e5d62c3ce1c2701288b72664aaa9e64259
Reviewed-on: https://go-review.googlesource.com/c/go/+/521497
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
This lets us combine more write barriers, getting rid of some of the
test+branch and gcWriteBarrier* calls.
With the new write barriers, it's easy to add a few non-pointer writes
to the set of values written.
We allow up to 2 non-pointer writes between pointer writes. This is enough
for, for example, adjacent slice fields.
Fixes#62126
Change-Id: I872d0fa9cc4eb855e270ffc0223b39fde1723c4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/521498
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Due to a race condition persistConn could be closed without removing request canceler.
Note that without the fix test occasionally passes and to demonstrate the issue it has to be run multiple times, e.g. using -count=10.
Fixes#61708
Change-Id: I9029d7d65cf602dd29ee1b2a87a77a73e99d9c92
GitHub-Last-Rev: 6b31f9826d
GitHub-Pull-Request: golang/go#61745
Reviewed-on: https://go-review.googlesource.com/c/go/+/515796
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
An ETXTBSY error when starting a test binary is almost certainly
caused by the race reported in #22315. That race will resolve quickly
on its own, so we should just retry the command instead of reporting a
spurious failure.
Fixes#62221.
Change-Id: I408f3eaa7ab5d7efbc7a2b1c8bea3dbc459fc794
Reviewed-on: https://go-review.googlesource.com/c/go/+/522015
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
In checking whether a type implements an interface, there's this
complex predicate spanning multiple lines, which is very obtuse.
So let's just use the helper function we already have in package types
instead.
Change-Id: I80f69d41c2bee8d6807601cf913840fa4f042b5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/521435
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
The types.RecvsParamsResults, etc. helpers existed to make it "easier"
to iterate over all parameters, or recvs+params, or params+results;
but they end up still being quite clumsy to use due to the design goal
of not allocating temporary slices.
Now that recvs+params+results are stored in a single consecutive slice
anyway, we can just return different subslices and simplify the loops.
Change-Id: I84791b80dc099dfbfbbe6eddbc006135528c23b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/521375
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Now that all of the uses of signature types have been cleaned up, we
can simplify the internal representation significantly.
In particular, instead of 3 separate struct objects each with 3
separate slices of fields, we can store all of the parameters in a
single slice and track the boundaries between them.
We still need a results tuple struct for representing the type of
multi-value call expressions, but just a single one and it can safely
reuse the results subsection of the full parameters slice.
Note: while Sizeof(Func) has increased (e.g., 32->56 on amd64), we're
saving on the allocation of 2 Types, 2 Structs, and 2 []*Field (288
bytes total on amd64), not counting any extra GC size class padding
from using a single shared []*Field instead of 3 separate ones.
Change-Id: I119b5e960e715b3bc4f1f726e58b910a098659da
Reviewed-on: https://go-review.googlesource.com/c/go/+/521335
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Currently, this list includes *almost* all runtime packages, but not
quite all.
We leave out internal/bytealg for reasons explained in the code.
Compiling with or without race instrumentation has no effect on the
other packages added to the list here, so this is a no-op change
today, but makes this more robust.
Change-Id: Iaec585b2efbc72983d8cb3929394524c42dd664d
Reviewed-on: https://go-review.googlesource.com/c/go/+/521701
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This adds a test that all packages imported by runtime are marked as
runtime tests by LookupPkgSpecial. We add two packages that were
missing from the list.
Change-Id: I2545980ab09474de0181cf546541527d8baaf2e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/521700
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
As we did for the asm -compiling-runtime flag, this CL modifies the
compiler to compute the -+ (compiling runtime) flag from the package
path. Unlike for asm, some tests use -+ explicitly to opt in to
runtime restrictions, so we leave the flag, but it's no longer passed
by any build tools.
This lets us eliminate cmd/go's list of "runtime packages" in favor of
the unified objabi.LookupPkgSpecial. It also fixes an inconsistency
with dist, which only passed -+ when compiling "runtime" itself.
One consequence of this is that the compiler now ignores the -N flag
when compiling runtime packages. Previously, cmd/go would strip -N
when passing -+ and the compiler would fatal if it got both -N and -+,
so the overall effect was that the compiler never saw -N when
compiling a runtime package. Now we simply move that logic to disable
-N down into the compiler.
Change-Id: I4876047a1563210ed122a31b72d62798762cbcf5
Reviewed-on: https://go-review.googlesource.com/c/go/+/521699
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There are several implementations of "is this package path a runtime
package". They all have slightly different lists because they all care
about slightly different properties of building the runtime.
To start converging these, we replace objabi.IsRuntimePackagePath with
objabi.LookupPkgSpecial, which returns a struct we can extend with
various special build properties. We'll extend this with several other
flags in the following CLs.
Change-Id: I21959cb8c3d18a350d6060467681c72ea49af712
Reviewed-on: https://go-review.googlesource.com/c/go/+/521698
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Currently, dist and go pass a -compiling-runtime flag to asm if
they're compiling a runtime package. However, now that we always pass
the package path to asm, it can make that determination just as well
as its callers can. This CL moves that check into asm and drops the
flag.
This in turn makes dist's copy of IsRuntimePackagePath unnecessary, so
we delete it.
Change-Id: I6ecf2d50b5b83965012af34dbe5f9a973ba0778b
Reviewed-on: https://go-review.googlesource.com/c/go/+/521697
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, the types package has IsRuntimePkg and IsReflectPkg
predicates for testing if a Pkg is the runtime or reflect packages.
IsRuntimePkg returns "true" for any "CompilingRuntime" package, which
includes all of the packages imported by the runtime. This isn't
inherently wrong, except that all but one use of it is of the form "is
this Sym a specific runtime.X symbol?" for which we clearly only want
the package "runtime" itself. IsRuntimePkg was introduced (as
isRuntime) in CL 37538 as part of separating the real runtime package
from the compiler built-in fake runtime package. As of that CL, the
"runtime" package couldn't import any other packages, so this was
adequate at the time.
We could fix this by just changing the implementation of IsRuntimePkg,
but the meaning of this API is clearly somewhat ambiguous. Instead, we
replace it with a new RuntimeSymName function that returns the name of
a symbol if it's in package "runtime", or "" if not. This is what
every call site (except one) actually wants, which lets us simplify
the callers, and also more clearly addresses the ambiguity between
package "runtime" and the general concept of a runtime package.
IsReflectPkg doesn't have the same issue of ambiguity, but it
parallels IsRuntimePkg and is used in the same way, so we replace it
with a new ReflectSymName for consistency.
Change-Id: If3a81d7d11732a9ab2cac9488d17508415cfb597
Reviewed-on: https://go-review.googlesource.com/c/go/+/521696
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently the runtime marks all new memory as MADV_HUGEPAGE on Linux and
manages its hugepage eligibility status. Unfortunately, the default
THP behavior on most Linux distros is that MADV_HUGEPAGE blocks while
the kernel eagerly reclaims and compacts memory to allocate a hugepage.
This direct reclaim and compaction is unbounded, and may result in
significant application thread stalls. In really bad cases, this can
exceed 100s of ms or even seconds.
Really all we want is to undo MADV_NOHUGEPAGE marks and let the default
Linux paging behavior take over, but the only way to unmark a region as
MADV_NOHUGEPAGE is to also mark it MADV_HUGEPAGE.
The overall strategy of trying to keep hugepages for the heap unbroken
however is sound. So instead let's use the new shiny MADV_COLLAPSE if it
exists.
MADV_COLLAPSE makes a best-effort synchronous attempt at collapsing the
physical memory backing a memory region into a hugepage. We'll use
MADV_COLLAPSE where we would've used MADV_HUGEPAGE, and stop using
MADV_NOHUGEPAGE altogether.
Because MADV_COLLAPSE is synchronous, it's also important to not
re-collapse huge pages if the huge pages are likely part of some large
allocation. Although in many cases it's advantageous to back these
allocations with hugepages because they're contiguous, eagerly
collapsing every hugepage means having to page in at least part of the
large allocation.
However, because we won't use MADV_NOHUGEPAGE anymore, we'll no longer
handle the fact that khugepaged might come in and back some memory we
returned to the OS with a hugepage. I've come to the conclusion that
this is basically unavoidable without a new madvise flag and that it's
just not a good default. If this change lands, advice about Linux huge
page settings will be added to the GC guide.
Verified that this change doesn't regress Sweet, at least not on my
machine with:
/sys/kernel/mm/transparent_hugepage/enabled [always or madvise]
/sys/kernel/mm/transparent_hugepage/defrag [madvise]
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none [0 or 511]
Unfortunately, this workaround means that we only get forced hugepages
on Linux 6.1+.
Fixes#61718.
Change-Id: I7f4a7ba397847de29f800a99f9cb66cb2720a533
Reviewed-on: https://go-review.googlesource.com/c/go/+/516795
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
On Unix platforms, testenv.Command sends SIGQUIT to stuck commands
before the test times out. For subprocesses that are written in Go,
that causes the runtime to dump running goroutines, and in other
languages it triggers similar behavior (such as a core dump).
If the subprocess is stuck due to a bug (such as #57999), that may
help to diagnose it.
For #57999.
Change-Id: Ia2e9d14718a26001e030e162c69892497a8ebb21
Reviewed-on: https://go-review.googlesource.com/c/go/+/521816
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
When the write barrier does several pointer writes under one
write barrier flag check, the line numbers aren't really correct.
The writes inside the write barrier have a confusing set of positions.
The loads of the old values are given the line number of the
corresponding store instruction, but the stores into the write buffer
are given the line number of the first store. Instead, give them all
line numbers corresponding to the store instruction.
The writes at the merge point, which are the original writes and the
only ones that happen when the barrier is off, are currently all given
the line number of the first write. Instead give them their original
line number.
Change-Id: Id64820b707f45f07b0978f8d03c97900fdc4bc0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/521499
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
On some platforms asmcgocall can be called with a nil g. Additionally, it
can be called when already on a the system (g0) stack or on a signal stack.
In these cases we do not need to switch (and/or cannot switch) to the
system stack and as a result, do not need to save the g.
Rework asmcgocall on ppc64x to follow the pattern used on other architectures,
such as amd64 and arm64, where a separate nosave path is called in the above
cases. The nil g case will be needed to support openbsd/ppc64.
Updates #56001
Change-Id: I431d4200bcbc4aaddeb617aefe18590165ff2927
Reviewed-on: https://go-review.googlesource.com/c/go/+/478775
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL removes a lot of the redundant methods for accessing struct
fields and signature parameters. In particular, users never have to
write ".Slice()" or ".FieldSlice()" anymore; the exported APIs just do
what you want.
Further internal refactorings to follow.
Change-Id: I45212f6772fe16aad39d0e68b82d71b0796e5639
Reviewed-on: https://go-review.googlesource.com/c/go/+/521295
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Rather than constructing a new runtime._defer struct type at each
defer statement, we can use a single shared one. Also, by naming it
runtime._defer, we avoid emitting new runtime and DWARF type
descriptors in every package that contains a "defer" statement.
Shaves ~1kB off cmd/go.
Change-Id: I0bd819aec9f856546e684abf620e339a7555e73f
Reviewed-on: https://go-review.googlesource.com/c/go/+/521676
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
The example text below suggests that []byte("") always evaluates to
the non-nil value []byte{}, but the text proper doesn't explicitly
require that. This CL makes it clear that it must not evaluate to
[]byte(nil), which otherwise was allowed by the wording.
Change-Id: I6564bfd5e2fd0c820d9b55d17406221ff93ce80c
Reviewed-on: https://go-review.googlesource.com/c/go/+/521035
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
The go resolver shouldn't attempt to query .onion domains, but
the restriction was not restricted for search domains.
Also before this change query for "sth.onion" would
not be suffixed with any search domain (for "go.dev" search
domain, it should query fine the "std.onion.go.dev" domain).
Change-Id: I0f3e1387e0d59721381695f94586e3743603c30e
GitHub-Last-Rev: 7e8ec44078
GitHub-Pull-Request: golang/go#60678
Reviewed-on: https://go-review.googlesource.com/c/go/+/501701
Run-TryBot: Mateusz Poliwczak <mpoliwczak34@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is supposed to be an internal type within package types. At least
for now, users of the types package should stick to the types.Type
APIs as much as possible.
This CL also unexports FuncType and a few others to prevent
backsliding.
Change-Id: I053fc115a5e6a57c148c8149851a45114756072f
Reviewed-on: https://go-review.googlesource.com/c/go/+/521255
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that pcvalue keeps its cache on the M, we can drop all of the
stack-allocated pcvalueCaches and stop carefully passing them around
between lots of operations. This significantly simplifies a fair
amount of code and makes several structures smaller.
This series of changes has no statistically significant effect on any
runtime Stack benchmarks.
I also experimented with making the cache larger, now that the impact
is limited to the M struct, but wasn't able to measure any
improvements.
This is a re-roll of CL 515277
Change-Id: Ia27529302f81c1c92fb9c3a7474739eca80bfca1
Reviewed-on: https://go-review.googlesource.com/c/go/+/520064
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Currently, the pcvalue cache is stack allocated for each operation
that needs to look up a lot of pcvalues. It's not always clear where
to put it, a lot of the time we just pass a nil cache, it doesn't get
reused across operations, and we put a surprising amount of effort
into threading these caches around.
This CL moves it to the M, where it can be long-lived and used by all
pcvalue lookups, and we don't have to carefully thread it across
operations.
This is a re-roll of CL 515276 with a fix for reentrant use of the
pcvalue cache from the signal handler.
Change-Id: Id94c0c0fb3004d1fda1b196790eebd949c621f28
Reviewed-on: https://go-review.googlesource.com/c/go/+/520063
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
If we're not using the upper bits, don't bother issuing a
sign/zero extension operation.
For arm64, after CL 520916 which fixed a correctness bug with
extensions but as a side effect leaves many unnecessary ones
still in place.
Change-Id: I5f4fe4efbf2e9f80969ab5b9a6122fb812dc2ec0
Reviewed-on: https://go-review.googlesource.com/c/go/+/521496
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
When rewriting, for example, MSUBW, we need to ensure that the result
has its 32 top bits zeroed. That's what the instruction is spec'd to do.
Normally, we'd only use MSUBW for computations on 32-bit values, and
as such the top 32 bits aren't normally used. But some situations, like
if we cast the result to a uint64, the top 32 bits do matter.
This comes up in 62131 because we have a rule saying, MOVWUreg applied
to a MSUBW is unnecessary, as the arg to MOVWUreg already has zeroed
top 32 bits. But if MSUBW is later rewritten to another op that doesn't
zero the top 32 bits (SUB, probably), getting rid of the MOVWUreg earlier
causes a problem.
So change rewrite rules to always maintain the top 32 bits as zero if the
instruction is spec'd to provide that. We need to introduce a few *W operations
to make that happen.
Fixes#62131
Change-Id: If3d160821e285fd7454746b735a243671bff8894
Reviewed-on: https://go-review.googlesource.com/c/go/+/520916
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Condition variables are subtle and error-prone, and this example
demonstrates exactly the sorts of problems that they introduce.
Unfortunately, we're stuck with them for the foreseeable future.
As previously implemented, this example was racy: since the callback
passed to context.AfterFunc did not lock the mutex before calling
Broadcast, it was possible for the Broadcast to occur before the
goroutine was parked in the call to Wait, causing in a missed wakeup
resulting in deadlock.
The example also had a more insidious problem: it was not safe for
multiple goroutines to call waitOnCond concurrently, but the whole
point of using a sync.Cond is generally to synchronize concurrent
goroutines. waitOnCond must use Broadcast to ensure that it wakes up
the target goroutine, but the use of Broadcast in this way would
produce spurious wakeups for all of the other goroutines waiting on
the same condition variable. Since waitOnCond did not recheck the
condition in a loop, those spurious wakeups would cause waitOnCond
to spuriously return even if its own ctx was not yet done.
Fixing the aforementioned bugs exposes a final problem, inherent to
the use of condition variables in this way. This one is a performance
problem: for N concurrent calls to waitOnCond, the resulting CPU cost
is at least O(N²). This problem cannot be addressed without either
reintroducing one of the above bugs or abandoning sync.Cond in the
example entirely. Given that this example was already published in Go
1.21, I worry that Go users may think that it is appropriate to use a
sync.Cond in conjunction with context.AfterFunc, so I have chosen to
retain the Cond-based example and document its pitfalls instead of
removing or replacing it entirely.
I described this class of bugs and performance issues — and suggested
some channel-based alternatives — in my GopherCon 2018 talk,
“Rethinking Classical Concurrency Patterns”. The section on condition
variables starts on slide 37. (https://youtu.be/5zXAHh5tJqQ?t=679)
Fixes#62180.
For #20491.
Change-Id: If987cd9d112997c56171a7ef4fccadb360bb79bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/521596
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
When running make.bash in a cross-compiled configuration
(for example, GOARCH different from GOHOSTARCH), cmd/go
is installed to GOROOT/bin/GOOS_GOARCH instead of GOROOT/bin.
That means that we need to look for GOROOT in both ../.. and ../../..,
not just the former.
Fixes#62119.
Updates #18678.
Change-Id: I283c6a10c46df573ff44da826f870417359226a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/521015
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This comment got left behind in some refactoring and now refers to
code "below" that is no longer below. Move it to be with the code it's
referring to.
Change-Id: I7f7bf0cf8b22c1f6e05ff12b8be71d18fb3359d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/521177
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Bypass: Austin Clements <austin@google.com>
This CL refactors typecheck.DeclFunc to require the caller to have
already constructed the ir.Func and signature type using ir.NewFunc
and types.NewSignature, and simplifies typecheck.DeclFunc to simply
return the slices of param and results ONAMEs.
typecheck.DeclFunc was the last reason that ir.Field still exists, so
this CL also gets rid of that.
Change-Id: Ib398420bac2fd135a235810b8af1635fa754965c
Reviewed-on: https://go-review.googlesource.com/c/go/+/520977
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Map.String and expvarHandler used the %q flag with fmt.Fprintf
to escape Go strings, which does so according to the Go grammar,
which is not always compatible with JSON strings.
Rather than calling json.Marshal for every string,
which will always allocate, declare a local appendJSONQuote
function that does basic string escaping.
Also, we declare an unexported appendJSON method on every
concrete Var type so that the final JSON output can be
constructed with far fewer allocations.
The resulting logic is both more correct and also much faster.
This does not alter the whitespace style of Map.String or expvarHandler,
but may alter the representation of JSON strings.
Performance:
name old time/op new time/op delta
MapString 5.10µs ± 1% 1.56µs ± 1% -69.33% (p=0.000 n=10+9)
name old alloc/op new alloc/op delta
MapString 1.21kB ± 0% 0.66kB ± 0% -45.12% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
MapString 37.0 ± 0% 7.0 ± 0% -81.08% (p=0.000 n=10+10)
Fixes#59040
Change-Id: I46a2125f43550b91d52019e5edc003d9dd19590f
Reviewed-on: https://go-review.googlesource.com/c/go/+/476336
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
I believe this bug is introduced by CL 460543 which optimizes the allocations
by changing the type of `idToType` from map to slice, but didn't update the
access code in `Decoder.typeString` that is safe for map but not for slice.
Fixes#62117
Change-Id: I0f2e4cc2f34c54dada1f83458ba512a6fde6dcbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/520757
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
The only remaining use for typecheck.NeedRuntimeType is to make sure
that method expressions with anonymous receiver types (e.g.,
"struct{T}.M") have the promoted-method wrapper generated. But the
unified frontend takes care of arranging for this now.
Change-Id: I89340cb6a81343f35e0de1062610cbb993d3b6bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/521036
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The Encoding.DecodedLen API only returns the maximum length of the
expected decoded output, since it does not know about padding.
Since we have the input, we can do better by computing the
input length without padding, and then perform the DecodedLen
calculation as if there were no padding.
This avoids over-growing the destination slice if possible.
Over-growth is still possible since the input may contain
ignore characters like newlines and carriage returns,
but those a rarely encountered in practice.
Change-Id: I38b8f91de1f4fbd3a7128c491a25098bd385cf74
Reviewed-on: https://go-review.googlesource.com/c/go/+/520267
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Except for a single call site in escape analysis, every use of
ir.AsNode involves a types.Object that's known to contain
an *ir.Name. Asserting directly to that type makes the code simpler
and more efficient.
The one use in escape analysis is extended to handle nil correctly
without it.
Change-Id: I694ae516903e541341d82c2f65a9155e4b0a9809
Reviewed-on: https://go-review.googlesource.com/c/go/+/520775
TryBot-Bypass: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This type used to provide extra type safety around which syntactic
nodes could also represent types, but now the only remaining use is
ir.TypeNode, and it always ends up as an ir.Node anyway. So we might
as well use Node instead.
Change-Id: Ia0842864794365b0e155dc5af154c673ffa2967b
Reviewed-on: https://go-review.googlesource.com/c/go/+/520609
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
An *ir.Func is always ODCLFUNC, so no need to double-check this
anymore. The type system statically ensures we have the right Op.
Also, pkginit.initRequiredForCoverage appears to be unused, so we can
get rid of it completely.
Change-Id: If1abb35672b40f705f23c365ad2a828c2661e9c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/520603
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The wasip1 TCP echo test introduced in CL 493358 has a race
condition with port selection. The test runner probes for a free
port and then asks the WASM runtime to listen on the port, which
may be taken by another process in the interim.
Due to limitations with WASI preview 1, the guest is unable to
query the port it's listening on. The test cannot ask the WASM
runtime to listen on port 0 (choose a free port) since there's
currently no way for the test to query the selected port and
connect to it.
Given the race condition is unavoidable, this test is now disabled
by default and requires opt-in via an environment variable.
This commit also eliminates the hard-coded connection timeout.
Fixes#61820.
Change-Id: I375145c1a1d03ad45c44f528da3347397e6dcb01
Reviewed-on: https://go-review.googlesource.com/c/go/+/519895
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Currently TestMutexProfile expects contention to reported as somewhere
between 0.9x and 2.0x the expected amount introduced. While bounding
from below is fine (especially since the goroutine holding the mutex
doesn't even start to sleep until the required number of goroutines are
blocked on a mutex), bounding from above can easily lead to flakiness.
Delays and non-determinism can come from anywhere in the system,
and nevertheless clocks keep ticking. The result is that goroutines
could easily appear to be blocked on a mutex much longer than just the
sleep time.
However, the contention upper bound is still useful, especially for
identifying wildly incorrect values. Set the contention total to be
proportional to the total wall-time spent in the actual sampling mutex
block sampling portion of the code. This should be a generous
upper-bound on how much contention there could be, because it should in
theory capture any delays from the environment in it as well.
Still, rounding errors could be an issue, and on Windows the time
granularity is quite low (~15ms, or 15% of what each goroutine is
supposed to add to the mutex profile), so getting unlucky with where
time measurements fall within each tick could also be a problem. Add an
extra 10%, which seems to make it much less likely to fail in a Windows
gomote.
Fixes#62094.
Change-Id: I59a10a73affd077185dada8474b91d0bc43b4a43
Reviewed-on: https://go-review.googlesource.com/c/go/+/520635
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
String symbol names could contain weird characters as we put the
string literal into the symbol name. So it may appear to need
mangling. However, as string symbols are grouped into a single
"go:string.*" symbol, the individual symbol names actually don't
matter. So don't mangle them.
Also make the mangling code more defensive in case of weird
symbol names.
Fixes#62098.
Change-Id: I533012567a9fffab69debda934f426421c7abb04
Reviewed-on: https://go-review.googlesource.com/c/go/+/520856
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL implements the remainder of the zero-copy string->[]byte
conversion optimization initially attempted in go.dev/cl/520395, but
fixes the tracking of mutations due to ODEREF/ODOTPTR assignments, and
adds more comprehensive tests that I should have included originally.
However, this CL also keeps it behind the -d=zerocopy flag. The next
CL will enable it by default (for easier rollback).
Updates #2205.
Change-Id: Ic330260099ead27fc00e2680a59c6ff23cb63c2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/520599
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
In order for decoding to faithfully reproduce the encoded input,
the symbols must be unique (i.e., provide a bijective mapping).
Thus, reject duplicate symbols in NewEncoding.
As a minor optimization, modify WithPadding to use the decodeMap
to quickly check whether the padding character is used in O(1)
instead of O(32) or O(64).
Change-Id: I5631f6ff9335c35d59d020dc0e307e3520786fbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/520335
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Change the internal constant enableInterfaceInference to a unifier
field that can be controlled dynamically and set it for Go 1.21
or later.
This restores Go 1.20 unification behavior for interfaces.
Fixes#61903.
Change-Id: Iefd6c0899811f8208a8be9cef2650a07787ae177
Reviewed-on: https://go-review.googlesource.com/c/go/+/519855
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Irrespective of whether unification is exact or inexact, method
signatures of interfaces must always match exactly: a type never
satisfies/implements an interface if relevant method signatures
are different (i.e., not identical, possibly after substitution).
This change matches the fix https://go.dev/cl/519435.
For #61879.
Change-Id: I28b0a32d32626d85afd32e107efce141235a923d
Reviewed-on: https://go-review.googlesource.com/c/go/+/519455
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This CL enables the latent support for string->[]byte conversions
added go.dev/cl/520259.
One catch is that we need to make sure []byte("") evaluates to a
non-nil slice, even if "" is (nil, 0). This CL addresses that by
adding a "ptr != nil" check for OSTR2BYTESTMP, unless the NonNil flag
is set.
The existing uses of OSTR2BYTESTMP (which aren't concerned about
[]byte("") evaluating to nil) are updated to set this flag.
Fixes#2205.
Change-Id: I35a9cb16c164cd86156b7560915aba5108d8b523
Reviewed-on: https://go-review.googlesource.com/c/go/+/520395
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Currently, we rewrite:
go f(new(T))
into:
tmp := new(T)
go func() { f(tmp) }()
However, we can both shrink the closure and improve escape analysis by
instead rewriting it into:
go func() { f(new(T)) }()
This CL does that.
Change-Id: Iae16a476368da35123052ca9ff41c49159980458
Reviewed-on: https://go-review.googlesource.com/c/go/+/520340
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Normalizing go/defer statements to always use functions with zero
parameters and zero results was added to escape analysis, because that
was the earliest point at which all three frontends converged. Now
that we only have the unified frontend, we can do it during typecheck,
which is where we perform all other desugaring and normalization
rewrites.
Change-Id: Iebf7679b117fd78b1dffee2974bbf85ebc923b23
Reviewed-on: https://go-review.googlesource.com/c/go/+/520260
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
I previously used a clumsy hack to copy Closgen back and forth while
inlining, to handle when an inlined function contains closures, which
need to each be uniquely numbered.
The real solution was to name the closures using r.inlCaller, rather
than r.curfn. This CL adds a helper method to do exactly this.
Change-Id: I510553b5d7a8f6581ea1d21604e834fd6338cb06
Reviewed-on: https://go-review.googlesource.com/c/go/+/520339
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL moves more common Func-setup logic into ir.NewFunc. In
particular, it now handles constructing the Name and wiring them
together, setting the Typecheck bit, and setting Sym.Func.
Relatedly, this CL also extends typecheck.DeclFunc to append the
function to typecheck.Target.Funcs, so that callers no longer need to
do this.
Change-Id: Ifa0aded8df0517188eb295d0dccc107af85f1e8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/520338
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
This CL extends ir.NewClosureFunc to take the signature type argument,
and to handle naming the closure and adding it to typecheck.Target.
It also removes the code for typechecking OCLOSURE and ODCLFUNC nodes,
by having them always constructed as typechecked. ODCLFUNC node
construction will be further simplified in the followup CL.
Change-Id: Iabde4557d33051ee470a3bc4fd49599490024cba
Reviewed-on: https://go-review.googlesource.com/c/go/+/520337
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
In CL 421877 and CL 444278, time.Time.AppendFormat has been
specially optimized for the time.RFC3339Nano representation.
Relying on that optimization and modify the output to obtain the
fixed-width millisecond resolution that slog uses.
This both removes a lot of code and also improves performance:
name old time/op new time/op delta
WriteTime 93.0ns ± 1% 80.8ns ± 0% -13.17% (p=0.000 n=8+9)
Change-Id: I61e8f4476c111443e3e2098a45b2c21a76137345
Reviewed-on: https://go-review.googlesource.com/c/go/+/478757
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
This CL extends escape analysis in two ways.
First, we already optimize directly called closures. For example,
given:
var x int // already stack allocated today
p := func() *int { return &x }()
we don't need to move x to the heap, because we can statically track
where &x flows. This CL extends the same idea to work for indirectly
called closures too, as long as we know everywhere that they're
called. For example:
var x int // stack allocated after this CL
f := func() *int { return &x }
p := f()
This will allow a subsequent CL to move the generation of go/defer
wrappers earlier.
Second, this CL adds tracking to detect when pointer values flow to
the pointee operand of an indirect assignment statement (i.e., flows
to p in "*p = x") or to builtins that modify memory (append, copy,
clear). This isn't utilized in the current CL, but a subsequent CL
will make use of it to better optimize string->[]byte conversions.
Updates #2205.
Change-Id: I610f9c531e135129c947684833e288ce64406f35
Reviewed-on: https://go-review.googlesource.com/c/go/+/520259
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
A negative rune (other than NoPadding) makes no semantic sense.
Doing so relies on integer overflow of converting a rune to a byte
and would thus be equivalent to passing the positive byte value
of byte(padding).
This may cause existing code to panic.
An alternative is treat negative runes as equivalent to NoPadding.
However, the code already panics to report erroneous padding values,
so this is in line with the existing API.
Change-Id: I02499705519581598adc0c8525d90e25278dc056
Reviewed-on: https://go-review.googlesource.com/c/go/+/505236
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Rather than having PipeWriter and PipeReader a wrapper type on pipe,
make them have the same underlying memory representation and
rely instead of simply casting the same *pipe pointer
as either a *PipeReader or *PipeWriter to control the set of methods.
This reduces the number of allocations by 2,
going from a total of 6 down to 4 allocations.
Change-Id: I09207a00c4b7afb44c7773d752c5628a07e24fda
Reviewed-on: https://go-review.googlesource.com/c/go/+/473535
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The pprof mutex profile was meant to match the Google C++ (now Abseil)
mutex profiler, originally designed and implemented by Mike Burrows.
When we worked on the Go version, pjw and I missed that C++ counts the
time each thread is blocked, even if multiple threads are blocked on a
mutex. That is, if 100 threads are blocked on the same mutex for the
same 10ms, that still counts as 1000ms of contention in C++. In Go, to
date, /debug/pprof/mutex has counted that as only 10ms of contention.
If 100 goroutines are blocked on one mutex and only 1 goroutine is
blocked on another mutex, we probably do want to see the first mutex
as being more contended, so the Abseil approach is the more useful one.
This CL adopts "contention scales with number of goroutines blocked",
to better match Abseil [1]. However, it still makes sure to attribute the
time to the unlock that caused the backup, not subsequent innocent
unlocks that were affected by the congestion. In this way it still gives
more accurate profiles than Abseil does.
[1] https://github.com/abseil/abseil-cpp/blob/lts_2023_01_25/absl/synchronization/mutex.cc#L2390Fixes#61015.
Change-Id: I7eb9e706867ffa8c0abb5b26a1b448f6eba49331
Reviewed-on: https://go-review.googlesource.com/c/go/+/506415
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
ld-prime emits a deprecation warning for -bind_at_load. The flag
is needed for plugins to not deadlock (#38824) when linking with
older darwin linker. It is supposedly not needed with newer linker
when chained fixups are used. For now, we always pass it, and
suppress the warning.
For #61229.
Change-Id: I4b8a6f864a460c40dc38adbb533f664f7fd5343c
Reviewed-on: https://go-review.googlesource.com/c/go/+/508696
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
These operations misbehave and cause hangs and flakes.
Fail hard if they are attempted.
Tested by backing out the Darwin-profiling-hang fix
CL 518836 and running run.bash, the guard panicked in
runtime/pprof tests, as expected/hoped.
Updates #61768
Change-Id: I89b6f85745fbaa2245141ea98f584afc5d6b133e
Reviewed-on: https://go-review.googlesource.com/c/go/+/519275
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add runtime support for range over functions, specifically
for defer in the loop body. The defer is running in one
function but needs to append to the deferred function list
for a parent function. This CL implements the runtime
support for that, in the form of two new functions:
deferrangefunc, which obtains a token representing the
current frame, and deferprocat, which is like deferproc
but adds to the list for frame denoted by the token.
Preparation for proposal #61405. The actual logic in the
compiler will be guarded by a GOEXPERIMENT; this code
will only run if the compiler emits calls to deferprocat.
Change-Id: I08adf359100856d21d7ff4b493afa229c9471e70
Reviewed-on: https://go-review.googlesource.com/c/go/+/510540
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
syscall.Unshare is the sort of system call that may be blocked in a
container environment, and experience has shown that different
container implementations choose from a variety of different error
codes for blocked syscalls.
In particular, the patch in
https://git.alpinelinux.org/aports/tree/community/go/tests-unshare-enosys.patch
seems to suggest that the container environment used to test the Go
distribution on Alpine Linux returns ENOSYS instead of EPERM.
The existing testenv.SyscallIsNotSupported helper checks for
the kinds of error codes we have seen from containers in practice, so
let's use that here.
For #62053.
Updates #29366.
Change-Id: Ic6755f7224fcdc0cb8b25dde2d6047ceb5c3ffdf
Reviewed-on: https://go-review.googlesource.com/c/go/+/520057
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
This is subtle and the compiler and runtime be in sync.
It is easier to develop the rest of the changes (especially when using
toolstash save/restore) if this change is separated out and done first.
Preparation for proposal #61405. The actual logic in the
compiler will be guarded by a GOEXPERIMENT, but it is
easier not to have GOEXPERIMENT-specific data structures
in the runtime, so just make the field always.
Change-Id: I7ec7049b99ae98bf0db365d42966baeec56e3774
Reviewed-on: https://go-review.googlesource.com/c/go/+/510539
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Most of the code is not necessary anymore.
Before we start changing how range works,
delete this code so it won't need updating.
Preparation for proposal #61405.
Change-Id: Ia6c6cc62b156e38a871279350a2e60c189967cac
Reviewed-on: https://go-review.googlesource.com/c/go/+/510536
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Compact the Regexp.String output. It was only ever intended for debugging,
but there are at least some uses in the wild where regexps are built up
using regexp/syntax and then formatted using the String method.
Compact the output to help that use case. Specifically:
- Compact 2-element character class ranges: [a-b] -> [ab].
- Aggregate flags: (?i:A)(?i:B)*(?i:C)|(?i:D)?(?i:E) -> (?i:AB*C|D?E).
Fixes#57950.
Change-Id: I1161d0e3aa6c3ae5a302677032bb7cd55caae5fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/507015
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
This makes cmd/api no longer an importable package.
In CL 453258 I forgot that there was no direct prohibition
on importing packages from cmd - we just rely on the
fact that cmd/* is all package main and everything else
is cmd/internal.
Fixes#62069.
Change-Id: Ifed738d333b40663f85eca8f83025fcea5df89a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/520038
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
For aggregate-typed arguments passed to a call, expandCalls
decomposed them into parts in the same block where the value
was created. This is not necessarily the call block, and in
the case where stores are involved, can change the memory
leaving that block, and getting that right is problematic.
Instead, do all the expanding in the same block as the call,
which avoids the problems of (1) not being able to reorder
loads/stores across a block boundary to conform to memory
order and (2) (incorrectly, not) exposing the new memory to
consumers in other blocks. Putting it all in the same block
as the call allows reordering, and the call creates its own
new memory (which is already dealt with correctly).
Fixes#61992.
Change-Id: Icc7918f0d2dd3c480cc7f496cdcd78edeca7f297
Reviewed-on: https://go-review.googlesource.com/c/go/+/519276
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Some file systems do not support file IDs. We should not use
FILE_ID_BOTH_DIR_INFO when reading directories on these file systems,
as it will fail. Instead, we should use FILE_ID_FULL_DIR_INFO,
which doesn't require file ID support.
Fixes#61907Fixes#61918
Change-Id: I83d0a898f8eb254dffe5b8fc68a4ca4ef21c0d85
Reviewed-on: https://go-review.googlesource.com/c/go/+/518195
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This kind of worked, kind of didn't, but by now no one is running into
those configs anymore during "go mod init", the code is complex,
and the tests are slow. Not worth the trouble of maintaining anymore.
Change-Id: I02d4188d531c68334d17b2462bafec4c5dd49777
Reviewed-on: https://go-review.googlesource.com/c/go/+/518776
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
We've decided to keep basic GOPATH mode running
for trees that already exist, but GOPATH-mode get is
being removed. It is old and not useful and probably
full of security holes. See #60915 for more details.
Fixes#60915.
Change-Id: I9db4c445579bf0b79f6543624602652555b66c1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/518775
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
With no error handler installed, an error leads to an (internal panic
and) immediate abort of type checking. Not all invariants hold up in
this case, but it also doesn't matter.
In Checker.infer, verify result conditions always if an error handler
is installed, but only then.
Fixes#61938.
Change-Id: I4d3d61bbccc696a75639fee5010f5d3cef17e855
Reviewed-on: https://go-review.googlesource.com/c/go/+/519775
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
The existing code was simply wrong: we cannot ever use the result
signature parameter list (rsig.params) if sigParams was adjusted
for variadic functions. If it was adjusted, we always must either
use sigParams or its separately instantiated version.
In the condition "n > 0 && adjusted", the "n > 0" should have
been in either of the respective "if statement" branches.
Simplified the code by merging with the result signature parameter
update.
Fixes#61931.
Change-Id: I5d39bc8bbc4dd85c7c985055d29532b4b176955e
Reviewed-on: https://go-review.googlesource.com/c/go/+/519456
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL extends ir.StaticValue to also work on closure variables.
Also, it extracts the code from escape analysis that's responsible for
determining the static callee of a function. This will be useful when
go/defer statement normalization is moved to typecheck.
Change-Id: I69e1f7fb185658dc9fbfdc69d0f511c84df1d3ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/518959
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Irrespective of whether unification is exact or inexact, method
signatures of interfaces must always match exactly: a type never
satisfies/implements an interface if relevant method signatures
are different (i.e., not identical, possibly after substitution).
Fixes#61879.
Change-Id: I20c0aa28ac86e2edec615b40f2269938e4a96938
Reviewed-on: https://go-review.googlesource.com/c/go/+/519435
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
When reading an archive, check for the presence of sentinel entries
created by the Go command. These zero-sized marker entries don't contain
any useful symbols, but rather are there to communicate info to the
linker; ignore them during symbol dumping.
Fixes#62036.
Change-Id: Ied017b0c5b92a3cf6fd13bb9c9f3a9664e4f20f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/519635
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When recovering from a panic, restore the caller's frame pointer before
returning control to the caller. Otherwise, if the function proceeds to
run more deferred calls before returning, the deferred functions will
get invalid frame pointers pointing to an address lower in the stack.
This can cause frame pointer unwinding to crash, such as if an execution
trace event is recorded during the deferred call on architectures which
support frame pointer unwinding.
Fixes#61766
Change-Id: I45f41aedcc397133560164ab520ca638bbd93c4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/516157
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
When a goroutine stack is reused on arm64, the spot on the stack where
the "caller's" frame pointer goes for the topmost frame should be
explicitly zeroed. Otherwise, the frame pointer check in adjustframe
with debugCheckBP enabled will fail on the topmost frame of a call stack
the first time a reused stack is grown.
Updates #39524, #58432
Change-Id: Ic1210dc005e3ecdbf9cd5d7b98846566e56df8f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/481636
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Much of the gcc_linux_*.c code is identical and duplicated across
architectures. Consolidate code for 386, arm, loong64, mips* and
riscv64, where the only difference is the build tags (386 also
has some non-functional ordering differences).
Change-Id: I14ee9a4cc6b72e165239d196b68b6343efaddf0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/518620
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Most freebsd architectures now use the same code, deduplicate accordingly.
The arm code differs slightly in that it has a compile time check for
ARM_TP_ADDRESS, however this is written in a way that it can be included
for all architectures.
Change-Id: I7f6032b63521d24d0c3b5e0e08d57e32b4f9ddc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/518619
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
For 32 bit equality (Eq32), rather than always zero extending to 64 bits,
sign extend for signed types and zero extend for unsigned types. This makes
no difference to the equality test (via SUB), however it increases the
likelihood of avoiding unnecessary sign or zero extension simply for the
purpose of equality testing.
While here, replace the Neq* rules with (Not (Eq*)) - this makes no
difference to the generated code (as the intermediates get expanded and
eliminated), however it means that changes to the equality rules also
reflect in the inequality rules.
As an example, the following:
lw t0,956(t0)
slli t0,t0,0x20
srli t0,t0,0x20
li t1,1
bne t1,t0,278fc
Becomes:
lw t0,1024(t0)
li t1,1
bne t1,t0,278b0
Removes almost 1000 instructions from the Go binary on riscv64.
Change-Id: Iac60635f494f6db87faa47752bd1cc16e6b5967f
Reviewed-on: https://go-review.googlesource.com/c/go/+/516595
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: M Zhuo <mzh@golangcn.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This is encoded similarly to RLDICL, but can clear the least
significant bits.
Likewise, update the auxint encoding of RLDICL to match those
used by the rotate and mask word ssa opcodes for easier usage
within lowering rules. The RLDICL ssa opcode is not used yet.
Change-Id: I42486dd95714a3e8e2f19ab237a6cf3af520c905
Reviewed-on: https://go-review.googlesource.com/c/go/+/515575
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The documentation of io.EOF: Read must return EOF itself, not an error
wrapping EOF, because callers will test for EOF using ==.
encoding/json package provides an example "ExampleDecoder" which uses
"err == io.EOF" as well, so I think it's more idiomatic to use == to test for io.EOF.
Change-Id: I8a9f06d655ca63b3ec3e7dbbdfc519a2686980e1
GitHub-Last-Rev: 665929e2a2
GitHub-Pull-Request: golang/go#62012
Reviewed-on: https://go-review.googlesource.com/c/go/+/519156
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Instead of having the inliner specially recognize that eq/hash
functions can't be inlined, change the geneq and genhash to mark them
as //go:noinline.
This is a prereq for a subsequent CL that will move more logic for
handling rtypes from package types to package reflectdata.
Change-Id: I091a9ededcc083fe8305cf5443a9af7d3a9053b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/518955
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
On Darwin (and assume also on iOS but not sure), notetsleepg
cannot be called in a signal-handling context. Avoid this
by disabling block reads on Darwin.
An alternate approach was to add "sigNote" with a pipe-based
implementation on Darwin, but that ultimately would have required
at least one more linkname between runtime and syscall to avoid
racing with fork and opening the pipe, so, not.
Fixes#61768.
Change-Id: I0e8dd4abf9a606a3ff73fc37c3bd75f55924e07e
Reviewed-on: https://go-review.googlesource.com/c/go/+/518836
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Relocate the definitions in cmddefs.go (used by the compiler and
the cover tool) to a separate package "covcmd". No change
in functionality, this is a pure refactoring, in preparation
for a subsequent change that will require updating the
imports for the package.
Change-Id: Ic1d277c94d9a574de0a11ec5ed77e892302b9a47
Reviewed-on: https://go-review.googlesource.com/c/go/+/517696
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Most architectures have a crosscall1 function that takes a function
pointer, a setg_gcc function pointer and a g pointer. However,
crosscall_386 only takes a function pointer and the call to setg_gcc
is performed in the thread entry function.
Rename crosscall_386 to crosscall1 for consistency with other
architectures, as well as standardising the API - while not strictly
necessary, it will allow for further deduplication as the calling
code becomes more consistent.
Change-Id: I77cf42e1e15e0a4c5802359849a849c32cebd92f
Reviewed-on: https://go-review.googlesource.com/c/go/+/518618
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This CL removes a bunch of obsolete code, which made the overall
possible data flow of the compiler much harder to understand. In
particular, it:
1. Removes typecheck.Declare by inlining its only two remaining uses,
and simplifying them down to just the couple of relevant assignments
for each remaining caller.
2. Renames ir.Package.{Asms,Exports} to {AsmHdrDecls,PluginExports},
respectively, to better describe what they're used for. In particular,
PluginExports now actually holds only the subset of Exports that used
to be confusingly called "ptabs" in package reflectdata.
3. Renames reflectdata.WriteTabs to reflectdata.WritePluginTable, to
make it clearer what it does.
4. Removes the consistency checks on len(Exports) and len(ptabs),
since now it's plainly obvious that only the unified importer ever
appends to PluginExports.
Change-Id: Iedc9d0a4e7648de4e734f7e3e7df302580fed542
Reviewed-on: https://go-review.googlesource.com/c/go/+/518757
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Even if a block is empty, we need to keep track of whether the
end-of-block instructions are preemptible.
This CL allows us to not mark the load+compare in instruction
sequences like
CMPL $0, runtime·writeBarrier(SB)
JEQ ...
Before, we had to mark the CMPL as uninterruptible because there
was no way to mark just the JEQ. Now there is, so there is no need
to mark the CMPL itself.
Change-Id: I4c27c0dc211c03b14637d420899cd2c2cccf3493
Reviewed-on: https://go-review.googlesource.com/c/go/+/518539
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Decls used to contain initializer statement for package-level
variables, but now it only contains ir.Funcs. So we might as well
rename it to Funcs and tighten its type to []*ir.Func.
Similarly, Externs always contains *ir.Names, so its type can be
constrained too.
Change-Id: I85b833e2f83d9d3559ab0ef8ab5d8324f4bc37b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/517855
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL moves the early deadcode elimination pass into the unified
writer. This allows shrinking the export data, by simplifying
expressions and removing unreachable statements. It also means we
don't need to repeatedly apply deadcode elimination on inlined calls
or instantiated generics.
Change-Id: I19bdb04861e50815fccdab39790f4aaa076121fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/517775
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Various tools expect tar files to contain entries for directories.
I dropped them when writing cmd/distpack because they're not
strictly necessary and omitting them saves space, but it also
turns out to break some things, so add them back.
We will backport this to release-branch.go1.21 so that Go 1.21.1
will include the directory entries. We can't do anything about
Go 1.21.0 retroactively.
% tar tzvf go1.22rsc1.src.tar.gz | sed 10q
drwxr-xr-x 0 0 0 0 Aug 10 10:07 go/
-rw-r--r-- 0 0 0 1337 Aug 10 10:07 go/CONTRIBUTING.md
-rw-r--r-- 0 0 0 1479 Aug 10 10:07 go/LICENSE
-rw-r--r-- 0 0 0 1303 Aug 10 10:07 go/PATENTS
-rw-r--r-- 0 0 0 1455 Aug 10 10:07 go/README.md
-rw-r--r-- 0 0 0 419 Aug 10 10:07 go/SECURITY.md
-rw-r--r-- 0 0 0 42 Aug 10 10:07 go/VERSION
drwxr-xr-x 0 0 0 0 Aug 10 10:07 go/api/
-rw-r--r-- 0 0 0 1142 Aug 10 10:07 go/api/README
-rw-r--r-- 0 0 0 35424 Aug 10 10:07 go/api/except.txt
% tar tzvf go1.22rsc1.darwin-amd64.tar.gz | sed 10q
drwxr-xr-x 0 0 0 0 Aug 10 10:07 go/
-rw-r--r-- 0 0 0 1337 Aug 10 10:07 go/CONTRIBUTING.md
-rw-r--r-- 0 0 0 1479 Aug 10 10:07 go/LICENSE
-rw-r--r-- 0 0 0 1303 Aug 10 10:07 go/PATENTS
-rw-r--r-- 0 0 0 1455 Aug 10 10:07 go/README.md
-rw-r--r-- 0 0 0 419 Aug 10 10:07 go/SECURITY.md
-rw-r--r-- 0 0 0 42 Aug 10 10:07 go/VERSION
drwxr-xr-x 0 0 0 0 Aug 10 10:07 go/api/
-rw-r--r-- 0 0 0 1142 Aug 10 10:07 go/api/README
-rw-r--r-- 0 0 0 35424 Aug 10 10:07 go/api/except.txt
%
Fixes#61862.
Change-Id: Iecd9ba893015295e88715b031b79a104236b9ced
Reviewed-on: https://go-review.googlesource.com/c/go/+/518335
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
time.Since(base) is an idiom that can be used to read the system
monotonic time as efficiently as possible, when that matters.
The current code structure adds a few nanoseconds on top of
the 15-20ns the time read already takes. Remove those few.
After this CL, there is no reason at all for anyone to
//go:linkname runtime.nanotime1 instead.
Came up while investigating #61765.
Change-Id: Ic9e688af039babfc2a5a8e67dcbb02847a5eb686
Reviewed-on: https://go-review.googlesource.com/c/go/+/518336
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
modules.txt gets a new ## workspace line at the start of the file if
it's generated in workspace mode. Then, when deciding whether the go
command runs in mod=vendor, we only do so if we're in the same mode
(workspace or not) as the modules.txt specifies.
For #60056
Change-Id: If478a9891a7135614326fcb80c4c33a431e4e531
Reviewed-on: https://go-review.googlesource.com/c/go/+/513756
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
The branch itself can't be marked, so we ensure we mark the last
ssa.Value in the block as uninterruptible, because that's where the
branch ends up getting its uninterruptibility from.
This is somewhat conservative, as we're marking an instruction as
uninterruptible that doesn't need to be. But it is an easy fix.
TODO: figure out a test
Change-Id: Icd314f0bbdce8f80019bafb9e861baca4e7ecbb1
Reviewed-on: https://go-review.googlesource.com/c/go/+/518055
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Split out the code that computes the initial inline "hairyness" budget
for a function so that it can be reused (in a later patch). This is a
pure refactoring; no change in compiler functionality.
Change-Id: I9b1b7b10a7c480559b837492b10eb08771b7a145
Reviewed-on: https://go-review.googlesource.com/c/go/+/514795
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Rename the ir-local function "reassigned" to "Reassigned" so that it
can be used as part of inline heuristic analysis. Fix up the header
comment along that way, which had some stale material. Add support for
detecting reassignments via OASOP (as opposed to just simple
assignments).
Updates #61502.
Change-Id: I50f40f81263c0d7f61f30fcf0258f0b0f93acdca
Reviewed-on: https://go-review.googlesource.com/c/go/+/511560
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Add some machinery to support computing function "properties" for use
in driving inlining heuristics, and a unit testing framework to check
to see if the property computations are correct for a given set of
canned Go source files. This CL is mainly the analysis skeleton and a
testing framework; the code to compute the actual props will arrive in
a later patch.
Updates #61502.
Change-Id: I7970b64f713d17d7fdd7e8e9ccc7d9b0490571bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/511557
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add definitions for a set of Go function "properties" intended to be
useful for driving inlining decisions. This CL just defines a set of
flags and a container to hold them; a subsequent CL will add code to
compute the properties for a function given its IR/AST representation.
Updates #61502.
Change-Id: Ifa26c1ad055c02ca0ce9cf37078cee7b3385e18a
Reviewed-on: https://go-review.googlesource.com/c/go/+/511556
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This flag is not terribly useful with the go command, which will pass
all environment variables through to subprocesses it invokes,
but it can be useful in other build systems, notably blaze and bazel,
to pass compiler-debugging variables like GOSSAFUNC through to
the compiler.
We have been maintaining this as a patch against Google's internal
toolchain for many years, and it has proven useful in those non-go-command
contexts.
Change-Id: Ic123193319f3c838a694eda2575347c516b85ac7
Reviewed-on: https://go-review.googlesource.com/c/go/+/507977
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
In CL 517755 the test was added in the unconstrained os_test.go
because it appeared to be portable, but it turned out not to be
valid on plan9.
(The build error was masked on the misc-compile TryBots by #61923.)
Although the test can also compile and run on Windows, the bug it
checks for is specific to Linux and only really needs to run there, so
I am moving it to os_unix_test.go instead of adding yet another test
file for “Unix and Windows but not Plan 9”.
Updates #60181.
Change-Id: I41fd11b288217e95652b5daa72460c0d26bde606
Reviewed-on: https://go-review.googlesource.com/c/go/+/518255
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
When we were comparing the first element of import stacks when sorting
depserrors we checked if the first stack was non empty, but not the
second one. Do the check for both stacks.
Fixes#61816
For #59905
Change-Id: Id5c11c2b1104eec93196a08c53372ee2ba97c701
Reviewed-on: https://go-review.googlesource.com/c/go/+/516739
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Open-coded defer slots are assigned indices upfront, so they're
logically like elements in an array. Without reassigning the indices,
we need to keep all of the elements alive so their relative offsets
are correct.
Fixes#61895.
Change-Id: Ie0191fdb33276f4e8ed0becb69086524fff022b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/517856
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
MkdirAll fails to create directories under root paths using volume
names (e.g. //?/Volume{GUID}/foo). This is because fixRootDirectory
only handle extended length paths using drive letters (e.g. //?/C:/foo).
This CL fixes that issue by also detecting volume names without path
separator.
Updates #22230Fixes#39785
Change-Id: I813fdc0b968ce71a4297f69245b935558e6cd789
Reviewed-on: https://go-review.googlesource.com/c/go/+/517015
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
PrintMarker was printing 50 NUL bytes before the marker.
Also, the examples for writing your own ShouldEnable helper suggest
"if m == nil { return false }", but this is inconsistent with how
Matcher.ShouldEnable handles nil pointers.
Change-Id: Ie45075ba7fb8fcc63eadce9d793a06ef0c8aa9f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/517615
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
This extends CL 419434 to all Unix targets. Rather than repeating
the code, pull all the similar code into a single function.
CL 419434 description:
For a cgo binary, at startup we set g0's stack bounds using the
address of a local variable (&size) in a C function x_cgo_init and
the stack size from pthread_attr_getstacksize. Normally, &size is
an address within the current stack frame. However, when it is
compiled with ASAN, it may be instrumented to __asan_stack_malloc_0
and the address may not live in the current stack frame, causing
the stack bound to be set incorrectly, e.g. lo > hi.
Using __builtin_frame_address(0) to get the stack address instead.
Change-Id: I914a09d32c66a79515b6f700be18c690f3c0c77b
Reviewed-on: https://go-review.googlesource.com/c/go/+/517335
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Apply the same transformations to the User-Agent header value that we
do to other headers.
Avoids header and request smuggling in Request.Write and
Request.WriteProxy. RoundTrip already validates values in
Request.Header, and didn't allow bad User-Agent values to
make it as far as the request writer.
Fixes#61824
Change-Id: I360a915c7e08d014e0532bd5af196a5b59c89395
Reviewed-on: https://go-review.googlesource.com/c/go/+/516836
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fix a bug where Clean could improperly drop .. elements from a
path on Windows, when the path contains elements containing a ':'.
For example, Clean("a/../b:/../../c") now correctly returns "..\c"
rather than "c".
Fixes#61866
Change-Id: I97b0238953c183b2ce19ca89c14f26700008ea72
Reviewed-on: https://go-review.googlesource.com/c/go/+/517216
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
This includes version-dependent support for GOEXPERIMENT and
-d=loopvar, -d=loopvarhash, to allow testing/porting of old code.
Includes tests of downgrade (1.22 -> 1.21) and upgrade (1.21 -> 1.22)
based on //go:build lines (while running a 1.22 build/compiler).
Change-Id: Idd3be61a2b46acec33c7e7edac0924158cc726b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/508819
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test used to run with a separate goroutine for timeout behavior,
presumably because it was difficult to set an appropriate timeout.
Now that the test is in cmd instead of misc, we can use
internal/testenv.Command, which makes adding the test timeout much
simpler and eliminates the need for the explicit goroutine.
For #61846.
Change-Id: I68ea09fcf2aa394bed1e900cf30ef7d143fa249f
Reviewed-on: https://go-review.googlesource.com/c/go/+/517095
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Previously, os.Stat only followed IO_REPARSE_TAG_SYMLINK
and IO_REPARSE_TAG_MOUNT_POINT reparse points.
This CL generalize the logic to detect which reparse points to follow
by using the reparse tag value to determine whether the reparse point
refers to another named entity, as documented in
https://learn.microsoft.com/en-us/windows/win32/fileio/reparse-point-tags.
The new behavior adds implicit support for correctly stat-ing reparse
points other than mount points and symlinks, e.g.,
IO_REPARSE_TAG_WCI_LINK and IO_REPARSE_TAG_IIS_CACHE.
Updates #42184
Change-Id: I51f56127d4dc6c0f43eb5dfa3bfa6d9e3922d000
Reviewed-on: https://go-review.googlesource.com/c/go/+/516555
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Historically, the Transport has silently truncated invalid
Host headers at the first '/' or ' ' character. CL 506996 changed
this behavior to reject invalid Host headers entirely.
Unfortunately, Docker appears to rely on the previous behavior.
When sending a HTTP/1 request with an invalid Host, send an empty
Host header. This is safer than truncation: If you care about the
Host, then you should get the one you set; if you don't care,
then an empty Host should be fine.
Continue to fully validate Host headers sent to a proxy,
since proxies generally can't productively forward requests
without a Host.
For #60374Fixes#61431
Change-Id: If170c7dd860aa20eb58fe32990fc93af832742b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/511155
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
CL 515656 updated go/types to use file base as key in the posVers map,
but introduced a panic when the corresponding *token.File is nil.
Check that pos is valid before performing the lookup.
Fixes#61822
Change-Id: I1ac9d48c831a470de8439a50022ba5f59b3e0bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/516738
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Now that pcvalue keeps its cache on the M, we can drop all of the
stack-allocated pcvalueCaches and stop carefully passing them around
between lots of operations. This significantly simplifies a fair
amount of code and makes several structures smaller.
This series of changes has no statistically significant effect on any
runtime Stack benchmarks.
I also experimented with making the cache larger, now that the impact
is limited to the M struct, but wasn't able to measure any
improvements.
Change-Id: I4719ebf347c7150a05e887e75a238e23647c20cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/515277
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Currently, the pcvalue cache is stack allocated for each operation
that needs to look up a lot of pcvalues. It's not always clear where
to put it, a lot of the time we just pass a nil cache, it doesn't get
reused across operations, and we put a surprising amount of effort
into threading these caches around.
This CL moves it to the M, where it can be long-lived and used by all
pcvalue lookups, and we don't have to carefully thread it across
operations.
Change-Id: I675e583e0daac887c8ef77a402ba792648d96027
Reviewed-on: https://go-review.googlesource.com/c/go/+/515276
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Currently, pcvalue only returns a valid start PC if cache is nil.
We're about to eliminate the cache argument and always use a pcvalue
cache, so make sure the cache stores the start PC and always return it
from pcvalue.
Change-Id: Ie8854af4b7e7ba1c2a17a495d9229320821daa23
Reviewed-on: https://go-review.googlesource.com/c/go/+/515275
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL changes deferreturn so that it never needs to invoke the
unwinder. Instead, in the unusual case that we recover into a frame
with pending open-coded defers, we now save the extra state needed to
find them in g.param.
Change-Id: Ied35f6c1063fee5b6044cc37b2bccd3f90682fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/515856
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
This CL optimizes open-coded defers in two ways:
1. It modifies local variable sorting to place all open-coded defer
closure slots in order, so that rather than requiring the metadata to
contain each offset individually, we just need a single offset to the
first slot.
2. Because the slots are in ascending order and can be directly
indexed, we can get rid of the count of how many defers are in the
frame. Instead, we just find the top set bit in the active defers
bitmask, and load the corresponding closure.
Change-Id: I6f912295a492211023a9efe12c94a14f449d86ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/516199
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
If the shared slice in a copied is modified, make a copy of it
and insert an attribute that warns of the bug.
Previously, we panicked, and panics in logging code should be avoided.
Change-Id: I24e9b0bf5c8cd09cf733e7dae8a82d025ef214e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/513760
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The following declarations related to syntactic object resolution
are now deprecated:
- Ident.Obj
- Object
- Scope
- File.{Scope,Unresolved}
- Importer
- Package, NewPackage
New programs should use the type checker instead.
Updates golang/go#52463
Updates golang/go#48141
Change-Id: I82b315f49b1341c11ae20dcbf81106084bd2ba86
Reviewed-on: https://go-review.googlesource.com/c/go/+/504915
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Alan Donovan <adonovan@google.com>
Over the past few months as I read the standard library's documentation
I kept finding spots where godoc links would have helped me.
I kept adding to a stash of changes to fix them up bit by bit.
The stash has grown big enough by now, and we're nearing a release,
so I think it's time to merge to avoid git conflicts or bit rot.
Note that a few sentences are slightly reworded,
since "implements the Fooer interface" can just be "implements [Fooer]"
now that the link provides all the context needed to the user.
Change-Id: I01c31d3d3ff066d06aeb44f545f8dd0fb9a8d998
Reviewed-on: https://go-review.googlesource.com/c/go/+/508395
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 497276 added optimization for len(string([]byte)) by avoiding call to
slicebytetostring. However, the bytes to string expression may contain
init nodes, which need to be preserved. Otherwise, it would make the
liveness analysis confusing about the lifetime of temporary variables
created by init nodes.
Fixes#61778
Change-Id: I6d1280a7d61bcc75f11132af41bda086f084ab54
Reviewed-on: https://go-review.googlesource.com/c/go/+/516375
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Sorting variables by size doesn't actually do anything, but sorting by
alignment makes sure we can optimally pack variables into the stack
frame.
While here, replace the monolithic description at the top of
cmpstackvarlt with line-by-line explanations of what each comparison
is doing.
Change-Id: I860677799618130ce4a55f084cec637cb9a2e295
Reviewed-on: https://go-review.googlesource.com/c/go/+/516197
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
sysctl kern.arandom has been supported since NetBSD 4.0, works inside a
chroot, has no confusing bells and whistles like Linux getrandom,
requires no complicated querying to avoid SIGSYS traps, and is what
NetBSD 10 will usee for the getentropy(3) library routine soon to
appear in POSIX.
Change-Id: I23bd84ecd5ff3e33e8958c60896db842c44667ba
GitHub-Last-Rev: 5db094c85a
GitHub-Pull-Request: golang/go#61441
Reviewed-on: https://go-review.googlesource.com/c/go/+/511036
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Converts the 5 x 8-bit source byte to two 32-bit integers.
This will reduce the number of shift operations.
benchmark old ns/op new ns/op delta
BenchmarkEncode-10 9005 4426 -50.85%
BenchmarkEncodeToString-10 10739 6155 -42.69%
benchmark old MB/s new MB/s speedup
BenchmarkEncode-10 909.69 1850.81 2.03x
BenchmarkEncodeToString-10 762.84 1331.02 1.74x
Change-Id: I9418d3436b73f94a4eb4b2b525e4f83612ff4d47
Reviewed-on: https://go-review.googlesource.com/c/go/+/514095
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
An optional interface FileInfoNames has been added.
If the parameter fi of FileInfoHeader implements the interface
the Gname and Uname of the return value Header are
provided by the method of the interface.
Also added testing.
Fixes#50102
Change-Id: I6fd06c7c9aaf29b22b7384542fe57affed33009a
Change-Id: I6fd06c7c9aaf29b22b7384542fe57affed33009a
GitHub-Last-Rev: 5e82257948
GitHub-Pull-Request: golang/go#61662
Reviewed-on: https://go-review.googlesource.com/c/go/+/514235
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Rather than testing for architectures that use libc-based system calls,
test that it is not the single architecture that Go is still using direct
system calls. This reduces the number of changes needed for new openbsd
ports.
Updates #36435
Updates #61546
Change-Id: I79c4597c629b8b372e9efcda79e8f6ff778b9e8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/516016
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
The type machVMRegionBasicInfoData is generated from C type
vm_region_basic_info_data_64_t, which is a packed struct with a
64-bit field at offset 20. We cannot use uint64 as the field type
in the Go struct, as that will be aligned at offset 24, which does
not match the C struct. Change back to [8]byte (which is what the
cgo command generates), but keep the name Offset.
Updates #61707.
Updates #50891.
Change-Id: I2932328d7f9dfe9d79cff89752666c794d4d3788
Reviewed-on: https://go-review.googlesource.com/c/go/+/516156
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Now that the development of the Go 1.21 release is almost done, its
release notes are moved to their eventual long-term home in x/website
in CL 516095. Delete the initial development copy here.
For golang/go#58645.
Change-Id: I5207d21289b2e7b9328c943a088f45bc81c710a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/516075
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Left out the following commits that felt more bug-fixy.
* f0de4b4f03 - crypto/x509: fix certificate validation with FQDN on Windows <Patryk Chelmecki>
* 20e08fe68c - crypto/tls: advertise correct ciphers in TLS 1.3 only mode <Monis Khan>
* 295c237b4d - crypto/tls: enforce 1.3 record version semantics <Roland Shoemaker>
Change-Id: Idd38b5c6897130424a0e8b857f371d7d384fc143
Reviewed-on: https://go-review.googlesource.com/c/go/+/515955
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Stop using BTSconst and friends when ORLconst can be used instead.
OR can be issued by more function units than BTS can, so it could
lead to better IPC. OR might take a few more bytes to encode, but
not a lot more.
Still use BTSconst for cases where the constant otherwise wouldn't
fit and would require a separate movabs instruction to materialize
the constant. This happens when setting bits 31-63 of 64-bit targets.
Add BTS-to-memory operations so we don't need to load/bts/store.
Fixes#61694
Change-Id: I00379608df8fb0167cb01466e97d11dec7c1596c
Reviewed-on: https://go-review.googlesource.com/c/go/+/515755
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
A consequence of go.dev/cl/513837 was that calling deferreturn would
now use the unwinder to find (just) the current frame, and it turns
out there are workloads where this has a significant performance
impact.
As a simple optimization, this CL adds a fast path for deferreturn to
detect when there are pending linked defers, which allows us to skip
invoking the unwinder entirely.
Notably, this still doesn't handle the corner case of calling
deferreturn in a function that uses linked defer when dynamically
there just aren't any defers pending. It also means that after
recovering from a panic and returning to a frame that used open-coded,
we still need to use the unwinder too.
I hope to further optimize defer handling to improve these cases too,
but this is an easy, short-term optimization that relieves the
performance impact to the affected workloads.
Change-Id: I11fa73649302199eadccc27b403b231db8f33db2
Reviewed-on: https://go-review.googlesource.com/c/go/+/515716
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The recent version of darwin linker ld64 emits an warning about
deprecation of the -no_pie flag. Further, the new darwin linker
ld-prime ignores -no_pie flag and generates a PIE binary anyway.
Switch to building PIE binaries by default.
Updates #54482.
Updates #61229.
Change-Id: I81294dcd07a368a20e1349d56556ee2fdcb8df44
Reviewed-on: https://go-review.googlesource.com/c/go/+/461697
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The encoding/gob.TestLargeSlice test needs too much virtual memory
to run reliably on machines with a small address space, for example
the plan9-arm builders where user processes only have 1 gigabyte.
Fixes#60284
Change-Id: Ied88630e5ec6685e14d2060ae316abca1619f9b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/496138
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
Rather than having register encoding knowledge in each caller of opxrrr,
pass the registers into opxrrr and let it handle the encoding. This reduces
duplication and improves readability.
Change-Id: I202c503465a0169277a0f64340598203c9dcf20c
Reviewed-on: https://go-review.googlesource.com/c/go/+/461140
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The existing Thread Local Storage (TLS) implementation for riscv64 uses
initial-exec (IE) mode, however a MOV of a TLS symbol currently loads the
thread pointer offset and not the actual address or memory location.
Rework TLS on riscv64 to generate the full instruction sequence needed to
load from or store to a TLS symbol. Additionally, provide support for both
initial-exec (IE) and local-exec (LE) TLS - in many cases we can use LE,
which is slightly more efficient and easier to support in the linker.
Change-Id: I1b43f8888b3b6b10354bbb79d604771e64d92645
Reviewed-on: https://go-review.googlesource.com/c/go/+/431103
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: M Zhuo <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Add "NewInliner" to the list of Go experiments, used for enabling an
updated/improved version of the function inlining phase within the Go
compiler.
Updates #61502.
Change-Id: I3218b3ae59a2d05156e8017cd9ee1d7b66cad031
Reviewed-on: https://go-review.googlesource.com/c/go/+/511555
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
posVers exists once for an entire package. Move it into the group
of fields related to the entire package (and out from the group
of fields that are specific to each batch of files).
Change-Id: I40ea722578408bdf2b85db91b65680e720c0c502
Reviewed-on: https://go-review.googlesource.com/c/go/+/514998
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
The CPU profiler skip samples if the sampling rate is too high
for the system timer resolution. This CL uses high resolution
timers on Windows when available, to avoid this problem.
Note that the default sampling rate (100Hz) is already too high
for the Windows timer resolution (15.6ms), so this CL also improves
the default Windows sampling coverage.
Not adding regression tests, as they would be too flaky.
Fixes#61665
Change-Id: Ifdadabc9ebaf56f397eac517bd0e5f1502b956b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/514375
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Extremely large RSA keys in certificate chains can cause a client/server
to expend significant CPU time verifying signatures. Limit this by
restricting the size of RSA keys transmitted during handshakes to <=
8192 bits.
Based on a survey of publicly trusted RSA keys, there are currently only
three certificates in circulation with keys larger than this, and all
three appear to be test certificates that are not actively deployed. It
is possible there are larger keys in use in private PKIs, but we target
the web PKI, so causing breakage here in the interests of increasing the
default safety of users of crypto/tls seems reasonable.
Thanks to Mateusz Poliwczak for reporting this issue.
Fixes#61460
Fixes CVE-2023-29409
Change-Id: Ie35038515a649199a36a12fc2c5df3af855dca6c
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1912161
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/515257
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
I was trying out gorebuild (a program that runs make.bash many times)
on a macOS system. Unfortunately there were a few failed invocations
on my first try, but not with a very good or interesting reason:
go tool dist: unexpected new file in $GOROOT/bin: .DS_Store
Tolerate it since it's not unexpected, and will not affect the build.
Change-Id: I656536b896098c2ba934667196d4ce82e706c8da
Reviewed-on: https://go-review.googlesource.com/c/go/+/513763
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Older s390x before z13 did not have support to carry out floating point operations i.e. they didn't have the support for vector instructions like VX/VL, etc.
Starting with Go1.19, z13 is the minimum hardware level for running Go on LoZ (s390x). The main cause of this issue was the refactoring of elliptic curve to internal/nistec. The new code structures made it difficult to dynamically switch implementations at runtime, so it became necessary (in order machines to continue to use the accelerated implementation) to require z13 as the minimum hardware.
Hence, Go programs, when run on unsupported hardware, should crash on startup instead of crashing out in crypto code.
Fixes: #58465
Change-Id: I7c1a816205d19b5ddd2f1464839d16fa96815384
Reviewed-on: https://go-review.googlesource.com/c/go/+/499495
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Cherry Mui <cherryyz@google.com>
It is the responsibility of go/types to complete any interface it
creates, except for those created by the user using NewInterface.
However, this was not being done for interfaces created during
instantiation.
Fix this by (rather carefully) ensuring that all newly created
interfaces are eventually completed.
Fixesgolang/go#61561
Change-Id: I3926e7c9cf80714838d2c1b5f36a2d3221c60c41
Reviewed-on: https://go-review.googlesource.com/c/go/+/513015
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Currently the only named capture supported by regexp is (?P<name>a).
The syntax (?<name>a) is also widely used and there is currently an effort from
the Rust regex and RE2 teams to also accept this syntax.
Fixes#58458
Change-Id: If22d44d3a5c4e8133ec68238ab130c151ca7c5c5
GitHub-Last-Rev: 31b50e6ab4
GitHub-Pull-Request: golang/go#61624
Reviewed-on: https://go-review.googlesource.com/c/go/+/513838
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Arrays, structs, and complex numbers are collections of values that
are handled separately by the memory model.
An earlier version may have said this, but the current version does not.
Say it.
Change-Id: If3928bed6659e58e688f88aa0dde05423cbb3820
Reviewed-on: https://go-review.googlesource.com/c/go/+/514476
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
benchmark old ns/op new ns/op delta
BenchmarkUnmarshalMap-10 218 172 -21.28%
benchmark old allocs new allocs delta
BenchmarkUnmarshalMap-10 15 12 -20.00%
benchmark old bytes new bytes delta
BenchmarkUnmarshalMap-10 328 256 -21.95%
Change-Id: Ie20ab62731c752eb0040c6d1591fedd7d12b1e0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/514100
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Fixes#61629
This reduce the pressure on regalloc because then the loop only keep alive
one value (the iterator) instead of the iterator and the upper bound since
the comparison now acts against an immediate, often zero which can be skipped.
This optimize things like:
for i := 0; i < n; i++ {
Or a range over a slice where the index is not used:
for _, v := range someSlice {
Or the new range over int from #61405:
for range n {
It is hit in 975 unique places while doing ./make.bash.
Change-Id: I5facff8b267a0b60ea3c1b9a58c4d74cdb38f03f
Reviewed-on: https://go-review.googlesource.com/c/go/+/512935
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Rather than passing registers as uint32, use int16 and cast to uint32 in
the OP_IRR implementation. This allows a large number of casts to be removed
and code simplified at call sites. Also be more consistent with op, register
and value ordering.
Change-Id: I510347d97787ce80a338037b25470addf3a2939d
Reviewed-on: https://go-review.googlesource.com/c/go/+/514098
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Rong Zhang <rongrong@oss.cipunited.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
This is a band-aid of a fix for Go 1.21, to create space to work on
a real fix for Go 1.22, if in fact the real fix is different. It simply
disables the go.sum update check during go list -m -u.
I don't have a self-contained test for the breakage. See #61605.
All existing tests continue to pass.
For #61605.
After merging into the Go 1.21 branch we can move #61605 to the Go 1.22 milestone.
Change-Id: Ib155710092003f08d2a6ce0aefa8e0270cad5a5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/513778
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When dynamic linking on darwin, the darwin linker doesn't link
relocations pointing to zero-sized local symbols, like our
start/end marker symbols, e.g. runtime.text and runtime.etext.
It will choose to resolve to another symbol on the same address
that may not be local, therefore that reference may point to a
different DSO, which is not what we want. We already fix up some
marker symbols, like text/etext, data/edata, bss/ebss. But we
currently don't fix up noptrdata and noptrbss. With the new
darwin linker ld-prime, this causes problems when building a
plugin. Fix up those symbols.
For #61229.
Change-Id: I2181bb9184b85af9a3c3f5dc6d78e4d5a1d56d53
Reviewed-on: https://go-review.googlesource.com/c/go/+/503538
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In Mach-O object files, there are two kinds of relocations:
"external" relocation, which targets a symbol, and "non-external"
relocation, which targets a section. For targeting symbols not in
the current object, we must use symbol-targeted relocations. For
targeting symbols defined in the current object, for some
relocation types, both kinds can be used. We currently use
section-targeted relocations for R_ADDR targeting locally defined
symbols.
Modern Apple toolchain seems to prefer symbol-targeted relocations.
Also, Apple's new linker, ld-prime, seems to not handle section-
targeted relocations well in some cases. So this CL switches to
always generate symbol-targeted relocations. This also simplifies
the code.
One exception is that DWARF tools seem to handle only section-
targeted relocations. So generate those in DWARF sections.
This CL supersedes CL 502616.
Fixes#60694.
For #61229.
Change-Id: I3b74df64f21114635061bcd89114392b3a2d588b
Reviewed-on: https://go-review.googlesource.com/c/go/+/503935
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Apple's new linker, ld-prime from Xcode 15 beta, when handling
initializers in __mod_init_func, drops the offset in the data,
resolving the relocation to the beginning of the section. The
latest version of ld-prime rejects non-zero addend. We need to use
symbol-targeted "external" relocations, so that it doesn't need
an addend and can be resolved correctly. This also works fine with
ld64.
Fixes#60694.
For #61229.
Change-Id: Ida2be6aa4c91bfcd142b755e2ec63aabfbbd77a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/502616
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL refactors gopanic, Goexit, and deferreturn to share a common
state machine for processing pending defers. The new state machine
removes a lot of redundant code and does overall less work.
It should also make it easier to implement further optimizations
(e.g., TODOs added in this CL).
Change-Id: I71d3cc8878a6f951d8633505424a191536c8e6b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/513837
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The previous implementation would limit itself to 0xfff000 | 0xfff << shift,
while the maximum possible value is 0xfff000 + 0xfff << shift. In practical
terms, this means that an additional ((1 << shift) - 1) * 0x1000 of offset
is reachable for operations that use this splitting format. In the case of
an 8 byte load/store, this is an additional 0x7000 that can be reached
without needing to use the literal pool.
Updates #59615
Change-Id: Ice7023104042d31c115eafb9398c2b999bdd6583
Reviewed-on: https://go-review.googlesource.com/c/go/+/512540
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
In a number of load and store cases, the use of the literal pool can be
entirely avoided by simply adding or subtracting the offset from the
register. This uses the same number of instructions, while avoiding a
load from memory, along with the need for the value to be in the literal
pool. Overall this reduces the size of binaries slightly and should have
lower overhead.
Updates #59615
Change-Id: I9cb6a403dc71e34a46af913f5db87dbf52f8688c
Reviewed-on: https://go-review.googlesource.com/c/go/+/512539
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Currently, pool literals are added when they are not needed, namely
in the case where the offset is a 24 bit unsigned scaled immediate.
By improving the classification of loads and stores, we can avoid
generating unused pool literals. However, more importantly this
provides a basis for further improvement of the load and store
code generation.
Updates #59615
Change-Id: Ia3bad1709314565a05894a76c434cca2fa4533c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/512538
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
benchmark old ns/op new ns/op delta
BenchmarkMapsDeepEqual-10 235 200 -15.05%
benchmark old allocs new allocs delta
BenchmarkMapsDeepEqual-10 7 6 -14.29%
benchmark old bytes new bytes delta
BenchmarkMapsDeepEqual-10 96 48 -50.00%
Change-Id: Ifa625ad25524cc9ee438711917606626b33a9597
Reviewed-on: https://go-review.googlesource.com/c/go/+/512576
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
The dist test name changed from "race" to "flag:race", "net:race",
"os:race" and so on in CL 496181, we missed that this skip was checking
the exact dist test name, and no builder reported a problem despite the
skip becoming inactive.
I considered deleting it as obsolete, but it may still be helpful
if someone runs race.bash on a linux/arm64 machine configured with
something other than the supported 48-bit VMA. So for now apply a
simple change to restore the existing skip.
Hopefully one day there will be a good way to check for unsupported VMA
size and disable the race detector conditionally instead of relying on
tests running, failing, and getting marked as skipped in cmd/dist.
For #29948.
For #37486.
Change-Id: I8af6862c92fb0ee538ab27327d43c50921bd1873
Reviewed-on: https://go-review.googlesource.com/c/go/+/512116
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
A small number of tests in the main tree are currently skipped in LUCI
because our builders there run tests without root. Unfortunately, these
tests begin to run when run under 'unshare -n -r' as implemented in
the current iteration of a no-network check. Add targeted builder-only
skips so that they don't begin to run and fail with a false positive.
Updates #10719.
For #30612.
Change-Id: I6dd320714a279c395882c1b2ebfbb2fce58f913b
Reviewed-on: https://go-review.googlesource.com/c/go/+/513779
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Tests that need to use the internet are expected not to run when -short
test flag is set, and the Go build system automatically catches when a
test forgets that. It does this by unsharing all real network interfaces
and leaving only a loopback interface in a new network namespace.
TestUnshare tests that a process started with CLONE_NEWNET unshare flag
has fewer network interfaces than before. Of course, if /proc/net/dev
starts out with a single loopback interface, the test would fail with
a false positive:
=== RUN TestUnshare
exec_linux_test.go:139: Got 3 lines of output, want <3
--- FAIL: TestUnshare (0.00s)
Give the test what it wants: a skip when the environment doesn't meet
the minimum requirements for the test, and more useful log output if
it fails.
Change-Id: I6b9c29d88ce725e640a7ee86c7e1be9761f21b02
Reviewed-on: https://go-review.googlesource.com/c/go/+/513762
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
As far a I can tell, there's currently no situation where this feature
detection will report a different result per request, so default to
doing once per process until there's evidence that doing it more often
is worthwhile.
Change-Id: I567d3dbd847af2f49f2e83cd9eb0ae61d82c1f83
Reviewed-on: https://go-review.googlesource.com/c/go/+/513459
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Currently on s390x, tan assembly implementation is not handling huge arguments at all. This change is to check for large arguments and revert back to native go implantation from assembly code in case of huge arguments.
The changes are implemented in assembly code to get better performance over native go implementation.
Benchmark details of tan function with table driven inputs are updated as part of the issue link.
Fixes#37854
Change-Id: I4e5321e65c27b7ce8c497fc9d3991ca8604753d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/470595
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
AIX and Solaris call into libc for syscalls, and expect M.mOS.perrno
to point to the thread-local errno value for the current M.
We initialize that field in miniterrno called from mstart.
However, this means that any libc calls before mstart will not
return the correct errno value.
This caused trouble in checkfds, which runs very early, before mstart.
We worked around that in 513215. This CL reverts 513215 in favor
of a better workaround: call miniterrno for m0 earlier (we will
still wind up calling miniterrno again from mstart, which does
no harm).
This is a better workaround because it means that if we add future
syscalls before mstart, they will behave as expected.
Fixes#61584
Change-Id: Ib6a0d3c53d2c8214cc339a5019f9d4f71a746f0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/513535
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
I considered deleting mustHaveExternalNetwork in favor of just using
the real testenv.MustHaveExternalNetwork. That certainly makes these
tests that call it easier to understand. But that negatively affects
some ports that don't have a longtest builder as it'd make the tests
not run automatically on any builder at all.
So, make a minimal change that applies only to GOOS=linux for now.
If we make more progress on establishing -longtest builders for all
ports, this intermediate layer helper will cease to have any benefit
and can be deleted in favor of the one in testenv package.
Change-Id: Iaea207d98e780db429ab49e6e227650a8b35b786
Reviewed-on: https://go-review.googlesource.com/c/go/+/513416
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
On darwin, -lm is not necessary as the math functions are included
in libSystem. Passing -lm multiple times results in linker
warnings. Don't pass it on darwin.
For #61229.
Change-Id: I72d8dab1f0eead68cbeb176ac97b8ed1a0cfddab
Reviewed-on: https://go-review.googlesource.com/c/go/+/508697
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The buildall.bash script was initially added in 2015 (in CL 9438),
documented as used in the implementation of the new compile-only
builders at the time.
That description was updated as the builder implementation changed
from "linux-amd64-compilesmoke" to "all-compile" and most recently
to "misc-compile", which it still mentions today.
The build system stopped using it in CL 464955 and there are no plans
to use it again in the future, so update the description so that it's
not misleading. Notably, adding additional checks to this script does
not mean they will be caught by builders.
Updates #31916.
Updates #58163.
Change-Id: I17558b1c150a3ad95105de14511c51791287991b
Reviewed-on: https://go-review.googlesource.com/c/go/+/513755
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For short all.bash, we can keep the small speedup of 2-10 seconds by
skipping 'go test' on packages without tests. This is viable without
coverage loss since the Go release process is guaranteed to run long
tests for all first class ports.
For golang/go#60463.
Change-Id: Ib5a6bd357d757141bc8f1c1dec148a6565726587
Reviewed-on: https://go-review.googlesource.com/c/go/+/503115
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Remove the optimization added in CL 10492 that skips running 'go test'
on Go packages without _test.go files. By now, 'go test' can find real
problems even in packages that don't have any custom tests.
On my fairly fast laptop, running go test -short on all 164 normal
and 96 vendored packages without tests took around 10 seconds on
the first run and 2.5 seconds on the second, a small fraction of
the total all.bash time. So prioritize gains in the test coverage
over those savings in all.bash time.
Fixesgolang/go#60463.
Change-Id: I3d2bec5c367de687e57131e7fd7e6b84fed30187
Reviewed-on: https://go-review.googlesource.com/c/go/+/503095
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Currently the Optab structure contains four arguments of an instruction,
excludes the fifth argument p.RegTo2. It does not participate in
instruction matching and is usually handled separately.
Instructions with five operands are common in the newer arm instruction
set, so this CL adds the fifth argument to Optab, so that instruction
matching is easier. This caused the oplook function also needs to be
updated synchronously, this CL also made some cleaning and modifications
to this function.
Change-Id: I1d95ad99e72a44dfad1e00db182cfc369a0e55c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/505975
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Preserve the names in case we want them to return an iterator.
Keep the efficient runtime implementations for now,
as we will probably want them under some name, perhaps KeysSlice
and ValuesSlice.
Fixes#61538
Change-Id: I6b03010bf071fb4531cb2f967dad46425962fcb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/513476
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The code was sorting files in the archives entirely by path string,
but that's not what fs.WalkDir would do. In a directory with
subdirectory foo/bar and file foo/bar.go, foo/bar gets visited
first, so foo/bar/baz appears before foo/bar.go, even though
"foo/bar/baz" > "foo/bar.go".
This CL replaces the string comparison with a path-aware
comparison that places foo/bar/baz before foo/bar.go,
so that if the tar file is extracted and then repacked using
fs.WalkDir, the files will remain in the same order.
This will make it easier to compare the pristine distpack-produced
tgz for darwin against the rebuilt tgz with signed binaries.
Before:
% tar tzvf /tmp/cmddist.tgz | grep -C1 runtime/cgo.go
-rw-r--r-- 0 0 0 11122 Jul 13 15:00 go/src/runtime/callers_test.go
-rw-r--r-- 0 0 0 2416 Jul 13 15:00 go/src/runtime/cgo.go
-rw-r--r-- 0 0 0 2795 Jul 13 15:00 go/src/runtime/cgo/abi_amd64.h
After:
% tar tzvf pkg/distpack/go1.21rsc.src.tar.gz | grep -C1 runtime/cgo.go
-rw-r--r-- 0 0 0 1848 Dec 31 1969 go/src/runtime/cgo/signal_ios_arm64.s
-rw-r--r-- 0 0 0 2416 Dec 31 1969 go/src/runtime/cgo.go
-rw-r--r-- 0 0 0 2479 Dec 31 1969 go/src/runtime/cgo_mmap.go
For #24904.
For #61513.
Change-Id: Ib7374bc0d6324377f81c561bef57fd87b2111b98
Reviewed-on: https://go-review.googlesource.com/c/go/+/511977
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Make the load detection a bit clearer and more precise. In particular,
for architectures which have to materialize the address using a
separate instruction, we were using the address materialization
instruction, not the load itself.
Also apply the marking a bit less. We don't need to mark the load itself,
only the instructions after the load. And we don't need to mark the WBend
itself, only the instructions before it.
Change-Id: Ie367a8023b003d5317b752d873bb385f931bb30e
Reviewed-on: https://go-review.googlesource.com/c/go/+/499395
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The 5ms sleep in (*Process).Wait was added to mitigate errors while
removing executable files using os.RemoveAll.
Windows 10 1903 implements POSIX semantics for DeleteFile, making the
implementation of os.RemoveAll on Windows much more robust. Older
Windows 10 versions also made internal improvements to avoid errors
when removing files, making it less likely that the 5ms sleep is
necessary.
Windows 10 is the oldest version that Go supports (see #57004), so it
makes sense to unconditionally remove the 5ms sleep now. We have all
the Go 1.22 development cycle to see if this causes any regression.
Fixes#25965
Change-Id: Ie0bbe6dc3e8389fd51a32484d5d20cf59b019451
Reviewed-on: https://go-review.googlesource.com/c/go/+/509335
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The default WASI runtime was originally set to Wazero, because it was
the first runtime used to test the Go implementation and because we
could easily find and fix issues in our implementation and theirs.
In CL 498675 we switched the default wasip1 runner to Wasmtime as it
runs faster and is a more established and mature runtime. We should
switch the default runtime to Wasmtime to consistently promote
Wasmtime as the primary tested and approved runtime.
Change-Id: Ic6c064142321af90f015e02b7fe0e71444d8842c
Reviewed-on: https://go-review.googlesource.com/c/go/+/513235
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This code stems from the original 7l C code, where one way to determine
the end of a table is to put a sentinel entry, then scan for it. This is
now Go code and the length of an array is readily available.
Remove the sentinel and sentinel scan, then adjust the remaining code to
work accordingly.
Change-Id: I8964c787f5149f3548fa78bf8923aa7a93f9482e
Reviewed-on: https://go-review.googlesource.com/c/go/+/512536
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
On AIX and Solaris the errno value is fetched using m.mOS.perrno.
When checkfds is called, that value has not yet been set up by minit.
Since the error value doesn't really matter in checkfds,
don't bother to check it on AIX and Solaris.
Fixes#61584
Change-Id: I4e679ee3fdad4f0b833ae102597b2d6b8cb46cb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/513215
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
On Unix-like platforms, enforce that the standard file descriptions (0,
1, 2) are always open during initialization. If any of the FDs are
closed, we open them pointing at /dev/null, or fail.
Fixes#60641
Change-Id: Iaab6b3f3e5ca44006ae3ba3544d47da9a613f58f
Reviewed-on: https://go-review.googlesource.com/c/go/+/509020
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In most cases this change removes assumptions that there is a single
main module in vendor mode and iterates over the workspace modules
when doing checks. The go mod vendor command will now, if in workspace
mode, create a vendor directory in the same directory as the go.work
file, containing the packages (and modules in modules.txt) loaded from
the workspace. When reassembling the module graph from the vendor
directory, an edges are added from each of the main modules to their
requirements, plus additionally to a fake 'vendor/modules.txt' module
with edges to all the modules listed in vendor/modules.txt.
For #60056
Change-Id: I4a485bb39836e7ab35cdc7726229191c6599903e
Reviewed-on: https://go-review.googlesource.com/c/go/+/495801
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
The Test{ARCH}Errors tests will call ctxt.Arch.Assemble, but this
function requires the assembler has been initialized. So this CL adds
a call to architecture.Init(ctxt) in testErrors, otherwise running
Test{ARCH}Errors alone would fail.
Change-Id: I4f3ba5a5fc1375d28779701989cf700cb4d1b635
Reviewed-on: https://go-review.googlesource.com/c/go/+/505976
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Eric Fang <eric.fang@arm.com>
The following instruction is wrongly encoded on arm64:
MOVD (R2)(R3<<0), R1
It's incorrectly encoded as
MOVD (R2)(R3<<3), R1
The reason for the error is that we hard-coded the shift encoding to 6,
which is correct for the MOVB and MOVBU instructions because it only
allows a shift amount of 0, but it is wrong for the MOVD instruction
because it also allows other shift values.
For instructions MOVB, MOVBU and FMOVB, the extension amount must be 0,
encoded in "S" as 0 if omitted, or as 1 if present. But in Go, we don't
distinguish between Rn.<EXT> and Rn.<EXT><<0, so we encode it as that
does not present. This makes no difference to the function of the
instruction.
Change-Id: I2afe3498392cc9b2ecd524c7744f28b9d6d107b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/510995
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The -s flag is to documented to disable symbol table, not DWARF
(which is the -w flag). However, due to a bug (#15166), -s was
made to also disable DWARF. That bug can be fixed without
disabling DWARF. So do that, and make it possible to enable DWARF
with -s.
Since -s has been disabling DWARF for quite some time, and users
who use -s may want to suppress all symbol information, as DWARF
also contains symbol information, we keep the current behavior,
having -s continue to disable DWARF by default. But we allow
enabling DWARF by specifying -w=0 (or false).
In summary, this is the behavior now:
-s no symbol table, no DWARF
-w has symbol table, no DWARF
-s -w no symbol table, no DWARF (same as -s)
-s -w=0 no symbol table, has DWARF
Change-Id: I1883f0aa3618abccfd735d104d983f7f531813d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/492984
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Currently, on Mach-O in external linking mode, the handling of -s
and -w flags are a bit mixed: neither flag disables the symbol
table, and both flags disable DWARF.
This CL makes it do what is documented: -s disables symbol table,
and -w disables DWARF. For the Darwin system linker, the -s flag
(strip symbol table) is obsolete. So we strip it afterwards. We
already use the strip command to strip the debug STAB symbols if
we need to combine DWARF. With this CL we'll use an additional
flag to strip more symbols. And we now also use strip if -s is
specified and we don't need to combine DWARF.
Change-Id: I9bed24fd388f2bd5b0ffa4ec2db46a4a2f6b1016
Reviewed-on: https://go-review.googlesource.com/c/go/+/493136
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, on Mach-O, we don't strip the symbol table even the -s
flag is set. This CL makes it suppress the symbol table, as
documented.
On Mach-O, even with -s, we still need to keep symbols that are
dynamically exported or referenced symbol. Otherwise the dynamic
linker cannot resolve them and the binary doesn't run.
(Interestingly, for a PIE binary it is okay to strip the symbol
table entirely. We keep the dynamic symbols for consistency. And
this is also in consistent with what the system "strip" command
does.)
Change-Id: I39c572553fe0215ae3bdf5349bf2bab7205fbdc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/492744
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We already skip testcarchive, testcshared, and testplugin in short
mode and not on builders. The shared build mode is not more
supported than the c-archive, c-shared, and plugin build modes. No
need to run it everywhere by default.
Updates #61025.
Change-Id: I6a06e04c1a1dc78f0f85456320d128bd67277915
Reviewed-on: https://go-review.googlesource.com/c/go/+/511696
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This extra newline causes pkg.go.dev and gopls to only show the bottom
half of this comment; I'm pretty sure this entire thing is meant to be
in the docs.
Change-Id: I5bbf081fb2072d9d773d5a995bc3693dc44f65ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/511855
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The timeout field is documented as being available so that it's possible
to override timeout by setting a non-zero value. If it's left at zero,
we don't need to override the default go test timeout, but we still need
to apply the timeout scale whenever it's something other than 1.
Fixes (via backport) #61468.
Change-Id: I63634e9b3ef8c4ec7f334b5a6b4bf3cad121355c
Reviewed-on: https://go-review.googlesource.com/c/go/+/511567
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Every call from C to Go does acquire a mutex to check whether Go runtime
has been fully initialized. This often does not matter, because the lock
is held only briefly. However, with code that does a lot of parallel
calls from C to Go could cause heavy contention on the mutex.
Since this is an initialization guard, we can double check with atomic
operation to provide a fast path in case the initialization is done.
With this CL, program in #60961 reduces from ~2.7s to ~1.8s.
Fixes#60961
Change-Id: Iba4cabbee3c9bc646e70ef7eb074212ba63fdc04
Reviewed-on: https://go-review.googlesource.com/c/go/+/505455
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently the GC creates a sweepLocker before restarting the world at
the end of the mark phase, so that it can safely flush mcaches without
the runtime incorrectly concluding that sweeping is done before that
happens.
However, with GODEBUG=gcstoptheworld=2, where sweeping happens during
that STW phase, creating that sweepLocker will fail, since the runtime
will conclude that sweeping is in fact complete (all the queues will be
drained). The problem however is that gcSweep, which does the
non-concurrent sweeping, doesn't actually flush mcaches.
In essence, this failure to create a sweepLocker is indicating a real
issue: sweeping is marked as complete, but we haven't flush the mcaches
yet!
The fix to this is to flush mcaches in gcSweep when in a non-concurrent
sweep. Now that gcSweep actually completes a full sweep, it's safe to
ignore a failure to create a sweepLocker (and in fact, it *must* fail).
While we're here, let's also remove _ConcurrentSweep, the debug flag.
There's already an alias for it called concurrentSweep, and there's only
one use of it in gcSweep.
Lastly, add a dist test for the GODEBUG=gcstoptheworld=2 mode.
Fixes#53885.
Change-Id: I8a1e5b8f362ed8abd03f76e4950d3211f145ab1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/479517
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The new section describes type inference as the problem
of solving a set of type equations for bound type parameters.
The next CL will update the section on unification to match
the new inference approach.
Change-Id: I2cb49bfb588ccc82d645343034096a82b7d602e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/503920
TryBot-Bypass: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
goschedImpl transitions the current goroutine from _Grunning to
_Grunnable and places it on the global run queue before calling into
schedule.
It does _not_ call wakep after adding the global run queue. I believe
the intuition behind skipping wakep is that since we are immediately
calling the scheduler so we don't need to wake anything to run this
work. Unfortunately, this intuition is not correct, as it breaks
coordination with spinning Ms [1].
Consider this example scenario:
Initial conditions:
M0: Running P0, G0
M1: Spinning, holding P1 and looking for work
Timeline:
M1: Fails to find work; drops P
M0: newproc adds G1 to P0 runq
M0: does not wakep because there is a spinning M
M1: clear mp.spinning, decrement sched.nmspinning (now in "delicate dance")
M1: check sched.runqsize -> no global runq work
M0: gosched preempts G0; adds G0 to global runq
M0: does not wakep because gosched doesn't wakep
M0: schedules G1 from P0 runq
M1: check P0 runq -> no work
M1: no work -> park
G0 is stranded on the global runq with no M/P looking to run it. This is
a loss of work conservation.
As a result, G0 will have unbounded* scheduling delay, only getting
scheduled when G1 yields. Even once G1 yields, we still won't start
another P, so both G0 and G1 will switch back and forth sharing one P
when they should start another.
*The caveat to this is that today sysmon will preempt G1 after 10ms,
effectively capping the scheduling delay to 10ms, but not solving the P
underutilization problem. Sysmon's behavior here is theoretically
unnecessary, as our work conservation guarantee should allow sysmon to
avoid preemption if there are any idle Ps. Issue #60693 tracks changing
this behavior and the challenges involved.
[1] It would be OK if we unconditionally entered the scheduler as a
spinning M ourselves, as that would require schedule to call wakep when
it finds work in case there is more work.
Fixes#55160.
Change-Id: I2f44001239564b56ea30212553ab557051d22588
Reviewed-on: https://go-review.googlesource.com/c/go/+/501976
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
When a thread transitions to spinning to non-spinning it must recheck
all sources of work because other threads may submit new work but skip
wakep because they see a spinning thread.
However, since the beginning of time (CL 7314062) we do not check the
global run queue, only the local per-P run queues.
The global run queue is checked just above the spinning checks while
dropping the P. I am unsure what the purpose of this check is. It
appears to simply be opportunistic since sched.lock is already held
there in order to drop the P. It is not sufficient to synchronize with
threads adding work because it occurs before decrementing
sched.nmspinning, which is what threads us to decide to wake a thread.
Resolve this by adding an explicit global run queue check alongside the
local per-P run queue checks.
Almost nothing happens between dropped sched.lock after dropping the P
and relocking sched.lock: just clearing mp.spinning and decrementing
sched.nmspinning. Thus it may be better to just hold sched.lock for this
entire period, but this is a larger change that I would prefer to avoid
in the freeze and backports.
For #55160.
Change-Id: Ifd88b5a4c561c063cedcfcfe1dd8ae04202d9666
Reviewed-on: https://go-review.googlesource.com/c/go/+/501975
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Issue #61486 causes a compiler crash but is not detected when running
stand-alone type-checker tests because no types are recorded.
Set up Config.Info map with all maps when when running local tests
so that type/object recording code is executed during local tests.
For #61486.
Change-Id: I8eb40c8525dac3da65db0dc7e0e654842713b9a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/511657
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently we may pass C linker flags in nondeterministic order,
as on ELf systems we pass --export-dynamic-symbol for symbols from
a map. This is usally not a big problem because even if the flags
are passed in nondeterministic order the resulting binary is
probably still deterministic. This CL makes it pass them in a
deterministic order to be extra sure. This also helps build
systems where e.g. there is a build cache for the C linking action.
Change-Id: I930524dd2c3387f49d62be7ad2cef937cb2c2238
Reviewed-on: https://go-review.googlesource.com/c/go/+/509215
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
When running "go test" including a main package which has a PGO
profile, we currently build the package being tested and its
dependencies with PGO, but we failed to attach the profile to
test-only dependencies. If a package is (transitively) imported
by both the package being tested and the test, the PGO version
and the non-PGO version of the package are both linked into the
binary, causing link-time error.
This CL fixes this by attaching the PGO profile to dependencies of
the test.
Fixes#61376.
Change-Id: I2559db9843c4cdab596b31e2025d8475ffbf58ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/510835
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The compiler/assembler's -S output prints relocation type
numerically, which is hard to understand. Every time I need to
count the relocation type constants to figure out which relocation
it actually is. Print the symbolic name instead.
Change-Id: I4866873bbae8b3dc0ee212609cb00280f9164243
Reviewed-on: https://go-review.googlesource.com/c/go/+/501856
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
We don't use R_PCREL for calls to dynamic symbols (we use R_CALL
instead). Don't handle R_PCREL as a call.
We don't use R_CALL on ARM64 (we use R_CALLARM64 instead).
Remove those cases, which we don't expect to see.
Change-Id: Idd99022a8eeb65750ffc2936ffdccf8bb0405e30
Reviewed-on: https://go-review.googlesource.com/c/go/+/501859
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, on darwin, we only support cgo_dynamic_import for
functions, but not variables, as we don't need it before.
mach_task_self_ is a variable defined in the system library, which
can be used to e.g. access the process's memory mappings via the
mach API. The C header defines a macro mach_task_self(), which
refers to the variable. To use mach_task_self_ (in pure-Go
programs) we need to access it in Go.
This CL handles cgo_dynamic_import for variables in the linker,
loading its address via the GOT. (Currently only on Darwin, as
we only need it there.)
For #50891.
Change-Id: Idf64fa88ba2f2381443a1ed0b42b14b581843493
Reviewed-on: https://go-review.googlesource.com/c/go/+/501855
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
If the test is about to time out, testenv.Command sends SIGQUIT to the
child process. The runtime's SIGQUIT goroutine dump should help us to
determine whether the hangs observed in TestCPUProfileWithFork are a
symptom of #60108 or a separate bug.
For #59995.
Updates #60108.
Change-Id: I26342ca262b2b0772795c8be142cfcad8d90db30
Reviewed-on: https://go-review.googlesource.com/c/go/+/507356
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
`syscall.ForkLock` is not used in `syscall.StartProcess` since
CL 288297, so using it in `sysSocket` makes no sense. This CL
goes a little bit further and removes the `sysSocket` fallback for
Windows 7, since it is not supported since go 1.21 (#57003).
Updates #60942
Change-Id: If14a0d94742f1b80af994f9f69938701ee41b402
Reviewed-on: https://go-review.googlesource.com/c/go/+/506136
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This CL partially reverts CL 297034. Inheritable handles are not
inherited by all workers thanks to using AdditionalInheritedHandles,
which explicitly specifies which handles to inherit by each worker.
This CL doesn't fix any bug, it's more of a cleanup, but also makes
the code more robust and more similar to its Unix counterpart.
Change-Id: I24c2d7f69dfb839a1aeb5858088d8f38b022f702
Reviewed-on: https://go-review.googlesource.com/c/go/+/506535
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
They are already collected via cmd/cgo.
The gccgo_link_c test is tweaked to do real linking as with this
change the cgo ldflags are not fully reflected in go build -n output,
since they now only come from the built archive.
Fixes#60287
Change-Id: Id433435fe8aeb9571327bf936e52a37f400cef4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/497117
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Andrey Bokhanko <andreybokhanko@gmail.com>
The mode used in the os.OpenFile example (0755) has all executable bits set.
I suspect that this ill-advised usage propagates to other codebases (by means of people carelessly copying the usage example), which is why I suggest modifying the example.
Change-Id: Ic36c8b41974f3fe00471822c2414e36b4e5dc1bc
GitHub-Last-Rev: 638f3beefe
GitHub-Pull-Request: golang/go#61384
Reviewed-on: https://go-review.googlesource.com/c/go/+/510135
Reviewed-by: Rob Pike <r@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Use generic implementation of IndexByte/IndexByteString
on plan9/amd64 since the assembly implementation
uses SSE instructions which are classified as floating
point instructions and cannot be used in a note handler.
A similar issue was fixed in CL 100577.
This fixes runtime.TestBreakpoint.
Fixes#61087.
Change-Id: Id0c085e47da449be405ea04ab9b93518c4e2fde8
Reviewed-on: https://go-review.googlesource.com/c/go/+/508400
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
The runtime was adjusting netpollWaiters before the waiting
goroutines were marked as ready. This could cause the scheduler
to report a deadlock because there were no goroutines ready to run.
Keeping netpollWaiters non-zero ensures that at least one goroutine
will call netpoll(-1) from findRunnable.
This does mean that if a program has network activity for a while
and then never has it again, and also has no timers, then we can leave
an M stranded in a call to netpoll from which it will never return.
At least this won't be a common case. And it's not new; this has been
a potential problem for some time.
Fixes#61454
Change-Id: I17c7f891c2bb1262fda12c6929664e64686463c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/511455
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The Windows DLL loader may call a DLL entry point, in our case
_rt0_amd64_windows_lib, with a stack that is
not 16-byte aligned. In theory, it shouldn't, but under some
circumstances, it does (see below how to reproduce it).
Having an unaligned stack can, and probably will, cause problems
down the line, for example if a movaps instruction tries to store
a value in an unaligned address it throws an Access Violation exception
(code 0xc0000005).
I managed to consistently reproduce this issue by loading a Go DLL into
a C program that has the Page Heap Verification diagnostic enabled [1].
Updates #54187 (and potentially fixes)
[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/example-12---using-page-heap-verification-to-find-a-bug
Change-Id: Id0fea7f407e024c9b8cdce10ce4802d7535e7542
Reviewed-on: https://go-review.googlesource.com/c/go/+/510755
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
We used to decrement it in netpollgoready, but that missed
the common case of a descriptor becoming ready due to I/O.
All calls to netpollgoready go through netpollunblock,
so this shouldn't miss any decrements we missed before.
Fixes#60782
Change-Id: Ideefefa1ac96ca38e09fe2dd5d595c5dd7883237
Reviewed-on: https://go-review.googlesource.com/c/go/+/503923
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Tested locally by changing GOROOT/go.env. At some point perhaps we
should also set up a builder that runs with some common expected
modifications to go.env
(such as GOTOOLCHAIN=local GOPROXY=direct GOSUMDB=off).
Fixes#61358.
Updates #61359.
Change-Id: I365ec536bec86370e302fb726fa897400ab42cf3
Reviewed-on: https://go-review.googlesource.com/c/go/+/509637
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This causes instances commonHandler created by withAttrs or withGroup to
share a mutex with their parent preventing concurrent writes to their
shared writer.
Fixes#61321
Change-Id: Ieec225e88ad51c84b41bad6c409fac48c90320b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/509196
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Due to an errant newline, both 'go doc' and pkg.go.dev currently
interpret the long comment in cmd/covdata/doc.go as a file comment
instead of package documentation.
Removing the errant newline caused 'go doc' to render the comment, but
it does not strip out the interior '//' tokens from the '/* … */'
block.
Removing those tokens and fixing up indentation seems to give
satisfactory rendering.
Change-Id: I5757c649e7380b026f7d8d1b6fd3cb6dddfb27ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/509635
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TestCompareBytes already took into account the -short
testing flag, however, only if not run on one of the Go builders.
This extra condition is no longer necessary as we have much
better longtest coverage than we did when the check was added.
Fixes#61071
Change-Id: I0fc716f4e7baa04019ee00608f223f27c931edcc
Reviewed-on: https://go-review.googlesource.com/c/go/+/507416
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Bypass: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The call from toolchain.Select to gover.FromToolchain was passing the
wrong argument but this was masked by gover.IsValid being a little bit
too lax.
Fix and test IsValid, which then breaks the existing gotoolchain_local
test, and then fix toolchain.Select to fix the test.
Fixes#61068.
Change-Id: I505ceb227457d6a51bd5e47f009b2fb1010c0d1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/508820
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(ANDCCconst [y] (MOV.*reg x)) should only be merged when zero
extending. Otherwise, sign bits are lost on negative values.
(ANDCCconst [0xFF] (MOVBreg x)) should be simplified to a zero
extension of x. Likewise for the MOVHreg variant.
Fixes#61297
Change-Id: I04e4fd7dc6a826e870681f37506620d48393698b
Reviewed-on: https://go-review.googlesource.com/c/go/+/508775
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Update the README to specify the module query "@master" instead of
"@latest".
Vendoring the highest tagged version is unlikely to be right. Usually
one wants to vendor the module at HEAD.
Change-Id: Id00d23523a13fd3dcd73d6eacefdf50bcdbfa26e
Reviewed-on: https://go-review.googlesource.com/c/go/+/508823
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
As #61067 pointed out, slog did not properly handle empty groups.
https://go.dev/cl/508436 dealt with most cases inside slog itself,
but handlers must still do a check on their own. Namely, a handler
must not output a group created by WithGroup unless the Record
has attributes.
This change adds a test to slogtest to check that case.
Fixes#61227.
Change-Id: Ibc065b6e5f6e199a41bce8332ea8c7f9d8373392
Reviewed-on: https://go-review.googlesource.com/c/go/+/508438
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also fix a (minor) double-Close error in Serve that was exposed by the
test fix.
Serve accepts a net.Listener, which produces net.Conn instances.
The documentation for net.Conn requires its methods to be safe for
concurrent use, so most implementations likely allow Close to be
called multiple times as a side effect of making it safe to call
concurrently with other methods. However, the net.Conn interface is a
superset of the io.Closer interface, io.Closer explicitly leaves the
behavior of multiple Close calls undefined, and net.Conn does not
explicitly document a stricter requirement.
Perhaps more importantly, the test for the fcgi package calls
unexported functions that accept an io.ReadWriteCloser (not a
net.Conn), and at least one of the test-helper ReadWriteCloser
implementations expects Close to be called only once.
The goroutine leaks were exposed by a racy arbitrary timeout reported
in #61271. Fixing the goroutine leak exposed the double-Close error:
one of the leaked goroutines was blocked on reading from an unclosed
pipe. Closing the pipe (to unblock the goroutine) triggered the second
Close call.
Fixes#61271.
Change-Id: I5cfac8870e4bb4f13adeee48910d165dbd4b76fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/508815
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We cancel the Context to unblock the test as soon as all of the "exit"
processes have completed. If that happens to occur before all of the
"hang" processes have started, the Start calls may fail with
context.Canceled.
Since those errors are possible in normal operation of the test,
ignore them.
Fixes#61277.
Updates #61080.
Change-Id: I20db083ec89ca88eb085ceb2892b9f87f83705ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/508755
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The previous upper bound was around 0.375 s, which is empirically
too short on a slow, heavily-loaded builder. Since the test doesn't
seem to depend on the actual duration in any meaningful way, let's
make it several orders of magnitude larger.
Fixes#61266.
Change-Id: I6dde5e174966ee385db67e3cb87334f463c7e597
Reviewed-on: https://go-review.googlesource.com/c/go/+/508695
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
When adding MPTCP support to address the proposal #56539, I missed the
GODEBUG setting from Russ Cox's plan:
I am inclined to say that we add MPTCP as an opt-in for a release or
two, and then make it opt-out. There should be a GODEBUG setting (...)
See: https://github.com/golang/go/issues/56539#issuecomment-1309294637
Thanks to andrius4669 for having reported this issue to me.
It makes sense to have this GODEBUG setting not to have to modify
applications to use MPTCP (if available). It can then be useful to
estimate the impact in case we want to switch from opt-in to opt-out
later.
The MPTCP E2E test has been modified to make sure we can enable MPTCP
either via the source code like it was already the case before or with
this environment variable:
GODEBUG=multipathtcp=1
The documentation has been adapted accordingly.
I don't know if it is too late for Go 1.21 but I had to put a version in
the documentation. The modification is small, the risk seems low and
this was supposed to be there from the beginning according to Russ Cox's
specifications. It can also be backported or only be present in the
future v1.22 if it is easier.
Note: I didn't re-open #56539 or open a new one. It is not clear to me
what I should do in this case.
Fixes#56539
Change-Id: I9201f4dc0b99e3643075a34c7032a95528c48fa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/507375
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
In CL 421441, we changed syscall to allow concurrent calls to
forkExec.
On platforms that support the pipe2 syscall that is the right
behavior, because pipe2 atomically opens the pipe with CLOEXEC already
set.
However, on platforms that do not support pipe2 (currently aix and
darwin), syscall.forkExecPipe is not atomic, and the pipes do not
initially have CLOEXEC set. If two calls to forkExec proceed
concurrently, a pipe intended for one child process can be
accidentally inherited by the other. If the process is long-lived, the
pipe can be held open unexpectedly and prevent the parent process from
reaching EOF reading the child's status from the pipe.
Fixes#61080.
Updates #23558.
Updates #54162.
Change-Id: I83edcc80674ff267a39d06260c5697c654ff5a4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/507355
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
GetFileInformationByHandleEx can return `ERROR_FILE_NOT_FOUND` when no
files were found in a root directory, as per MS-FSA 2.1.5.6.3 [1].
This error code should not be treated as an error, but rather as an
indication that no files were found, in which case `readdir` should
return an empty slice.
This CL doesn't add any test as it is difficult to trigger this error
code. Empty root directories created using Windows utilities such as
`net use` always report at least the optional `.` and `..` entries.
A reproducer is provided in #61159, but it requires WinFSP to be
installed.
Fixes#61159
[1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fsa/fa8194e0-53ec-413b-8315-e8fa85396fd8
Change-Id: Id46452030f5355c292e5b0abbf5e22af434a84d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/507775
Reviewed-by: Nick Craig-Wood <nickcw@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
2023-07-07 22:02:26 +00:00
3375 changed files with 140775 additions and 53381 deletions
description:"If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on [go.dev/play](https://go.dev/play) is best."
validations:
required:true
- type:textarea
id:actual-behavior
attributes:
label:"What did you see happen?"
description:Command invocations and their associated output, functions with their arguments and return results, full stacktraces for panics (upload a file if it is very long), etc. Prefer copying text output over using screenshots.
validations:
required:true
- type:textarea
id:expected-behavior
attributes:
label:"What did you expect to see?"
description:Why is the current output incorrect, and any additional context we may need to understand the issue.
description:Issues or feature requests for the documentation site
title:"x/pkgsite: issue title"
labels:["pkgsite"]
body:
- type:markdown
attributes:
value:"Please answer these questions before submitting your issue. Thanks!"
- type:input
id:url
attributes:
label:"What is the URL of the page with the issue?"
validations:
required:true
- type:input
id:user-agent
attributes:
label:"What is your user agent?"
description:"You can find your user agent here: https://www.google.com/search?q=what+is+my+user+agent"
validations:
required:true
- type:textarea
id:screenshot
attributes:
label:"Screenshot"
description:"Please paste a screenshot of the page."
validations:
required:false
- type:textarea
id:what-did-you-do
attributes:
label:"What did you do?"
description:"If possible, provide a recipe for reproducing the error. Starting with a Private/Incognito tab/window may help rule out problematic browser extensions."
about: Request a package be removed from the documentation site (pkg.go.dev)
title: "x/pkgsite: package removal request for [type path here]"
labels: pkgsite/package-removal
---
<!--
Please answer these questions before submitting your issue. Thanks!
-->
### What is the path of the package that you would like to have removed?
<!---
We can remove packages with a shared path prefix.
For example, a request for "github.com/author" would remove all pkg.go.dev pages with that package path prefix.
--->
### Are you the owner of this package?
<!---
Only the package owners can request to have their packages removed from pkg.go.dev.
--->
### What is the reason that you could not retract this package instead?
<!---
If you would like to have your module removed from pkg.go.dev, we recommend that you retract them, so that they can be removed from the go command and proxy.golang.org as well.
Retracting a module version involves adding a retract directive to your go.mod file and publishing a new version. For example: https://github.com/jba/retract-demo/blob/main/go.mod#L5-L8
See https://pkg.go.dev/about#removing-a-package for additional tips on retractions.
description:Issues or feature requests for the Go language server (gopls)
title:"x/tools/gopls: issue title"
labels:["gopls","Tools"]
body:
- type:markdown
attributes:
value:"Please answer these questions before submitting your issue. Thanks!"
- type:input
id:gopls-version
attributes:
label:"gopls version"
description:"Output of `gopls -v version` on the command line"
validations:
required:true
- type:textarea
id:go-env
attributes:
label:"go env"
description:"Output of `go env` on the command line in your workspace directory"
render:shell
validations:
required:true
- type:textarea
id:what-did-you-do
attributes:
label:"What did you do?"
description:"If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on [go.dev/play](https://go.dev/play) is better. A failing unit test is the best."
validations:
required:true
- type:textarea
id:actual-behavior
attributes:
label:"What did you see happen?"
validations:
required:true
- type:textarea
id:expected-behavior
attributes:
label:"What did you expect to see?"
validations:
required:true
- type:textarea
id:editor-and-settings
attributes:
label:"Editor and settings"
description:"Your editor and any settings you have configured (for example, your VSCode settings.json file)"
validations:
required:false
- type:textarea
id:logs
attributes:
label:"Logs"
description:"If possible please include gopls logs. Instructions for capturing them can be found here: https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capture-logs"
name:Go vulnerability management - bugs and feature requests
description:Issues or feature requests about Go vulnerability management
title:"x/vuln: issue title"
labels:["vulncheck or vulndb"]
body:
- type:markdown
attributes:
value:"Please answer these questions before submitting your issue. Thanks! To add a new vulnerability to the Go vulnerability database (https://vuln.go.dev), see https://go.dev/s/vulndb-report-new. To report an issue about a report, see https://go.dev/s/vulndb-report-feedback."
- type:textarea
id:govulncheck-version
attributes:
label:govulncheck version
description:What version of govulncheck are you using (`govulncheck -version`)?
placeholder:|
Go: devel go1.22-0262ea1ff9 Thu Oct 26 18:46:50 2023 +0000
label:"Does this issue reproduce at the latest version of golang.org/x/vuln?"
validations:
required:true
- type:textarea
id:go-env
attributes:
label:"Output of `go env` in your module/workspace:"
render:shell
validations:
required:true
- type:textarea
id:what-did-you-do
attributes:
label:"What did you do?"
description:"If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on [go.dev/play](https://go.dev/play) is best."
description:New telemetry counter or update on an existing one
title:"x/telemetry/config: proposal title"
labels:["Telemetry-Proposal"]
projects:["golang/29"]
body:
- type:textarea
attributes:
label:Counter names
description:Names of counters to add or update.
validations:
required:true
- type:textarea
attributes:
label:Description
description:What do these counters measure?
validations:
required:true
- type:textarea
attributes:
label:Rationale
description:|
Why is the counter important?
For example, what new insights will it provide, and how will that information be used?
If this is about updating existing counters, why is the change necessary?
validations:
required:true
- type:textarea
attributes:
label:Do the counters carry sensitive user information?
validations:
required:true
- type:textarea
attributes:
label:How?
description:|
How do we plan to compute the info?
If available, include the code location or cl that uses the golang.org/x/telemetry/counter API.
validations:
required:true
- type:textarea
attributes:
label:Proposed Graph Config
description:|
Approved telemetry counters are maintained as [Go Telemetry Graph Config](https://golang.org/x/telemetry/internal/graphconfig) records.
Please draft the record entry for your proposal here.
If multiple records need to be included, separate them with `---` lines.
You can check the list of the approved counters and their current configuration in [config.txt](https://go.googlesource.com/telemetry/+/master/internal/configgen/config.txt).
render:Text
value:|
counter: gopls/bug
title: Gopls bug reports
description: Stacks of bugs encountered on the gopls server.
type: partition, histogram, stack # choose only one.
program: golang.org/x/tools/gopls
counter: gopls/bug
depth: 16 # only if type is stack.
version: v0.13.0 # the first binary version containing this counter.
validations:
required:true
- type:dropdown
attributes:
label:New or Update
description:Is this a new counter? See [config.txt](https://go.googlesource.com/telemetry/+/master/internal/configgen/config.txt) for the list of approved counters.
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
packageissue9026
// This file appears in its own package since the assertion tests the
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
