When unifying two types A and B where one or both of them are
interfaces, consider the shared method signatures in unification.
1) If a defined interface (an interface with a type name) is unified
with another (defined) interface, currently they must originate
in the same type declaration (same origin) for unification to
succeed. This is more restrictive than necessary for assignments:
when interfaces are assigned to each other, corresponding methods
must match, but the interfaces don't have to be identical.
In unification, we don't know which direction the assignment is
happening (or if we have an assignment in the first place), but
in any case one interface must implement the other. Thus, we
check that one interface has a subset of the methods of the other
and that corresponding method signatures unify.
The assignment or instantiation may still not be possible but that
will be checked when instantiation and parameter passing is checked.
If two interfaces are compared as part of another type during
unification, the types must be equal. If they are not, unifying
a method subset may still succeed (and possibly produce more type
arguments), but that is ok: again, subsequent instantiation and
assignment will fail if the types are indeed not identical.
2) In a non-interface type is unified with an interface, currently
unification fails. If this unification is a consequence of an
assignment (parameter passing), this is again too restrictive:
the non-interface type must only implement the interface (possibly
among other type set requirements). In any case, all methods of the
interface type must be present in the non-interface type and unify
with the corresponding interface methods. If they don't, unification
will fail either way. If they do, we may infer additional type
arguments. Again, the resulting types may still not be correct but
that will be determined by the instantiation and parameter passing
or assignment checks. If the non-interface type and the interface
type appear as component of another type, unification may now
produce additional type arguments. But that is again ok because the
respective types won't pass instantiation or assignment checks since
they are different types.
This CL introduces a new unifier flag, enableInterfaceInference, to
enable this new behavior. It is currently disabled.
For #60353.
For #41176.
For #57192.
Change-Id: I983d0ad5f043c7fe9d377dbb95f6b9342f36f45f
Reviewed-on: https://go-review.googlesource.com/c/go/+/497656
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This relocation is not (yet?) defined in ELFv2, but has been added to
gnu gas a couple years ago. It is the same reloc as
R_PPC64_REL24_NOTOC, but hints power10 instructions should not be
emitted.
See binutils commit 7aba54da426b9999085d8f84e7896b8afdbb9ca6.
Fixes#60348
Change-Id: Ie953cd7bf1ffc621b498d4dbebb5de1231833c8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/496918
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently the pinner is created outside of the benchmarking loop.
However, this means that we get to reuse the same pinner for each loop;
in general, users are expected to create a pinner for a e.g. a cgo
call and then that variable will expire with the frame it lives in. (If
they can reuse the variable, great! However, I don't expect that to be
common.)
In essence, this benchmarks a harder case. It's not more right or wrong
than the previous version, but the fact that it's a slightly harder case
(that still mostly captures what the original version was capturing) is
useful.
Change-Id: I94987127f54d7bfecd7b8e6a5e632631ea57ad24
Reviewed-on: https://go-review.googlesource.com/c/go/+/497616
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
When unifying two types A and B where one or both of them are
interfaces, consider the shared method signatures in unification.
1) If a defined interface (an interface with a type name) is unified
with another (defined) interface, currently they must originate
in the same type declaration (same origin) for unification to
succeed. This is more restrictive than necessary for assignments:
when interfaces are assigned to each other, corresponding methods
must match, but the interfaces don't have to be identical.
In unification, we don't know which direction the assignment is
happening (or if we have an assignment in the first place), but
in any case one interface must implement the other. Thus, we
check that one interface has a subset of the methods of the other
and that corresponding method signatures unify.
The assignment or instantiation may still not be possible but that
will be checked when instantiation and parameter passing is checked.
If two interfaces are compared as part of another type during
unification, the types must be equal. If they are not, unifying
a method subset may still succeed (and possibly produce more type
arguments), but that is ok: again, subsequent instantiation and
assignment will fail if the types are indeed not identical.
2) In a non-interface type is unified with an interface, currently
unification fails. If this unification is a consequence of an
assignment (parameter passing), this is again too restrictive:
the non-interface type must only implement the interface (possibly
among other type set requirements). In any case, all methods of the
interface type must be present in the non-interface type and unify
with the corresponding interface methods. If they don't, unification
will fail either way. If they do, we may infer additional type
arguments. Again, the resulting types may still not be correct but
that will be determined by the instantiation and parameter passing
or assignment checks. If the non-interface type and the interface
type appear as component of another type, unification may now
produce additional type arguments. But that is again ok because the
respective types won't pass instantiation or assignment checks since
they are different types.
This CL introduces a new Config flag, EnableInterfaceInference, to
enable this new behavior. If not set, unification remains unchanged.
To be able to test the flag durign unification, a *Checker is passed
and stored with the unifier.
For #60353.
Fixes#41176.
Fixes#57192.
Change-Id: I6b167a9afa378d0682e9b101d9d86f5777308af7
Reviewed-on: https://go-review.googlesource.com/c/go/+/497015
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>
b.ResetTimer used to also stop the timer, however it does not anymore.
These benchmarks hadn't been fixed and as a result ended up measuring
some additional things.
Also, make some for loops more conventional.
Change-Id: I76ca68456d85eec51722a80587e5b2c9f5d836a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/496996
Run-TryBot: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Change-Id: I8a903b76d80f451b498b145b14c97f96191e05f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/486775
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: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#10275
Change-Id: I2b3d54f3eb0f85d65324ddc3c3b2a797d42a16c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/496537
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 494915 introduced an additional fcntl(F_GETFL) syscall to determine
whether the file is in append-only mode. The existing unix.IsNonblock
call also issues an fcntl(F_GETFL) syscall. The two can be combined and
both the append-only mode and the non-blocking flags can be determined
from that syscall's result.
Change-Id: I915589ed94e079f6abaa2fd0032ef01f78698f7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/497075
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
These are only needed on aix and darwin.
Change-Id: Iea67e4631197359f2bec346ef7d7b723ca23646e
Reviewed-on: https://go-review.googlesource.com/c/go/+/497076
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In order to have some test coverage of concurrent use of the go/types
APIs, update the Stdlib test to type-check concurrently. In combination
with non-deterministic ordering, this should hopefully provide moderate
test coverage of concurrent use.
Also, remove the arbitrary 10ms timeout in short mode, in favor of
simply not running.
After this change, TestStdlib went from taking 16s on my laptop to 2s,
in part because of the parallelism and in part because we are no longer
type-checking twice (once for the import er, once for the test).
Fixesgolang/go#47729
Change-Id: Ie49743947ab2d5aec051c3d09ce045acf5b94ad4
Reviewed-on: https://go-review.googlesource.com/c/go/+/484540
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Change-Id: I6c9a8decb5b261be4548f148739b44e8860c5f8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/497595
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Currently the CPU stats are only updated once every mark termination,
but for writing robust tests, it's often useful to force this update.
Refactor the CPU stats accumulation out of gcMarkTermination and into
its own function. This is also a step toward real-time CPU stats.
While we're here, fix some incorrect documentation about dedicated GC
CPU time.
For #59749.
For #60276.
Change-Id: I8c1a9aca45fcce6ce7999702ae4e082853a69711
Reviewed-on: https://go-review.googlesource.com/c/go/+/487215
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently pidleget gets passed "now" from before the M goes into
netpoll, resulting in incorrect accounting of idle CPU time.
lastpoll is also stored with a stale "now": the mistake was added in the
same CL it was added for pidleget.
Recompute "now" after returning from netpoll.
Also, start tracking idle time on js/wasm at all.
Credit to Rhys Hiltner for the test case.
Fixes#60276.
Change-Id: I5dd677471f74c915dfcf3d01621430876c3ff307
Reviewed-on: https://go-review.googlesource.com/c/go/+/496183
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 466099 rewrote stack symbolization in race reports. Prior to this
CL, physical frames consisting entirely of wrapper logical frame would
print the wrapper, even though in other cases we try to avoid
printing wrappers. CL 466099 unintentionally changed this behavior and
now physical frames consisting entirely of wrapper frames instead fail
to symbolize and print "??()".
Fix this by taking the outermost wrapper frame if the entire logical
frame expansion consists of wrappers.
Fixes#60245.
Change-Id: I13de8857e508b757ea10d1fc7a47258d7fddbfdb
Reviewed-on: https://go-review.googlesource.com/c/go/+/497235
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
For #56857
Change-Id: I0622af974783ab435e91b9fb3c1ba43f256ee4ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/497315
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This sets up for introducing the 'go' and 'toolchain' modules
but should be a no-op by itself.
For #57001.
Change-Id: I2e02b5d417f1edd4f4653b101e4975fe23093f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/497456
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Now that cfg.CanGetenv does the right thing, we don't need a separate
readEnvFile in 'go env'.
Change-Id: I187c8615ad074ba132516bcf499f82877a32d5e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/497457
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
As part of the work for #57179 we moved configurable defaults
to GOROOT/go.env, so that packagers don't have to modify
source code to change those defaults. Since packagers may want
to modify GOTOOLCHAIN's default, move it to go.env too.
This CL modifies 'go env' to print GOTOOLCHAIN by default.
It also refines CL 496957 from yesterday to recognize any env
var in either go.env or the user go/env, not just the user go/env.
When I put GOTOOLCHAIN in go.env, but before I added it to
the default printing list, 'go env GOTOOLCHAIN' was printing
an empty string, and it was incredibly confusing.
For #57001.
Fixes#60361 while we're here.
Also includes a fix for a review comment on CL 497079 that I forgot to mail.
Change-Id: I7b904d9202f05af789aaa33aed93f903b515aa28
Reviewed-on: https://go-review.googlesource.com/c/go/+/497437
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
CL 493275 started using gcBits for pinner bits. This means gcBits can be
allocated while holding the mspanSpecial lock. This is safe because
these were just parallel in the partial order, but now they need an
explicit edge between them.
For #58277.
Change-Id: I37917730e12d59cf0580f198d732198413a56424
Reviewed-on: https://go-review.googlesource.com/c/go/+/497475
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reapples CL 495596, which was reverted at CL 496185. The x/tools
failure, #60263, has been resolved. The ppc64 failures, #60368, have
_not_ been resolved, but are believed to be specific to that port. This
CL will make ppc64 flaky while the issue is investigated, but give more
soak time on primary ports.
Build the compiler with PGO. As go build -pgo=auto is enabled by
default, we just need to store a profile in the compiler's
directory.
The profile is collected from building all std and cmd packages on
Linux/AMD64 machine, using profile.sh.
This improves the compiler speed. On Linux/AMD64,
name old time/op new time/op delta
Template 138ms ± 5% 136ms ± 4% -1.44% (p=0.005 n=36+39)
Unicode 147ms ± 4% 140ms ± 4% -4.99% (p=0.000 n=40+39)
GoTypes 780ms ± 3% 778ms ± 4% ~ (p=0.172 n=39+39)
Compiler 105ms ± 5% 99ms ± 7% -5.64% (p=0.000 n=40+40)
SSA 5.83s ± 6% 5.80s ± 6% ~ (p=0.556 n=40+40)
Flate 89.0ms ± 5% 87.0ms ± 6% -2.18% (p=0.000 n=40+40)
GoParser 172ms ± 4% 167ms ± 4% -2.72% (p=0.000 n=39+40)
Reflect 333ms ± 4% 333ms ± 3% ~ (p=0.426 n=40+39)
Tar 128ms ± 4% 126ms ± 4% -1.82% (p=0.000 n=39+39)
XML 173ms ± 4% 170ms ± 4% -1.39% (p=0.000 n=39+40)
[Geo mean] 253ms 248ms -2.13%
The profile is pretty transferable. Using the same profile, we
see a bigger win on Darwin/ARM64,
name old time/op new time/op delta
Template 71.0ms ± 2% 68.3ms ± 2% -3.90% (p=0.000 n=20+20)
Unicode 71.8ms ± 2% 66.8ms ± 2% -6.90% (p=0.000 n=20+20)
GoTypes 444ms ± 1% 428ms ± 1% -3.53% (p=0.000 n=19+20)
Compiler 48.9ms ± 3% 45.6ms ± 3% -6.81% (p=0.000 n=20+20)
SSA 3.25s ± 2% 3.09s ± 1% -5.03% (p=0.000 n=19+20)
Flate 44.0ms ± 2% 42.3ms ± 2% -3.72% (p=0.000 n=19+20)
GoParser 76.7ms ± 1% 73.5ms ± 1% -4.15% (p=0.000 n=18+19)
Reflect 172ms ± 1% 165ms ± 1% -4.13% (p=0.000 n=20+19)
Tar 63.1ms ± 1% 60.4ms ± 2% -4.24% (p=0.000 n=19+20)
XML 83.2ms ± 2% 79.2ms ± 2% -4.79% (p=0.000 n=20+20)
[Geo mean] 127ms 121ms -4.73%
For #60368.
Change-Id: I2cec0fc85e21c38d57ba6f0e5e90cde5d443ebd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/497455
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This includes release notes for several small runtime changes, including
runtime/trace and runtime package changes.
For #58645.
Change-Id: I3e9c804da1bb6b385088e16a20d9576c11098021
Reviewed-on: https://go-review.googlesource.com/c/go/+/497095
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ansiwen <ansiwen@gmail.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Updates the DecryptPKCS1v15SessionKey function comment to be less cut
and dry about its protections against Bleichenbacher attacks. In
particular note that the protocol using this method must be explicitly
designed with these mitigations in mind, and call out usages which
may cause the migiations to be useless.
Change-Id: I06fd25157f12a3afb401bb08dff4faef7fb0a9b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/469235
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
CL 415241 and CL 411935 break tests into unified/nounified variants, for
compatibility with old frontend while developing unified IR. Now the old
frontend was gone, so moving those tests back to the original files.
Change-Id: Iecdcd4e6ee33c723f6ac02189b0be26248e15f0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/497275
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
We already refuse to build code in modules are too new (CL 476279).
This is a more comprehensive check: refuse to do anything at all with
modules or workspaces that are too new.
Since the module or workspace is new, it may have semantics we don't
understand and misinterpret well before we get to the actual building of code.
For example when we switched from // +build to //go:build that changed
the decision about which files go into a package, which affects the way
the overall load phase runs and which errors it reports. Waiting until the
building of code would miss earlier changes like that one.
Leaving the test from CL 476279 alone, but it's not load-bearing anymore.
For #57001.
Change-Id: I8c39943db1d7ddbcb9b5cae68d80459fddd68151
Reviewed-on: https://go-review.googlesource.com/c/go/+/497435
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
If a hash match is "disabled" (!enabled) indicate that in the
output with DISABLED. This is helpful in ensuring that multiple
package-directed command-line flags have the intended behavior,
e.g.
```
go build -a \
-gcflags=all=-d=gossahash=vn \
-gcflags=runtime=-d=gossahash=vy \
std
```
Output looks like
[DISABLED] [bisect-match 0x11d0ee166d9d61b4]
or (w/ "v"-prefixed hashcode )
sort/slice.go:23:29 note [DISABLED] [bisect-match 0xa5252e1c1b85f2ec]
gossahash triggered sort/slice.go:23:29 note [DISABLED] 100001011111001011101100
Change-Id: I797e02b3132f9781d97bacd0dcd2e80af0035cd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497216
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test is failing on the nocgo builder.
Change-Id: I9426ce77907956e4654fd437ad20e3af664e83ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/497436
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
To make the new go lines work with 'go get' as minimum requirements,
this CL creates a synthetic 'go' module that has as its versions the valid
versions that can be listed on the 'go' line.
In preparation for allowing 'toolchain' changes as well, an equivalent
synthetic module is introduced for 'toolchain'.
For #57001.
Change-Id: Id0ebbd283f0f991859d516d21dffe59a834db540
Reviewed-on: https://go-review.googlesource.com/c/go/+/497080
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
go install m@v and go run m@v are the only commands
that ignore the local go.mod. As such they need to use a
different signal to find the Go version, namely the m@v go.mod.
Because there is no way to predict that Go version (no equivalent
of "go version" for interrogating the local go.mod), if we do switch
toolchains we always print about it.
For #57001.
Change-Id: I981a0b8fa61992b353589355ba72a3b9d55914e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/497079
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Some custom toolchain builds add extra suffixes to the version.
Strip those off (cutting at - or +) to find the underlying Go version.
For #57001.
Change-Id: I234fb2d069aaf0922c0a2c848e4a4c38e4adf9bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/497415
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Clean up Go version comparison.
CL 494436 added an ad hoc version comparison for the toolchain switch.
There are also other version comparisons scattered throughout the code,
assuming that using semver.Compare with a "v" prefix gives the right answer.
As we start to allow versions like "go 1.21rc1" in the go.mod file,
those comparisons will not work properly.
A future CL will need to inject Go versions into semver for use with MVS,
so do what Bryan suggested in the review of CL 494436 and rewrite the
comparison in terms of that conversion.
For #57001.
Change-Id: Ia1d441f1bc259874c6c1b3b9349bdf9823a707d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/496735
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Since Linux 3.18, support for madvise is optional, depending on
the setting of the CONFIG_ADVISE_SYSCALLS configuration option.
The Go runtime currently assumes in several places that we
do not unmap heap memory; that needs to remain true. So, if
madvise is unsupported, we cannot fall back on munmap. AFAIK,
the only way to free the pages is to remap the memory region.
For the x86, the system call mmap() is implemented by sys_mmap2()
which calls do_mmap2() directly with the same parameters. The main
call trace for
mmap(v, n, PROT_READ|PROT_WRITE, MAP_ANON|MAP_FIXED|MAP_PRIVATE, -1, 0)
is as follows:
```
do_mmap2()
\- do_mmap_pgoff()
\- get_unmapped_area()
\- find_vma_prepare()
// If a VMA was found and it is part of the new mmaping, remove
// the old mapping as the new one will cover both.
// Unmap all the pages in the region to be unmapped.
\- do_munmap()
// Allocate a VMA from the slab allocator.
\- kmem_cache_alloc()
// Link in the new vm_area_struct.
\- vma_link()
```
So, it's safe to fall back on mmap().
See D.2 https://www.kernel.org/doc/gorman/html/understand/understand021.html
Change-Id: Ia2b4234bc0bf8a4631a9926364598854618fe270
GitHub-Last-Rev: 179f047154
GitHub-Pull-Request: golang/go#60218
Reviewed-on: https://go-review.googlesource.com/c/go/+/495081
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
With this change a Pinner preallocates an array of 5 pointers for
references to pinned objects. This reduces allocations when a pinner
is reused with up to 5 pinned objects.
This is a follow-up to CL 367296.
Signed-off-by: Sven Anderson <sven@anderson.de>
Change-Id: Ibea0b9ee4d7e39b0341a1da9d8276a4283e4956d
Reviewed-on: https://go-review.googlesource.com/c/go/+/496275
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: 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>
When associating methods with their receiver base, we need to implement
the same indirection through Cgo types as is done for selector
expressions. This fixes a bug where methods declared on aliases of Cgo
types were not associated with their receiver.
While porting to types2, align the types2 testFiles helper with the
go/types implementation. In order to avoid call-site bloat, switch to an
options pattern for configuring the Config used to type-check.
Fixesgolang/go#59944
Change-Id: Id14101f01c122b6c856ae5453bd00ec07e83f414
Reviewed-on: https://go-review.googlesource.com/c/go/+/493877
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This patch revives the testing.Coverage() function, which takes a
snapshot of the coverage counters within an executing "go test -cover"
test binary and returns a percentage approximating the percent of
statements covered so far.
Fixes#59590.
Change-Id: I541d47a42d71c8fb2edc473d86c8951fa80f4ab0
Reviewed-on: https://go-review.googlesource.com/c/go/+/495450
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Enhance the functions called by _testmain.go during "go test -cover"
test binary runs to allow for injection of extra or "auxiliary"
meta-data files when reporting coverage statistics. There are unit
tests for this functionality, but it is not yet wired up to be used by
the Go command yet, that will appear in a subsequent patch.
Change-Id: I10b79ca003fd7a875727dc1a86f23f58d6bf630c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495451
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Add a new function runtime/coverage.snapshot(), which samples the
current values of coverage counters in a running "go test -cover"
binary and returns percentage of statements executed so far. This
function is intended to be used by the function testing.Coverage().
Updates #59590.
Change-Id: I861393701c0cef47b4980aec14331168a9e64e8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/495449
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Add a flag to EmitPercent indicating to emit a single line percent
summary across all packages as opposed to a line per package. We need
to set this flag when reporting as part of a "go test -cover" run, but
false when reporting as part of a "go tool covdata percent" run.
Change-Id: Iba6a81b9ae27e3a5aaf9d0e46c0023c0e7ceae16
Reviewed-on: https://go-review.googlesource.com/c/go/+/495448
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Include some additional whitepace when emitting percentage of
statements covered per package, to make "go tool covdata percent"
output more like "go test -cover" output.
Change-Id: I450cf2bfa05b1eed747cb2f99967314419fa446c
Reviewed-on: https://go-review.googlesource.com/c/go/+/495445
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
