Given we have support for field access to type params with a single
structural type, we need to distinguish between methods calls and field
access when we have an OXDOT node on an expression which is a typeparam
(or correspondingly a shape). We were missing checks in getInstInfo,
which figures out the dictionary format, which then caused problems when
we generate the dictionaries. We don't need/want dictionary entries for
field access, only for bound method calls. Added a new function
isBoundMethod() to distinguish OXDOT nodes which are bound calls vs.
field accesses on a shape.
Removed isShapeDeref() - we can't have field access or method call on a
pointer to variable of type param type.
Fixes#50690
Change-Id: Id692f65e6f427f28cd2cfe474dd30e53c71877a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/379674
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Add some useful comments, mainly relates to types.Type. (No non-comment
changes.)
Change-Id: I3665ed69b180c4e790af2f9243f65c805083391a
Reviewed-on: https://go-review.googlesource.com/c/go/+/379918
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Very, very rarely TestVectoredHandlerDontCrashOnLibrary fails because
the C subprocess exits with a 0 status code and no output. This
appears to happen because C does not actually guarantee that stdout
will be flushed on exit and somehow, very rarely, it is not flushed.
Add explicit fflushes to fix this. This reduces the failure rate of
TestVectoredHandlerDontCrashOnLibrary from 0.0013% to 0% in 250,000
iterations.
Fixes#49959.
Change-Id: I892cf49a165ac91134c5da37588a2ab11e1f3f8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/380494
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Mostly from CL 367954.
Change-Id: Id003b0f785a286a1a649e4d6e8c87d0418a36545
Reviewed-on: https://go-review.googlesource.com/c/go/+/379920
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This fixes checks for crossing module boundaries when the root of
the module is a symlink. We're comparing paths by string, so we need
to follow the symlink to get the proper path to compare.
Change-Id: Idf5f0dd5c49bcae5fffb5372e99a7fab89169a9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/380057
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The closure in parallelLabelHog should be labeled in a addition to
parallelLabelHog itself. Generally samples on that goroutine land on
labelHog, but there is a small portion of the closure outside of
labelHog.
Fixes#50740.
Change-Id: I363b6d8eec2e6920c215686e2039fce6d5b29a98
Reviewed-on: https://go-review.googlesource.com/c/go/+/380055
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Pratt <mpratt@google.com>
This reverts CL 376414.
For #47694.
For #50481.
Change-Id: Ie73961046e52e6e5d3262ef0aeaa24bec7eaa937
Reviewed-on: https://go-review.googlesource.com/c/go/+/379835
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In a method declaration "func (f *Foo[_, _]) String() string { ... }",
the two blank typeparams have the same name, but our current design with
types1 needs unique names for type params. Similarly, for export/import,
we need unique names to keep the type params straight in generic types
and connect the proper type param with the proper constraint. We make
blank type params unique by changing them to $1, $2, etc in noder.typ0()
via typecheck.TparamExportName(). We then revert $<num> back to _ during
type2 import via typecheck.TparamName(). We similarly revert
during gcimporter import. We don't need/want to revert in the types1
importer, since we want unique names for type params.
Rob Findley has made a similar change to x/tools (and we tried to make
the source code changes similar for the gcimporter and types2 importer
changes).
Fixes#50419
Change-Id: I855cc3d90d06bcf59541ed0c879e9a0e4ede45bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/379194
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Use an enviroment variable rather than a build tag to control starting
a busy loop thread when testprogcgo starts. This lets us skip another
build that invokes the C compiler and linker, which should avoid
timeouts running the runtime tests.
Fixes#44422
Change-Id: I516668d71a373da311d844990236566ff63e6d72
Reviewed-on: https://go-review.googlesource.com/c/go/+/379294
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
And disallow replaces of any main modules in the go.work file itself.
Change-Id: Ifa9ba9eaed047e6a75fcde230d96c7c450c1a1ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/379534
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that we instantiate methods on instantiated types, there is no need
to use unification to match signatures inside of missingMethod.
Generally, we should never encounter uninstantiated signatures within
statements. If we do encounter signatures that contain type parameters,
it is because the signatures are themselves defined or instantiated
using type parameters declared in the function scope (see example
below). The current unification logic would not handle this.
type S[T any] struct{}
func (S[T]) m(T)
func _[P any]() bool {
var v interface{m(int)}
_, ok = v.(S[P])
return ok
}
Change-Id: I754fb5535bba2fc7a209dc7419fd4015c413c9a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/379540
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is a map from identifiers to type parameters, use *TypeParam
as map value instead of Type.
Change-Id: Ib006393418c6352bcffc1c6796c5e002c33d9f4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/379634
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Most CONVIFACEs are created in the transform phase (or old typechecker,
in -G=0 mode). But if the main result of a multi-value assignment (map,
channel, or dot-type) must be converted to an interface during the
assignment, that CONVIFACE is not created until (*orderState).as2ok in
the order phase (because the AS2* ops and their sub-ops are so tightly
intertwined). But we need to create the CONVIFACE during the
stenciling/transform phase to enable dictionary lookups. So, in
transformAssign(), if we are doing a special multi-value assignment
involving a type-param-derived type, assign the results first to temps,
so that we can manifest the CONVIFACE during the transform in assigning
the first temp to lhs[0].
Added a test for both AS2RECV (channel receives) and AS2MAPR (maps). I
don't think we can have a type assertion on a type-param-derived type.
Fixes#50642
Change-Id: I4d079fc46c93d8494d7db4ea8234d91522edb02a
Reviewed-on: https://go-review.googlesource.com/c/go/+/379054
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Slightly better for cases such as string(1 << s).
Leaves type-checker tests alone for now because
there are multiple dozens.
For #45117.
Change-Id: I47b314c713fabe424c2158674bf965416a8a6f5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/379274
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
It was removed in CL 378576.
For #50501
Change-Id: I26b8f0e99a40fa5c616aa4849a6ab15dd0d072f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/379314
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TestCPUProfileMultithreadMagnitude compares pprof results vs OS rusage
to verify that pprof is capturing all CPU usage. Presently it compares
the sum of cpuHog1 samples vs rusage. However, background usage from the
scheduler, GC, etc can cause additional CPU usage causing test failures
if rusage is too far off from the cpuHog1 samples.
That said, this test doesn't actually need to care about cpuHog1
samples. It simply cares that pprof samples match rusage, not what the
breakdown of usage was. As a result, we can compare the sum of _all_
pprof samples vs rusage, which should implicitly include any background
CPU usage.
Fixes#50097.
Change-Id: I649a18de5b3dcf58b62be5962fa508d14cd4dc79
Reviewed-on: https://go-review.googlesource.com/c/go/+/379535
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Document and enforce API expectation. Add a test so we don't
inadvertently change the function behavior with respect to nil
type arguments.
Fixes#50620.
Change-Id: Ic000bff7504a03006bd248a319c7a2d49dcf09c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/379374
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This makes TestLabelSystemstack much more strict, enabling it to detect
any misplacement of labels.
Unfortunately, there are several edge cases where we may not have an
obviously correct stack trace, so we generally except the runtime
package, with the exception of background goroutines that we know should
not be labeled.
For #50007
For #50032
Change-Id: I8dce7e7da04f278ce297422227901efe52782ca0
Reviewed-on: https://go-review.googlesource.com/c/go/+/369984
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
GC background mark worker goroutines are created when the first GC is
triggered (or next GC after GOMAXPROCS increases). Since the GC can be
triggered from a user goroutine, those workers will inherit any pprof
labels from the user goroutine.
That isn't meaningful, so avoid it by excluding system goroutines from
inheriting labels.
Fixes#50032
Change-Id: Ib425ae561a3466007ff5deec86b9c51829ab5507
Reviewed-on: https://go-review.googlesource.com/c/go/+/369983
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Instead, allow the test to run up until nearly the test's deadline,
whatever that may be, and then crash with a panic (instead of calling
t.Errorf) to get a useful goroutine dump.
With the arbitrary timeout removed, we can now also run this test in
short mode, reducing its impact on test latency.
Fixes#19381
Change-Id: Ie1fae321a2973fcb9b69a012103363f16214f529
Reviewed-on: https://go-review.googlesource.com/c/go/+/378034
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For an extension operation like MOWWreg, if the operand is already
extended, we optimize the second extension out. Usually a LoadReg
of a proper type would come already extended, as a MOVW/MOVWU etc.
instruction does. But for a LoadReg to a floating point register,
the instruction does not do the extension. So we cannot elide the
extension.
Fixes#50671.
Change-Id: Id8991df78d5acdecd3fd6138c558428cbd5f6ba3
Reviewed-on: https://go-review.googlesource.com/c/go/+/379236
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This test occasionally takes very slightly longer than the 3 second
timeout on slow builders (especially windows-386-2008), so increase
the timeout to 5 seconds. It fails with much longer timeouts on Plan
9, so skip it as flaky there.
Updates #41015.
Change-Id: I426a7adfae92c18a0f8a223dd92762b0b91565e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/379214
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This test was missed in CL 358539, presumably because the 'longtest'
builders lack a 'gpg' executable.
Updates #49168Fixes#50675
Change-Id: Ie3bfc761a5e4304531119625742f3def9df8af3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/378575
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently the code handles the case of returning values from
a function with no result parameters as a special case.
Consider this input:
package p
func f0_2() { return 1, 2 }
func f0_1() { return 1 }
func f1_0() int { return }
func f1_2() int { return 1, 2 }
func f2_0() (int, int) { return }
func f2_1() (int, int) { return 1 }
The errors are:
x.go:3:33: no result values expected <<<
x.go:4:33: no result values expected <<<
x.go:5:26: not enough return values
have ()
want (int)
x.go:6:36: too many return values
have (number, number)
want (int)
x.go:7:26: not enough return values
have ()
want (int, int)
x.go:8:33: not enough return values
have (number)
want (int, int)
There are two problems with the current special case emitting the
errors on the marked line:
1. It calls them 'result values' instead of 'return values'.
2. It doesn't show the type being returned, which can be useful to programmers.
Using the general case solves both these problems,
so this CL removes the special case and calls the general case instead.
Now those two errors read:
x.go:3:33: too many return values
have (number, number)
want ()
x.go:4:33: too many return values
have (number)
want ()
Fixes#50653.
Change-Id: If6b47dcece14ed4febb3a2d3d78270d5be1cb24d
Reviewed-on: https://go-review.googlesource.com/c/go/+/379116
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Consider the following program:
package p
func f() {
x := 1
v := 2
switch v.(type) {
case int:
println(x)
println(x / 0)
case 1:
}
}
Before this CL, the compiler prints:
x.go:4:2: x declared but not used
x.go:6:9: v (variable of type int) is not an interface
x is in fact used, and other errors in the switch go undiagnosed.
This commit fixes that problem by processing the switch statement
even when the 'not an interface' error is reported.
Now the compiler drops the spurious 'declared but not used'
and adds two previously undiagnosed problems:
x.go:6:9: v (variable of type int) is not an interface
x.go:9:15: invalid operation: division by zero
x.go:10:7: 1 is not a type
go/types was printing roughly the same thing the compiler did before,
and now still prints roughly the same thing the compiler does after.
(The only differences are in the exact reported columns.)
Fixes#50493.
Change-Id: I317883f29077b1b4bbd0e8793617fd3bb31aa0f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/379117
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This extends the skip added in CL 375635 to the "_Headers" variant of
the test, since we have observed similar failures in that variant on
the builders.
For #43120
Change-Id: Ib1c97fbb776b576271629272f3194da77913a941
Reviewed-on: https://go-review.googlesource.com/c/go/+/379156
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
In the compiler, we need to distinguish field and method access on a
type param. For field access, we avoid the dictionary access (to create
an interface bound) and just do the normal transformDot() (which will
create the field access on the shape type).
This field access works fine for non-pointer types, since the shape type
preserves the underlying type of all types in the shape. But we
generally merge all pointer types into a single shape, which means the
field will not be accessible via the shape type. So, we need to change
Shapify() so that a type which is a pointer type is mapped to its
underlying type, rather than being merged with other pointers.
Because we don't want to change the export format at this point in the
release, we need to compute StructuralType() directly in types1, rather
than relying on types2. That implementation is in types/type.go, along
with the helper specificTypes().
I enabled the compiler-related tests in issue50417.go, added an extra
test for unnamed pointer types, and added a bunch more tests for
interesting cases involving StructuralType(). I added a test
issue50417b.go similar to the original example, but also tests access to
an embedded field.
I also added a unit test in
cmd/compile/internal/types/structuraltype_test.go that tests a bunch of
unusual cases directly (some of which have no structural type).
Updates #50417
Change-Id: I77c55cbad98a2b95efbd4a02a026c07dfbb46caa
Reviewed-on: https://go-review.googlesource.com/c/go/+/376194
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#50501
(in a sense, by removing a flag that looks like it should do something
it does not)
Change-Id: I69ae4862706a6283cda4016fd43b361bb21557f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/378576
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
We use uname -m to decide the GOHOSTARCH default,
and on my ARM64 Mac laptop, uname -m prints x86_64.
uname -a prints:
Darwin p1.local 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000 x86_64
(Note the x86_64 at the end, consistent with uname -m.)
The effect of this is that make.bash builds an x86 toolchain
even when I start with an ARM64 bootstrap toolchain!
Avoid being tricked by looking for RELEASE_ARM64 instead.
Fixes#50643.
Change-Id: I76eded84bde8009d29419d5982bf964a0bf1c8fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/378894
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The VMOVQ instruction stores a 128-bit number into a V register, for
example:
VMOVQ $0x1122334455667788, $0x99aabbccddeeff00, V2
From a documentation (https://pkg.go.dev/cmd/internal/obj/arm64) point
of view, the value in V2 should be 0x112233445566778899aabbccddeeff00,
however the value is actually 0x99aabbccddeeff001122334455667788. The
reason is that we misplaced the high 64-bit and the low 64-bit in the
literal pool. To maintain backward compatibility, this CL adjusts the
rule of VMOVQ instruction to make the documentation consistent with the
code.
Fixes#50528
Change-Id: Ib51f59e97c55252ab2a50bbc6ba4d430732a7a04
Reviewed-on: https://go-review.googlesource.com/c/go/+/377055
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Eric Fang <eric.fang@arm.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Trust: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, there are two regexps in the race detector output tests
that assume subtests will complete in < 1 second. This isn't necessary
and very occasionally fails (on builders that are probably very
loaded). Make these tests less picky about timing.
Fixes#50612.
Change-Id: Ib3f94d6c5dc37541dbeb06de71cf462a74af844b
Reviewed-on: https://go-review.googlesource.com/c/go/+/378581
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
As a follow-up to https://golang.org/cl/371474, add the OS version to
the metadata printed for each test.
Fixes#50146.
Change-Id: I3b7e47983d0e85feebce8e424881b931882d53bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/371475
Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Knowing whether test failures are correlated with specific CPU models on
has proven useful on several issues. Log it for prior to testing so it
is always available.
internal/sysinfo provides the CPU model, but it is not available in the
bootstrap toolchain, so we can't access this unconditionally in
cmd/dist. Instead use a build-tagged file, as the final version of
cmd/dist will use the final toolchain.
The addition of new data to the beginning of cmd/dist output will break
x/build/cmd/coordinator's banner parsing, leaving extra lines in the log
output, though information will not be lost.
https://golang.org/cl/372538 fixes up the coordinator and should be
submitted and deployed before this CL is submitted.
For #46272.
For #49209.
For #50146.
Change-Id: I515d2ec58e4c0034b76bf624ecaab38f16146074
Reviewed-on: https://go-review.googlesource.com/c/go/+/371474
Trust: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
SHT_NOBITS sections do not occupy space in the file and their offset is
"conceptual", reading their data should return all zeroes instead of
reading bytes from the section that follows them.
Change-Id: Iaa9634792c1909c3e87dab841dd646cd6dcf9027
Reviewed-on: https://go-review.googlesource.com/c/go/+/375216
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also adjust other skips to actually call t.Skip, so that the test
correctly shows as skipped instead of passing.
For #50605
Change-Id: Ied482f231a879224c5a92e2c47a6b21c1593a7da
Reviewed-on: https://go-review.googlesource.com/c/go/+/378554
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The netpoll code was written long ago, when the
only multiprocessors that Go ran on were x86.
It assumed that an atomic store would trigger a
full memory barrier and then used that barrier
to order otherwise racy access to a handful of fields,
including pollDesc.closing.
On ARM64, this code has finally failed, because
the atomic store is on a value completely unrelated
to any of the racily-accessed fields, and the ARMv8
hardware, unlike x86, is clever enough not to do a
full memory barrier for a simple atomic store.
We are seeing a constant background rate of trybot
failures where the net/http tests deadlock - a netpollblock
has clearly happened after the pollDesc has begun to close.
The code that does the racy reads is netpollcheckerr,
which needs to be able to run without acquiring a lock.
This CL fixes the race, without introducing unnecessary
inefficiency or deadlock, by arranging for every updater
of the relevant fields to publish a summary as a single
atomic uint32, and then having netpollcheckerr use a
single atomic load to fetch the relevant bits and then
proceed as before.
Fixes#45211 (until proven otherwise!).
Change-Id: Ib6788c8da4d00b7bda84d55ca3fdffb5a64c1a0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/378234
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When we export a shape instantiation, because a particular
fully-instantiated type is needed by an inlineable function, we possibly
export the body of the instantiation, if it is inlineable. In this case,
we should have been calling ImportedBody() to make sure that the
function body had already been read in (if it is actually imported from
another package).
Fixes#50598
Change-Id: I512d2bcc745faa6ff3a97e25bc8f46e2c2643d23
Reviewed-on: https://go-review.googlesource.com/c/go/+/378494
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Let T be a type parameter, and say we instantiate it with S, a type
that isn't pointer-like (e.g. a pair of ints, or as in 50182, a
slice). Then to call a method m on a variable of type T, the compiler
does essentially:
var v T = ...
i := (interface{m()})(v)
i.m()
The conversion at that second line allocates, as we need to make the
data word for an interface. And in the general case, that interface
may live an arbitrarily long time. But in this case, we know it
doesn't.
The data word of i has type *S. When we call i.m, we can't call S.m
directly. It is expecting an S, not a *S. We call through a wrapper
defined on *S, which looks like:
func (p *S) m() {
var s S = *p
s.m()
}
The value passed in for p is exactly the data word mentioned above. It
never escapes anywhere - the wrapper copies a type S variable out of
*p and p is dead after that. That means that in the situation where we
build an interface for the explicit purpose of calling a method on it,
and use that built interface nowhere else, the allocation of the data
word for that interface is known to die before the call returns and
thus can be stack allocated.
One tricky case is that although the allocation of the backing store
of the interface conversion doesn't escape, pointers we store *inside*
that allocation might escape (in fact they definitely will, unless we
can devirtualize the receiver).
Fixes#50182
Change-Id: I40e893955c2e6871c54ccecf1b9f0cae17871b0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/378178
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
