If a generic type declaration is missing a constraint, syntactically
it is an array type declaration with an undefined array length.
Mention the possibility of a missing constraint in the error message
for the undefined array length.
For #56064.
For #55961.
For #51145.
Change-Id: Ic161aeda9ea44faa8aa3bf3e9d62b3b13a95d4c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/439559
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Add "-O2" to all compiler/linker tests. This makes compiler/linker
feature probing better resemble actual compiling later.
Why?
----
zig c++ is a clang front-end[1] that accepts, among other things, the
target over the command line. This command:
zig c++ -target x86_64-linux-gnu main.o -o main
Will:
1. Pre-compile libc++.a.
2. Link the program with libc++.a from (1).
Currently Go only is learning about one flag from the linker, that is,
"--no-gc-sections". The resulting command that tests for the flag
support is this:
c++ -Wl,--no-gc-sections -x c - -o
This causes Zig to pre-compile libc++.a in debug mode. Then the actual
compiler+linker command from CGo adds a few more flags, including "-O2":
c++ <...> -Wl,--no-gc-sections -O2 <...>
From Zig perspective, debug-mode libc++.a is different from the
optimized one; that causes Zig to compile a new libc++.a. Specifically,
Zig adds "-fno-omit-frame-pointer" for debug builds, and
"-fomit-frame-pointer" for optimized builds.
As a result, we have to two sets of libc++.a for every arch/os tuple.
That takes CPU time and a bit of disk space.
Zig performance impact
----------------------
First compilation of a simple CGo application is faster by ~2.5 seconds
or ~60%:
$ CC="zig c++ -target x86_64-linux-gnu.2.28" hyperfine \
--warmup 3 --runs 10 \
--prepare 'rm -fr ~/.cache/zig ~/.cache/go-build /tmp/go-*' \
--parameter-list go go1.19,go1.19-O2 \
'/code/go/bin/{go} build .'
Benchmark 1: /code/go/bin/go1.19 build .
Time (mean ± σ): 6.168 s ± 0.059 s [User: 7.465 s, System: 1.578 s]
Range (min … max): 6.111 s … 6.242 s 10 runs
Benchmark 2: /code/go/bin/go1.19-O2 build .
Time (mean ± σ): 3.816 s ± 0.080 s [User: 4.730 s, System: 1.130 s]
Range (min … max): 3.657 s … 3.958 s 10 runs
Summary
'/code/go/bin/go1.19-O2 build .' ran
1.62 ± 0.04 times faster than '/code/go/bin/go1.19 build .'
If we add C++ to the mix, the difference grows to almost ~23 seconds, or
almost 90%:
$ CC="zig c++ -target x86_64-linux-gnu.2.28" hyperfine \
--warmup 1 --runs 3 \
--prepare 'rm -fr ~/.cache/zig ~/.cache/go-build /tmp/go-*' \
--parameter-list go go1.19,go1.19-O2 \
'/code/go/bin/{go} build .'
Benchmark 1: CC="zig c++ -target x86_64-linux-gnu.2.28" /code/go/bin/go1.19 build .
Time (mean ± σ): 51.137 s ± 0.183 s [User: 234.165 s, System: 15.005 s]
Range (min … max): 50.934 s … 51.288 s 3 runs
Benchmark 2: CC="zig c++ -target x86_64-linux-gnu.2.28" /code/go/bin/go1.19-O2 build .
Time (mean ± σ): 27.102 s ± 0.068 s [User: 119.816 s, System: 8.513 s]
Range (min … max): 27.038 s … 27.174 s 3 runs
Summary
'/code/go/bin/go1.19-O2 build .' ran
1.89 ± 0.01 times faster than '/code/go/bin/go1.19 build .'
The difference is just due to the fact that Zig will not be instructed
to compile libc++.a for debug builds; Go doesn't need that.
Non-Zig performance impact
--------------------------
A.k.a. does "-O2" for this check worsen performance?
No statistically significant performance differences with both clang-15
and gcc-11. Also, it affects only the first compile of a CGo progam, as
the linker tests are cached across invocations. go1.19 binary is the
go1.19 tag; go1.19-O2 is go1.19 + this patch.
$ hyperfine --warmup 3 --runs 20 \
--prepare 'rm -fr ~/.cache/go-build/ /tmp/go-*' \
--parameter-list go go1.19,go1.19-O2 \
--parameter-list cc gcc-11,clang-15 \
'CC={cc} /code/go/bin/{go} build .'
Benchmark 1: CC=gcc-11 /code/go/bin/go1.19 build .
Time (mean ± σ): 681.1 ms ± 13.7 ms [User: 501.6 ms, System: 247.1 ms]
Range (min … max): 654.1 ms … 707.2 ms 20 runs
Benchmark 2: CC=gcc-11 /code/go/bin/go1.19-O2 build .
Time (mean ± σ): 676.8 ms ± 10.2 ms [User: 500.4 ms, System: 245.6 ms]
Range (min … max): 664.4 ms … 696.4 ms 20 runs
Benchmark 3: CC=clang-15 /code/go/bin/go1.19 build .
Time (mean ± σ): 860.1 ms ± 17.1 ms [User: 530.0 ms, System: 394.9 ms]
Range (min … max): 839.4 ms … 920.0 ms 20 runs
Benchmark 4: CC=clang-15 /code/go/bin/go1.19-O2 build .
Time (mean ± σ): 864.5 ms ± 26.6 ms [User: 537.8 ms, System: 390.1 ms]
Range (min … max): 841.9 ms … 955.5 ms 20 runs
Summary
'CC=gcc-11 /code/go/bin/go1.19-O2 build .' ran
1.01 ± 0.03 times faster than 'CC=gcc-11 /code/go/bin/go1.19 build .'
1.27 ± 0.03 times faster than 'CC=clang-15 /code/go/bin/go1.19 build .'
1.28 ± 0.04 times faster than 'CC=clang-15 /code/go/bin/go1.19-O2 build .'
cgo.go
------
package main
// #define _FILE_OFFSET_BITS 64
// #include <unistd.h>
// #include <fcntl.h>
// #include <stdio.h>
// char* hello() { return "hello, world"; }
// void phello() { printf("%s, your lucky number is %p\n", hello(), fcntl); }
import "C"
func main() {
C.phello()
}
func Chello() string {
return C.GoString(C.hello())
}
Alternatives considered
-----------------------
There are a few alternatives:
1. Add "-O2" for linker-only tests. That looks like too much catering to
zig alone. If we can add it, then add for everything.
2. Add "-fomit-frame-pointer" instead of "-O2". This flag does not
universally imply debug mode, thus same argument applies as to (1).
3. Add "-O2" for this particular test (`--no-gc-sections`). This is
brittle and not future-proof: a future linker test may omit this
flag.
Hardware
--------
Tested on a 4-core (8 HT) Intel(R) Core(TM) i7-8665U CPU on Debian 11,
Linux 5.10.0-15-amd64.
[1]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html
Change-Id: I5223a5cf53fc5d2b77ac94a6c5712c32c7fbdf36
GitHub-Last-Rev: 2e998b831a
GitHub-Pull-Request: golang/go#55966
Reviewed-on: https://go-review.googlesource.com/c/go/+/436884
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run "go build ./x" in this workspace:
-- go.work --
use ./y
-- x/go.mod --
module x
go 1.19
-- x/m.go --
package m
It fails with: "go: open /tmp/foo/y/go.mod: no such file or directory".
It's unclear where the name "y" comes from.
This change will emit error like: "go: cannot load module listed in
go.work file: open /tmp/foo/y/go.mod: no such file or directory"
Fixes#55952.
Change-Id: Ia45dd915e3fbd6e33340f352b3d6235c6c31190b
GitHub-Last-Rev: 410de1b4a7
GitHub-Pull-Request: golang/go#56050
Reviewed-on: https://go-review.googlesource.com/c/go/+/438147
Run-TryBot: hopehook <hopehook@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
This permits us to safely support concurrent access to files on Plan 9.
Concurrent access was already safe on other systems.
This does introduce a change: if one goroutine calls a blocking read
on a pipe, and another goroutine closes the pipe, then before this CL
the close would occur. Now the close will be delayed until the blocking
read completes.
Also add tests that concurrent I/O and Close on a pipe are OK.
For #50436
For #56043
Change-Id: I969c869ea3b8c5c2f2ef319e441a56a3c64e7bf5
Reviewed-on: https://go-review.googlesource.com/c/go/+/438347
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
An older version of go compiling a main module that references a
standard library package from a newer release (e.g. net/netip added in
go 1.18) currently produces a confusing error message. This changes adds
a new error message including go version diagnostics.
Fixes#48966
Change-Id: I1e8319dafcf1f67d1b1ca869fe84190c3b3f3c3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/432075
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>
With moduleHasRootPackage eliminated in the previous CL, needSum is
now invariantly true at all call sites.
Change-Id: I00e44117e545ea0d3de82604dfa018b013ab8f0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/440296
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This change moves Linux epoll's syscalls implementation to the
"runtime/internal/syscall" package. The intention in this CL was to
minimise behavioural changes but make the code more generalised. This
also will allow adding new syscalls (like epoll_pwait2) without the
need to implement assembly stubs for each arch.
It also drops epoll_create as not all architectures provide this call.
epoll_create1 was added to the kernel in version 2.6.27 and Go requires
Linux kernel version 2.6.32 or later since Go 1.18. So it is safe to
always use epoll_create1.
This is a resubmit as the previous CL 421994 was reverted due to test
failures after the merge with the master. The issue was fixed in
CL 438615
For #53824
For #51087
Change-Id: I1bd0f23a85b4f9b80178c5dd36fd3e95ff4f9648
Reviewed-on: https://go-review.googlesource.com/c/go/+/440115
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
AddrFromSlice is not covered by any other test so far.
Change-Id: I91034c6cac95a023fc419c855873a395b1afdab7
Reviewed-on: https://go-review.googlesource.com/c/go/+/435916
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
This commit was dedicated to adding an example of using B.ReportMetrics
with B.RunParallel called ExampleB_ReportMetric_parallel. In this
example, the same algorithm for ExampleB_ReportMetric was used, instead
with a concurrent for loop using PB.Next instead of a standard one.
There is also notes noting when to use the B.ReportMetric methods when
running concurrent testing.
Fixes#50756
Change-Id: I2a621b4e367af5f4ec47d38a0da1035a8d52f628
Reviewed-on: https://go-review.googlesource.com/c/go/+/437815
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Replace the ad-hoc approach to running tests in HTTP/1 and HTTP/2
modes with a 'run' function that executes a test in various modes.
By default, these modes are HTTP/1 and HTTP/2, but tests can
opt-in to HTTPS/1 as well.
The 'run' function also takes care of post-test cleanup (running the
afterTest function).
The 'run' function runs tests in parallel by default. Tests which
can't run in parallel (generally because they use global test hooks)
pass a testNotParallel option to disable parallelism.
Update clientServerTest to use t.Cleanup to clean up after itself,
rather than leaving this up to tests to handle.
Drop an unnecessary mutex in SetReadLoopBeforeNextReadHook.
Test hooks can't be set in parallel, and we want the race detector
to notify us if two simultaneous tests try to set a hook.
Fixes#56032
Change-Id: I16be64913c426fc93d84abc6ad85dbd3bc191224
Reviewed-on: https://go-review.googlesource.com/c/go/+/438137
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Move the writev definition for solaris from package
internal/syscall/unix to package syscall. This corresponds to where
writev is defined on aix, darwin and openbsd as well and is
go:linkname'ed from internal/poll. This also allows updating the
generated wrappers more easily if needed.
Change-Id: I671ed8232d25319f8e63f549f786d77a17602148
Reviewed-on: https://go-review.googlesource.com/c/go/+/436597
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Wait or Run will populate its ProcessState when the command completes.
Fixes#56002.
Change-Id: I21547431f5d2d3e0fc0734fd1705421a0ac4209c
Reviewed-on: https://go-review.googlesource.com/c/go/+/437996
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
egrep and fgrep are obsolescent now.
This PR updates all egrep and fgrep commands to grep -E and grep -F.
Running egrep/fgrep command with grep v3.8 will output the following warning to stderr:
egrep: warning: egrep is obsolescent; using grep -E
see also:
https://www.phoronix.com/news/GNU-Grep-3.8-Stop-egrep-fgrephttps://lists.gnu.org/archive/html/info-gnu/2022-09/msg00001.html
Change-Id: Iea1ca9ae72264530c67727b5e27cf1b7a362dd97
GitHub-Last-Rev: 3584884bd4
GitHub-Pull-Request: golang/go#55299
Reviewed-on: https://go-review.googlesource.com/c/go/+/432256
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This cuts the wall duration for 'go test os/exec' and
'go test -race os/exec' roughly in half on my machine,
which is an even more significant speedup with a high '-count'.
For better or for worse, it may also increase the repro rate
of #34988.
Tests that use Setenv or Chdir or check for FDs opened during the test
still cannot be parallelized, but they are only a few of those.
Change-Id: I8d284d8bff05787853f825ef144aeb7a4126847f
Reviewed-on: https://go-review.googlesource.com/c/go/+/439196
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>
This test has been disabled for over nine years (since CL 12869049).
Although it still compiles, it seems likely to have rotted since then,
and if it was going to detect a real bug it also seems like that bug
would have been encountered and reported by users since then (and
would presumably have its own regression tests).
To eliminate overhead from mainining it (or skipping over it while
maintaining other tests), let's just delete it.
Fixes#5780.
Change-Id: I2a85cba20cba98a1dc6fc82336ae5e22d2242e99
Reviewed-on: https://go-review.googlesource.com/c/go/+/439197
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In practice this only shows up when a vendored package, imported on the
command line, imports an internal package.
Change-Id: I34c161d1f1ef15a87c58a422f17d11f77fbac53f
Reviewed-on: https://go-review.googlesource.com/c/go/+/439735
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
When it calculates the smallest n such that:
n >= i && n % buildInfoAlign == 0
the expression should be
(i+buildInfoAlign-1)&^(buildInfoAlign-1)
instead of
(i+buildInfoAlign-1)&^buildInfoAlign
Fixes#54968.
Change-Id: Ibb7bdf568a521545b2609acc85e2ab4e05da5dae
GitHub-Last-Rev: 479ebc140a
GitHub-Pull-Request: golang/go#54971
Reviewed-on: https://go-review.googlesource.com/c/go/+/429815
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: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
For example:
movb a0, a0
srai $1, a0, a0
the assembler will expand to:
slli $56, a0, a0
srai $56, a0, a0
srai $1, a0, a0
this CL optimize to:
slli $56, a0, a0
srai $57, a0, a0
Remove 270+ instructions from Go binary on linux/riscv64.
Change-Id: I375e19f9d3bd54f2781791d8cbe5970191297dc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/428496
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I375233dc700adbc58a6d4af995d07b352bf85b11
GitHub-Last-Rev: ef12920523
GitHub-Pull-Request: golang/go#55994
Reviewed-on: https://go-review.googlesource.com/c/go/+/437715
Run-TryBot: Ian Lance Taylor <iant@google.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: Keith Randall <khr@google.com>
This fixes a bug introduced by CL 426094 that caused the
golang.org/x/website/internal/web tests to fail.
Fixes#56034
Change-Id: Ic64967c6d440ad260b7283a18972b20023320ab6
Reviewed-on: https://go-review.googlesource.com/c/go/+/437976
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: I6be77e7b7c919f26bed7b6690cce6741888ba78a
GitHub-Last-Rev: 4ef4a7b425
GitHub-Pull-Request: golang/go#56051
Reviewed-on: https://go-review.googlesource.com/c/go/+/438991
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@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>
Set a 1MiB limit on special file blocks (PAX headers, GNU long names,
GNU link names), to avoid reading arbitrarily large amounts of data
into memory.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting
this issue.
Fixes CVE-2022-2879
For #54853
Change-Id: I85136d6ff1e0af101a112190e027987ab4335680
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1565555
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/439355
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Set a 128 MB limit on the amount of space used by []syntax.Inst
in the compiled form corresponding to a given regexp.
Also set a 128 MB limit on the rune storage in the *syntax.Regexp
tree itself.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue.
Fixes CVE-2022-41715.
Fixes#55949.
Change-Id: Ia656baed81564436368cf950e1c5409752f28e1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/439356
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
We were saving non-go file information in the module index files,
leading in an unnecessary increase in memory usage in modules
containing many non-go files. This was a bug because this information
is never used. Don't save that information.
For #54226
Change-Id: I0644064f83f96e3a9f43b7e66ca94d69d9603376
Reviewed-on: https://go-review.googlesource.com/c/go/+/439118
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Use shorter more Go-like names for the new APIs being added in the
runtime/coverage package for writing coverage data under user control
from server programs. Old names were a bit too clunky/verbose.
Updates #51430.
Change-Id: Ifdd5b882a88613c7c4342b40ed93b58547483c77
Reviewed-on: https://go-review.googlesource.com/c/go/+/438503
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The traceback code has special "jump stack" logic, to trace back
stack switches through systemstack. If we're at the entry of
systemstack, the stack switch hasn't happened, so don't jump to
user stack.
The jump stack logic is only used if we're on the g0 stack. It can
happen that we're at the entry of a recursive systemstack call on
the g0 stack. In we jump stack here, there will be two problems:
1. There are frames between entering the g0 stack and this
recursive systemstack call. Those frames will be lost.
2. Worse, we switched frame.sp but frame.fp calculation will use
the entry SP delta (0), which will be wrong, which in turn
leads wrong frame.lr and things will go off.
For now, don't jump stack if we're at entry of systemstack (SP
delta is 0).
Using a per-PC SPWRITE marker may be a better fix. If we haven't
written the SP, we haven't switched the stack so we can just
unwind like a normal function.
May fix#55851.
Change-Id: I2b624c8c086b235b34d9c7d3cebd4a37264f00f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/437299
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
On Mac OS X, the default stack size for non-main threads created by cgo is
fixed at 512KB and cannot be altered by setrlimit. This stack size is too
small for some recursive scenarios. We can solve this problem by explicitly
copying the stack size of the main thread when creating a new thread.
Change-Id: I400d5b2e929a1ee261502914a991e208759f64a8
GitHub-Last-Rev: b29c74599e
GitHub-Pull-Request: golang/go#53667
Reviewed-on: https://go-review.googlesource.com/c/go/+/415915
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: hopehook <hopehook@golangcn.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Indirect branches are much more expensive than direct. If the call is
known to be local, we can replace most of the operations with a nop,
and call directly.
Updates #53345
Change-Id: Icfff9ec1f6c7f8e4181f0f28976033308d2f53eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/412715
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also make error recovery slightly more robust in this case.
Fixes#56022.
Change-Id: I1c01c1465adb48c71367d037b6f0e3fe56f68ec9
Reviewed-on: https://go-review.googlesource.com/c/go/+/438540
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>
TryBot-Result: Gopher Robot <gobot@golang.org>
asn1 allocates due to reflect.TypeOf(new(big.Int)) in init time.
We could replace it with (*big.Int)(nil).
Before:
init encoding/asn1 @1.0 ms, 0.009 ms clock, 224 bytes, 7 allocs
After:
init encoding/asn1 @0.70 ms, 0.002 ms clock, 192 bytes, 6 allocs
Fixes#55973
Change-Id: I7c3cc0f48631af73cf34ad3c731c380f46c72359
Reviewed-on: https://go-review.googlesource.com/c/go/+/435257
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: hopehook <hopehook@golangcn.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Imagine that initFuncTypes is called with n=3, funcTypes will be
[nil, nil, nil, **reflect.rtype] afterward, then it's called with n=2.
The current implementation will copy funcTypes because funcTypes[2] is
nil. This is unnecessary. It should make a new slice and copy funcTypes
into it only when n >= len(funcTypes).
Updates #56011.
Change-Id: Ia093d2f550d6924a4c58bcd21325093e32b40baa
GitHub-Last-Rev: a599eae7c2
GitHub-Pull-Request: golang/go#56024
Reviewed-on: https://go-review.googlesource.com/c/go/+/438395
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This reverts CL 437176.
Reason for revert: broke programs that plumb StdoutPipe from one command to Stdin on another and then call Wait on the former.
os/exec itself uses a type-assertion to *os.File to determine whether to copy stdin using a goroutine or just pass a file descriptor. An early Wait using a *os.File is benign (because closing the pipe doesn't close the child's inherited file descriptor), but an early Wait using a non-*os.File is not.
Updates #50436.
Change-Id: I4a2993e290982834f91696d890dfe77364c0cc50
Reviewed-on: https://go-review.googlesource.com/c/go/+/438695
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
[Roll-forward of CL 436915 by Tobias Klauser, with builtin and gen
directories dropped now that they've been handled separately.]
The minimum bootstrap version for Go ≥ 1.20 is Go 1.17. That version
supports the new style //go:build lines. Thus the old style //+build
lines can be dropped in this part of the tree as well. Leave the
//+build lines in cmd/dist which will ensure the minimum Go version
during bootstrap.
As suggested by Cherry during review of CL 430496
For #44505
Change-Id: Ifa686656c3e50bf7f92f70747b44d74a7d51bad8
Reviewed-on: https://go-review.googlesource.com/c/go/+/435473
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
These two directories are full of //go:build ignore files.
We can ignore them more easily by putting an underscore
at the start of the name. That also works around a bug
in Go 1.17 that was not fixed until Go 1.17.3.
Change-Id: Ia5389b65c79b1e6d08e4fef374d335d776d44ead
Reviewed-on: https://go-review.googlesource.com/c/go/+/435472
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
