OpenBSD has a default soft limit of 512 and hard limit of 1024 - as such,
attempting to open 1200 files is always going to fail unless the defaults
have been changed. On this platform use 768 instead such that it passes
without requiring customisation.
Fixes#51713
Change-Id: I7679c8fd73d4b263145129e9308afdb29d67bb54
Reviewed-on: https://go-review.googlesource.com/c/go/+/401594
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: 谢致邦 <xiezhibang@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
This CL adds support for debugger function calls on linux arm64
platform. The protocol is basically the same as in CL 109699, except for
the following differences:
1, The abi difference which affect parameter passing and frame layout.
2, Stores communication information in R20.
3, The closure register is R26.
4, Use BRK 0 instruction to generate a breakpoint. The saved PC in
sigcontext is the PC where the signal occurred, not the next PC.
In addition, this CL refactors the existing code (which is dedicated to
amd64) for easier multi-arch scaling.
Fixes#50614
Change-Id: I06b14e345cc89aab175f4a5f2287b765da85a86b
Reviewed-on: https://go-review.googlesource.com/c/go/+/395754
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Built using racebuild.
Note that racebuild fails when trying to test the .syso, because the
Go runtime doesn't think we support s390x race yet. But it builds the
.syso as a side effect which I grabbed. There's something of a
chicken-and-egg bootstrapping problem here, unfortunately.
Change-Id: Ibc6d04fd3a9bfb3224d08e8b78dcf09bb139a59d
Reviewed-on: https://go-review.googlesource.com/c/go/+/401714
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Jonathan Albrecht <jonathan.albrecht@ibm.com>
The proposal accepted the name ErrNestingDepth.
For #51684
Change-Id: I702365f19e5e1889dbcc3c971eecff68e0b08727
Reviewed-on: https://go-review.googlesource.com/c/go/+/401854
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.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>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This fixes a deadlock-on-failure that I probably introduced in
CL 385314.
This doesn't explain why the failure observed in #52492 occurred, but
it will at least give us more information to diagnose the failure if
it happens again. (The deadlock currently prevents the t.Fatal log
message from being written to the test's output.)
Fixes#52492.
Change-Id: I9e7874985e2820a6a4b703abe4f8e2035d5138c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/401575
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
In CL 397477 I merged long tests into the built-in cmd/release flow.
Skip them during the boringcrypto release for now; we've never run them
before.
For #51797.
Change-Id: I8d5caa945a2558cd3a311a90be5bfb62ae7b0ace
Reviewed-on: https://go-review.googlesource.com/c/go/+/401338
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is an exact copy of CL 401096 after fixing #52472 in CL 401654.
For #51087
For #52472
Change-Id: Ib3c914949a15517aacdca2d72e69e1c7b217e430
Reviewed-on: https://go-review.googlesource.com/c/go/+/401656
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is an exact copy of CL 388478 after fixing #52472 in CL 401654.
For #51087
For #52472
Change-Id: I6c6bd7ddcab1512c682e6b44f61c7bcde97f5c58
Reviewed-on: https://go-review.googlesource.com/c/go/+/401655
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The test has proven to be flaky on OpenBSD since March, and there
hasn't been progress on resolving this finding. Mark the test as
flaky to so that this problem doesn't block the Go 1.19 release.
Updates #51482.
Change-Id: I92ad7498c20cfa94565880363bec85f9a4f3e916
Reviewed-on: https://go-review.googlesource.com/c/go/+/401335
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
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>
Reviewed-by: Michael Pratt <mpratt@google.com>
Use error_.errorf for reporting related error information rather than
inlining the "\n\t". This aligns go/types with types2 in cases where the
related information has no position information. In other cases,
go/types needs to report a "continuation error" (starting with '\t') so
that users can access multiple error positions.
Change-Id: Ica98466596c374e0c1e502e7227c8d8c803b4c22
Reviewed-on: https://go-review.googlesource.com/c/go/+/400825
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
To begin aligning with types2 error reporting, use an error_ type to
hold unevaluated error information, to report via Checker.report.
Change-Id: Ic5ac515759961e55b81acc9eeaac4db25b61804c
Reviewed-on: https://go-review.googlesource.com/c/go/+/400824
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Checker.err was only called to report errors created with
Checker.newError or Checker.newErrorf. Update the API to pass around
*Error rather than error, eliminating unnecessary type assertions and
handling.
Change-Id: I995a120c7e87266e656b8ff3fd9ed3d368fd17fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/400823
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
With this patch, -asan option can detect the error memory
access to global variables.
So this patch makes a few changes:
1. Add the asanregisterglobals runtime support function,
which calls asan runtime function _asan_register_globals
to register global variables.
2. Create a new initialization function for the package
being compiled. This function initializes an array of
instrumented global variables and pass it to function
runtime.asanregisterglobals. An instrumented global
variable has trailing redzone.
3. Writes the new size of instrumented global variables
that have trailing redzones into object file.
4. Notice that the current implementation is only compatible with
the ASan library from version v7 to v9. Therefore, using the
-asan option requires that the gcc version is not less than 7
and the clang version is less than 4, otherwise a segmentation
fault will occur. So this patch adds a check on whether the compiler
being used is a supported version in cmd/go.
Change-Id: I664e74dcabf5dc7ed46802859174606454e8f1d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/321715
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Fannie Zhang <Fannie.Zhang@arm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This CL adds support for the reg ABI to the bytes functions for
riscv64. These are initially under control of the
GOEXPERIMENT macro until all changes are in.
Change-Id: I026295ae38e2aba055f7a51c77f92c1921e5ec97
Reviewed-on: https://go-review.googlesource.com/c/go/+/361916
Run-TryBot: mzh <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 205457 added the flag -Wno-nullability-completeness to work
around a user-reported build breakage on macOS Catalina.
However, according to
https://golang.org/issue/35247#issuecomment-589115489 the root cause
of the breakage may be a toolchain misconfiguration on the host
(perhaps compiling the XCode stdlib using a Homebrew build of the
"clang" compiler?).
Adding an obscure warning flag to enable building stdlib.h with an
otherwise-broken toolchain seems clearly inappropriate to me.
If need be we can instead provide guidance to users on how to unbreak
their toolchain.
Updates #35247Fixes#49913
Change-Id: I84def34e101bed7911d8d78a991a29095b8791fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/368634
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In CL 339309 this was probably copied from the respective godoc comment
in package inet.af/netaddr, also see
https://pkg.go.dev/inet.af/netaddr#IP.Is4
In net/netip the type is named Addr, so adjust the godoc comment
accordingly.
Change-Id: Ib5ab8054067f8b74119efa4732192a8407189f9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/401394
Run-TryBot: Tobias Klauser <tobias.klauser@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: Dmitri Shuralyov <dmitshur@google.com>
Also update the file in $GOROOT/api/next to use proposal number.
For #51684
Change-Id: I28bfa6bc1cee98a17b13da196d41cda34d968bb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/401076
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.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: Dmitri Shuralyov <dmitshur@google.com>
The following Value methods are now inlineable:
Bool for ~bool
String for ~string (but not other kinds)
Bytes for []byte (but not ~[]byte or ~[N]byte)
Len for ~[]T (but not ~[N]T, ~chan T, ~map[K]V, or ~string)
Cap for ~[]T (but not ~[N]T or ~chan T)
For Bytes, we only have enough inline budget to inline one type,
so we optimize for unnamed []byte, which is far more common than
named []byte or [N]byte.
For Len and Cap, we only have enough inline budget to inline one kind,
so we optimize for ~[]T, which is more common than the others.
The exception is string, but the size of a string can be obtained
through len(v.String()).
Performance:
Bool 1.65ns ± 0% 0.51ns ± 3% -68.81% (p=0.008 n=5+5)
String 1.97ns ± 1% 0.70ns ± 1% -64.25% (p=0.008 n=5+5)
Bytes 8.90ns ± 2% 0.89ns ± 1% -89.95% (p=0.008 n=5+5)
NamedBytes 8.89ns ± 1% 8.88ns ± 1% ~ (p=0.548 n=5+5)
BytesArray 10.0ns ± 2% 10.2ns ± 1% +1.58% (p=0.048 n=5+5)
SliceLen 1.97ns ± 1% 0.45ns ± 1% -77.22% (p=0.008 n=5+5)
MapLen 2.62ns ± 1% 3.07ns ± 1% +17.24% (p=0.008 n=5+5)
StringLen 1.96ns ± 1% 1.98ns ± 2% ~ (p=0.151 n=5+5)
ArrayLen 1.96ns ± 1% 2.19ns ± 1% +11.46% (p=0.008 n=5+5)
SliceCap 1.76ns ± 1% 0.45ns ± 2% -74.28% (p=0.008 n=5+5)
There's a slight slowdown (~10-20%) for obtaining the length
of a string or map, but a substantial improvement for slices.
Performance according to encoding/json:
CodeMarshal 555µs ± 2% 562µs ± 4% ~ (p=0.421 n=5+5)
MarshalBytes/32 163ns ± 1% 157ns ± 1% -3.82% (p=0.008 n=5+5)
MarshalBytes/256 453ns ± 1% 447ns ± 1% ~ (p=0.056 n=5+5)
MarshalBytes/4096 4.10µs ± 1% 4.09µs ± 0% ~ (p=1.000 n=5+4)
CodeUnmarshal 3.16ms ± 2% 3.02ms ± 1% -4.18% (p=0.008 n=5+5)
CodeUnmarshalReuse 2.64ms ± 3% 2.51ms ± 2% -4.81% (p=0.016 n=5+5)
UnmarshalString 65.4ns ± 4% 64.1ns ± 0% ~ (p=0.190 n=5+4)
UnmarshalFloat64 59.8ns ± 5% 58.9ns ± 2% ~ (p=0.222 n=5+5)
UnmarshalInt64 51.7ns ± 1% 50.0ns ± 2% -3.26% (p=0.008 n=5+5)
EncodeMarshaler 23.6ns ±11% 20.8ns ± 1% -12.10% (p=0.016 n=5+4)
Add all inlineable methods of Value to cmd/compile/internal/test/inl_test.go.
Change-Id: Ifc192491918af6b62f7fe3a094a5a5256bfb326d
Reviewed-on: https://go-review.googlesource.com/c/go/+/400676
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.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: Dmitri Shuralyov <dmitshur@google.com>
Partially fixes https://github.com/golang/go/issues/38674
The first commit has the actual unification, the second commit just cleans things up by moving shared code into its own package for clarity.
Change-Id: I85067f8b247df02f94684ec1297a1a42263bba0c
GitHub-Last-Rev: 370a4ecad3
GitHub-Pull-Request: golang/go#52315
Reviewed-on: https://go-review.googlesource.com/c/go/+/399542
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: Ia0a4be56d4e1fbfc73e6ce24f01a658c89a74adb
GitHub-Last-Rev: dd95e50c4b
GitHub-Pull-Request: golang/go#52393
Reviewed-on: https://go-review.googlesource.com/c/go/+/400694
Reviewed-by: Ian Lance Taylor <iant@google.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: Dmitri Shuralyov <dmitshur@google.com>
Currently bufio.Writer implements forwarding to the underlying Writer
for large writes via Write, but it does not do the same for large
writes via WriteString.
If the underlying Writer is also a StringWriter, use the same "large
writes" logic also in WriteString while taking care to only check
once per call to WriteString whether the underlying Writer implements
StringWriter.
Change-Id: Id81901c07b035936816b9e41b1f5688e699ee8e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/380074
Reviewed-by: Ian Lance Taylor <iant@google.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: Dmitri Shuralyov <dmitshur@google.com>
Also correct parameter name in comment.
Change-Id: Ic9486e08c2eea184faccf181cda7da808793def6
Reviewed-on: https://go-review.googlesource.com/c/go/+/400674
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This is a re-do of CL 388477, fixing #52472.
It is unsafe to call syscall.RawSyscall from syscall.Syscall with
-coverpkg=all and -race. This is because:
1. Coverage adds a sync/atomic call in RawSyscall to increment the
coverage counter.
2. Race mode instruments sync/atomic calls with TSAN runtime calls. TSAN
eventually calls runtime.racecallbackfunc, which expects
getg().m.p != 0, which is no longer true after entersyscall().
cmd/go actually avoids adding coverage instrumention to package runtime
in race mode entirely to avoid these kinds of problems. Rather than also
excluding all of syscall for this one function, work around by calling
RawSyscall6 instead, which avoids coverage instrumention both by being
written in assembly and in package runtime/*.
For #51087Fixes#52472
Change-Id: Iaffd27df03753020c4716059a455d6ca7b62f347
Reviewed-on: https://go-review.googlesource.com/c/go/+/401654
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>
cmd/trace is currently somewhat painful to use in odd environments since
it depends on the presence of $GOROOT/misc/trace to serve the static
trace viewer content.
Use //go:embed to embed this content directly into cmd/trace for easier
use.
Change-Id: I83b7d97dbecc9773f3b5a6b3bc4a6597473bc01a
Reviewed-on: https://go-review.googlesource.com/c/go/+/378194
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Just like https://golang.org/cl/401454 removed the work from gofmt for a
nice ~5% speed-up in the default case, we can also use the option in the
equivalent go/format for programs which use it rather than gofmt,
as go/format makes no use of objects either.
No benchmark numbers as we already measured the ~5% speed-up with gofmt
in the other CL linked above.
See #46485.
Change-Id: Icbf98e6d46a616081314e2faa13f1dfade3bbaef
Reviewed-on: https://go-review.googlesource.com/c/go/+/401474
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
go/parser will by default resolve objects as per the go/ast.Object type,
which is then used by gofmt's rewrite and simplify flags.
However, none of that is needed if neither of the flags is set,
so we can avoid the work entirely for a nice speed-up.
benchcmd -n 8 GofmtSrcCmd gofmt -l ~/tip/src/cmd
name old time/op new time/op delta
GofmtSrcCmd 957ms ± 7% 908ms ± 7% -5.12% (p=0.028 n=8+8)
name old user-time/op new user-time/op delta
GofmtSrcCmd 11.2s ± 1% 10.4s ± 1% -7.23% (p=0.001 n=7+7)
name old sys-time/op new sys-time/op delta
GofmtSrcCmd 325ms ±29% 286ms ±22% ~ (p=0.065 n=8+8)
name old peak-RSS-bytes new peak-RSS-bytes delta
GofmtSrcCmd 295MB ±17% 276MB ±15% ~ (p=0.328 n=8+8)
See #46485.
Change-Id: Iad1ae294953710c233f7837d7eb02e23d11c6185
Reviewed-on: https://go-review.googlesource.com/c/go/+/401454
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This reverts CL400377, which restricted serials passed to
x509.CreateCertificate to <= 20 octets. Unfortunately this turns out to
be something _a lot_ of people get wrong. Since it's not particularly
obvious how to properly generate conformant serials, until we provide
an easier way for people to get this right, reverting this restriction
makes sense (possible solution discussed in #52444.)
Change-Id: Ia85a0ffe61e2e547abdaf1389c3e1ad29e28a2be
Reviewed-on: https://go-review.googlesource.com/c/go/+/401657
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Rename it TestIssue1560 since it no longer sleeps.
For #1560Fixes#45586
Change-Id: I338eee9de43e871da142143943e9435218438e90
Reviewed-on: https://go-review.googlesource.com/c/go/+/400194
Reviewed-by: Bryan Mills <bcmills@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>
TryBot-Result: Gopher Robot <gobot@golang.org>
When the user is trying to list or build a package in a module that's
outside of the workspace provide a more clear message hinting to the
user that they can add the module to the workspace using go work use.
Fixes#51604
Change-Id: I1202ecb2f22fd6351bfdec88ed613b8167687fb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/400014
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Future CLs will be changing the provenance of these functions. Move the
declarations to the individual OS files now so that future CLs can
change only 1 OS at a time rather than changing all at once.
For #51087
Change-Id: I5e1bca71e670263d8c0faa586c1b6b4de1a114b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/388474
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL exports the existing ir.UintptrKeepAlive via the new directive
//go:uintptrkeepalive. This makes the compiler insert KeepAlives for
pointers converted to uintptr in calls, keeping them alive for the
duration of the call.
//go:uintptrkeepalive requires //go:nosplit, as stack growth can't
handle these arguments (it cannot know which are pointers). We currently
check this on the immediate function, but the actual restriction applies
to all transitive calls.
The existing //go:uintptrescapes is an extension of
//go:uintptrkeepalive which forces pointers to escape to the heap, thus
eliminating the stack growth issue.
This pragma is limited to the standard library.
For #51087
Change-Id: If9a19d484d3561b4219e5539b70c11a3cc09391e
Reviewed-on: https://go-review.googlesource.com/c/go/+/388095
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
CL 388095 will change this file significantly. Move it preemptively to
ensure git tracks the move properly.
For #51087
Change-Id: I1408aecf8675723041b64e54cf44cdec38cc655c
Reviewed-on: https://go-review.googlesource.com/c/go/+/388094
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is a code simplification using the new API added in #50599.
Change-Id: Icb9628bcd0daa3dc2d653e9654b38099730137d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/401535
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
With #50599 implemented, base.AppendPWD is redundant if cmd.Env would
otherwise be nil, and calls to os.Environ followed by base.AppendPWD
can be replaced by a simpler call to cmd.Environ.
Updates #50599.
Change-Id: I94a22e2a4cc8e83c815ac41702ea0b1ee5034ecc
Reviewed-on: https://go-review.googlesource.com/c/go/+/401534
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: If3d8391d81e8de869dbb3c857f0570817e8aa440
Reviewed-on: https://go-review.googlesource.com/c/go/+/400914
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I5698c7576a0f39ae62de7bea64286ac8e578d421
Reviewed-on: https://go-review.googlesource.com/c/go/+/400916
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I5ccbcea4c53658136b25ca608faec19eeec2e908
Reviewed-on: https://go-review.googlesource.com/c/go/+/400915
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
