- Include the callee names in hot call inlining message.
- Print the graph when pgoinline >= 2.
Change-Id: Iceb89b5f18cefc69ab9256aca9a910743d22ec0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/448496
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Passing a profile with no sample is arguably not a user error.
Accept such a profile, and ignore it as it doesn't indicate any
optimizations. This also makes testing easier.
Change-Id: Iae49a4260e20757419643153f50d8d5d51478411
Reviewed-on: https://go-review.googlesource.com/c/go/+/448495
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Appears to be a typo in CL 447315.
Change-Id: I9f380a3c7521f5ac5a1d7e271eaa60bd4bbcfb29
Reviewed-on: https://go-review.googlesource.com/c/go/+/448515
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Unix and Windows differ in how they handle LookupCNAME(name).
If name exists in DNS with an A or AAAA record but no CNAME,
then on all operating systems and in the pure Go resolver,
LookupCNAME returns the name associated with the A/AAAA record
(the original name).
TestLookupCNAME has been testing this, because www.google.com
has no CNAME. I think it did at one point, but not anymore, and the
tests are still passing. Also added google.com as a test, since
top-level domains are disallowed from having CNAMEs.
If name exists in DNS with a CNAME record pointing to a record that
does not exist or that has no A or AAAA record,
then Windows has always reported the CNAME value,
but Unix-based systems and the pure Go resolver have reported
a failure instead. cname-to-txt.go4.org is an test record that is
a CNAME to a non-A/AAAA target (the target only has a TXT record).
This CL changes the Unix-based systems and the pure Go resolver
to match the Windows behavior, allowing LookupCNAME to succeed
whenever a CNAME exists.
TestLookupCNAME nows tests the new behavior by looking up
cname-to-txt.go4.org (run by bradfitz).
Fixes#50101.
Change-Id: Ieff5026c8535760e6313c7a41ebd5ff24de6d9be
Reviewed-on: https://go-review.googlesource.com/c/go/+/446179
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The interface will let us store actor-specific state in the
interface implementation instead of continuing to grow
the Action struct. In the long term we should remove fields
from the struct that are not used by all Actions.
Change-Id: I8ac89eda7a91d742cee547a1f779e9f254dfd2f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/448356
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Extend the context package to allow users to specify why a context was
canceled in the form of an error, the "cause". Users write the cause
by calling WithCancelCause to construct a derived context, then
calling cancel(cause) to cancel the context with the provided cause.
Users retrieve the cause by calling context.Cause(ctx), which returns
the cause of the first cancelation for ctx or any of its parents.
The cause is implemented as a field of cancelCtx, since only cancelCtx
can be canceled. Calling cancel copies the cause to all derived (child)
cancelCtxs. Calling Cause(ctx) finds the nearest parent cancelCtx by
looking up the context value keyed by cancelCtxKey.
API changes:
+pkg context, func Cause(Context) error
+pkg context, func WithCancelCause(Context) (Context, CancelCauseFunc)
+pkg context, type CancelCauseFunc func(error)
Fixes#26356Fixes#51365
Change-Id: I15b62bd454c014db3f4f1498b35204451509e641
Reviewed-on: https://go-review.googlesource.com/c/go/+/375977
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Sameer Ajmani <sameer@golang.org>
Auto-Submit: Sameer Ajmani <sameer@golang.org>
Change-Id: Iddf4d3bcc3bc2badf0d0f6b06375c901e76a40bb
GitHub-Last-Rev: 95586bfc16
GitHub-Pull-Request: golang/go#56268
Reviewed-on: https://go-review.googlesource.com/c/go/+/443315
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: I7605bcbbaa64bb4273ad458a157b1c6011467973
Reviewed-on: https://go-review.googlesource.com/c/go/+/447915
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@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>
Remove redundant code at line 365, `oldCtx := req.Context()`, because it's the same as line 349.
Change-Id: I9b028e8c8740c22945708b143e4e86a0baa40f64
GitHub-Last-Rev: 4ad0f3871b
GitHub-Pull-Request: golang/go#54925
Reviewed-on: https://go-review.googlesource.com/c/go/+/428977
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Resend of CL 432735 (with one additional conversion that the original CL
missed) after it broke the longtest builder on x/tools and was reverted
in CL 433478. Now that x/tools/go/ssa has support for this, the longtest
x/tools build passes as well.
Use slice-to-array conversions in AddrFromSlice and
(*Addr).UnmarshalBinary. This allows using AddrFrom16 and drop the
redundant ipv6Slice helper.
For #46505
Change-Id: I4d8084b7a97f162e4f7d685c86aac56d960ff693
Reviewed-on: https://go-review.googlesource.com/c/go/+/448396
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This gets the Go command out of the business of thinking it understands
compiler debug flags, and allows the compiler to turn down its worker
concurrency instead of failing and forcing the user to do the very
same thing. Debug flags that are obviously safe for concurrency
(at least to me) are tagged; probably there's more.
Change-Id: I59bb19861d8a654a9cfd2364ee78c8628212f82e
Reviewed-on: https://go-review.googlesource.com/c/go/+/448359
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Invalid struct name in the comment in merge.go
dstate -> mstate
dstate already exists and is in cmd/covdata/dump.go
Change-Id: Id8b2412d2f81ae8afa1e9df3d09c218d84818ffb
GitHub-Last-Rev: 898eda4a20
GitHub-Pull-Request: golang/go#56631
Reviewed-on: https://go-review.googlesource.com/c/go/+/448475
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Alpine has a known issue where setgid clobbers the Go stack (#39857).
misc/cgo/test skips other tests that use setgid on Alpine, but not
this one. It's not clear to me why this test *used to* pass, but when
I refactored misc/cgo/test in CL 447355 it started failing.
Disable this test on Alpine, like the other setgid tests.
Change-Id: I2e646ef55e2201a4f0b377319d719a011ec847f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/448355
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Support for direct libc calls was added in CL 446178 but the build
tags weren't quite activating it when cgo was not enabled. Adjust them
and add a new supporting file for darwin.
This should use the new direct libc calls with both CGO_ENABLED=0 and
CGO_ENABLED=1 when building for darwin.
Updates #12524
Change-Id: Ieee4b298dee13f389ed3a63c0a4a3a18c9180163
Reviewed-on: https://go-review.googlesource.com/c/go/+/448020
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Dan Peterson <danp@danp.net>
Auto-Submit: Ian Lance Taylor <iant@google.com>
In verifyServerCertificate parse certificates using the global
certificate cache.
This should signficiantly reduce memory usage in TLS clients which make
concurrent connections which reuse certificates (anywhere in the chain)
since there will only ever be one copy of the certificate at once.
Fixes#46035
Change-Id: Icf5153d0ea3c14a0bdc8b26c794f21153bf95f85
Reviewed-on: https://go-review.googlesource.com/c/go/+/426455
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Change-Id: Iabf955cdb161d02cb4a3e06f466b331e1b6eb2c2
Signed-off-by: cui fliter <imcusg@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/447456
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Adds a BoringSSL CRYPTO_BUFFER_POOL style reference counted intern
table for x509.Certificates. This can be used to significantly reduce
the amount of memory used by TLS clients when certificates are reused
across connections.
Updates #46035
Change-Id: I8d7af3bc659a93c5d524990d14e5254212ae70f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/426454
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Though we split traces into 100MB chunks, currently each chunk always
includes the entire stack frame map, including frames for all events in
the trace file, even if they aren't needed by events in this chunk.
This means that if the stack frame JSON alone is >100MB then there is no
space at all for events. In that case, we'll generate splits each
containing 1 event, which is effectively useless.
Handle this more efficiently by only including stack frames referenced
by events in the chunk. Each marginal events only adds at most a few
dozen stack frames, so it should now longer be possible to only include
a tiny number of events.
Fixes#56444.
Change-Id: I58aa8f271c32678028b72d82df16e6ea762ebb39
Reviewed-on: https://go-review.googlesource.com/c/go/+/445895
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
runtime.bgsweep contains an infinite loop. With aggressive enough
inlining, it may not perform any CALLs on a typical iteration. If
the runtime trying to preempt this goroutine, the lack of CALLs may
prevent preemption for ever occurring.
bgsweep does happen to call goschedIfBusy. Add a preempt check there to
make sure we yield eventually.
For #55022.
Change-Id: If22eb86fd6a626094b3c56dc745c8e4243b0fb40
Reviewed-on: https://go-review.googlesource.com/c/go/+/447135
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
ISEL is roughly equivalent to CMOV on PPC64. Verify ISEL generation
in all reasonable cases.
Note "ISEL test x y z" is the same as "ISEL !test y x z". test is
always one of LT (0), GT (1), EQ (2), SO (3). Sometimes x and y are
swapped if GE/LE/NE is desired.
Change-Id: Ie1bf029224064e004d855099731fe5e8d05aa990
Reviewed-on: https://go-review.googlesource.com/c/go/+/445215
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Change-Id: I1f713bbb35917ab50b0cde24a81340aa16c2ed03
Reviewed-on: https://go-review.googlesource.com/c/go/+/448195
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Ic16824482142d4de4d0b949459e36505ee944ff7
Reviewed-on: https://go-review.googlesource.com/c/go/+/448175
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Dan Kortschak <dan@kortschak.io>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dan Kortschak <dan@kortschak.io>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
For #46746
Change-Id: I75ddb9ce24cd3394186562dae156fef9fe2d55d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/447798
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I871a747b4b47bccc889f2fdc93a2bcebb041b719
Reviewed-on: https://go-review.googlesource.com/c/go/+/447895
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Currently locations are stored in a map and looked up by ID from
the map. The IDs are usually small sequential integers (the Go
pprof CPU profiles are so). Using a slice is more efficient (with
a fallback map to handle weirdly large IDs).
Change-Id: I9e20d5cebca3a5239636413e1bf2f0b273038031
Reviewed-on: https://go-review.googlesource.com/c/go/+/447803
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that most GOROOT packages do not have install targets, their
staleness depends on whether their builds have been cached. That means
that, from a clean cache, once
TestNewReleaseRebuildsStalePackagesInGOPATH builds certain targets, they
will stay non-stale for the second run of the test, becasue the will
still be in the cache. So the first run of the test from a clean cache
will pass and the second will fail. Set GOCACHE to a temporary directory
in the test to use a clean cache and avoid this.
Change-Id: I91f954138a4723d81545134441148badbfc515f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/448018
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rather than matching calls to edges in the profile based directly on
line number in the source file, use the line offset from the start of
the function. This makes matching robust to changes in the source file
above the function containing the call.
The start line in the profile comes from Function.start_line, which is
included in Go pprof output since CL 438255.
Currently it is an error if no samples set start_line to help users
detect profiles missing this information. In the future, we should
fallback to using absolute lines, which is better than nothing.
For #55022.
Change-Id: Ie621950cfee1fef8fb200907a2a3f1ded41d04fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/447315
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
When adding weights for a call stack, for recursive calls, to
avoid double counting we check if we already saw the node and the
edge. We check the node first. An edge can be repeated if the node
is repeated. Most stacks are not recursive, so check repeated edge
only conditionally.
Change-Id: I4b8f039289dcd3383ca89593d6d16d903b94c3dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/447804
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Now that misc/cgo/test doesn't invoke any Go builds itself, we don't
need to use GOFLAGS to thread build flags down into sub-builds.
Preparation for #37486.
Change-Id: I9ecdd215da5c21339cbf76765f8be2190d19539c
Reviewed-on: https://go-review.googlesource.com/c/go/+/447356
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
When we were first introducing module mode, CL 163418 moved many of
the tests in misc/cgo/test into their own test binary under testdata
so misc/cgo/test continued to work in both GOPATH mode and module
mode. This introduce a somewhat complicated test driver into
misc/cgo/test. Since the misc/cgo/test test had to invoke "go test" as
a subprocess, this required care to thread any build flags down into
the subprocess. The output from any failures of the sub-process was
also less than ideal.
Now that we don't have to worry about running these in GOPATH mode any
more, this CL moves all of the tests back into misc/cgo/test and drops
the test driver.
There are two slight complications:
- Test41761 was added after this split and has a C type "S" that's
also present in misc/cgo/test itself. We rename that to keep that
test working.
- TestCgo in go/internal/srcimporter now fails to import misc/cgo/test
because misc/cgo/test now contains imports of other "misc" module
packages and the importer it sets up isn't configured to allow that.
We fix this by setting up a build context that's configured for
this.
Preparation for #37486.
Change-Id: I3c4f73540e0482bbd493823cca44b0ce7fac01f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/447355
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently in the pprof Graph, a Node's in/out edges are
represented as maps, keyed by the source/destination Nodes. For a
Node it usually has a very small number of edges, so linear search
would be generally faster than map operations. Use slices and
linear search instead.
Change-Id: I5ab06be0c019373cd3a845b9f3282731372e9c4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/447802
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We intentionally don't use file path so it is resilient to code
moving. OrigName and Objfile are also not used currently. Remove
them. (We can add them back if it turns out to be useful.)
Change-Id: I7975d78c874bc21475b9119301088452a4426cb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/447801
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We don't use it. Make graph building a little faster.
Change-Id: I4a6f516f8e68bf338be8350f91c51f6f1dea26bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/447800
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Default concurrency is now GOMAXPROCS, though this is normally
reduced to 4 by the go build commmand.
If compiler flags don't permit concurrency, silently
turn it down instead of failing the compilation.
Change-Id: Id26cc3214e0ca402d60f915e98276a58d809e097
Reviewed-on: https://go-review.googlesource.com/c/go/+/447358
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Semicolon has bad copy-paste ergonomics; it requires quoting.
Slash is okay, and won't be a separator ever in debug strings
because it is already used in e.g. ssa/phase/debug=etc.
Change-Id: I493360e9282666eea1a342971a77df2ebd6c92ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/447975
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
With CL 447015, we identify hot callees from edge weights, but
the code only traverses edges for calls from the current package.
If the callee is in a different package, when compiling that
package, the edge was not visited, so the callee was not actually
marked inline candidate. This CL fixes it by traversing all hot
edges.
Change-Id: If668c1a16ebe34e3474376b88ab3a84be76b8562
Reviewed-on: https://go-review.googlesource.com/c/go/+/448015
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This may fix the TestEINTR failures that have been frequent on the
riscv64 builders since CL 445597.
Updates #37405.
Updates #39043.
Change-Id: Iaf1403ff5ce2ff0203d5d0059908097d32d0b217
Reviewed-on: https://go-review.googlesource.com/c/go/+/447495
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Change-Id: I9bcaba0ca9c30b204bf126dbfec4cd48d9ebe2ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/447896
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Than McIntosh <thanm@google.com>
Run-TryBot: xie cui <523516579@qq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes a bug that was introduced in CL 410414; in that CL, to avoid
a race condition in the initialization of the lexer, the setting
of the breakOK and continueOK options was moved to before
Tree.funcs was populated from parameters. As a result, the parser
missed the fact that 'break' and 'continue' were defined as functions.
Following CL 421883 race conditions are no longer an issue, so
the simplest fix is just to move the initialization where it was
before - in startParse, after t.funcs has been set.
Fixes#56538
Change-Id: I3b99fe9ad12255a4f6eb9a00eb3f64529ff055c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/447775
Run-TryBot: Eli Bendersky <eliben@golang.org>
Auto-Submit: Eli Bendersky <eliben@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Fixes#55301
Change-Id: Ie8abcd383eee9af75038bde908ac638f43d33b7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/444955
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>
Run-TryBot: xie cui <523516579@qq.com>
Plan 9 uses NUL as os.PathListSeparator, so it's almost always going
to appear in the environment variable list. Exempt GOOS=plan9 from the
check for NUL in environment variables.
For #56284.
Fixes#56544.
Change-Id: I23df233cdf20c0a9a606fd9253e15a9b5482575a
Reviewed-on: https://go-review.googlesource.com/c/go/+/447715
Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
