Note that this changes a few unsynchronized operations of forcegcstate.idle to synchronized operations.
Updates #53821
Change-Id: I041654cc84a188fad45e2df7abce3a434f9a1f15
Reviewed-on: https://go-review.googlesource.com/c/go/+/425361
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
On the write side, g.selectDone has been converted
from non-atomic to atomic access.
For #53821.
Change-Id: Iac46bc6acce7eed51dfd990285dd57f0d58b4ae2
Reviewed-on: https://go-review.googlesource.com/c/go/+/425414
Run-TryBot: hopehook <hopehook@qq.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Note that this changes a non-atomic operation to atomic operation.
For #53821
Change-Id: I798914f505c8d7f85f9d7629fdc6493363a20aa1
Reviewed-on: https://go-review.googlesource.com/c/go/+/425782
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: hopehook <hopehook@qq.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
In typebits.Set we check that the offset is a multiple of the
alignment, which makes perfect sense. But for values like
atomic.Int64, which has 8-byte alignment even on 32-bit platforms
(i.e. the alignment is larger than PtrSize), if it is on stack it
may be under-aligned, as the stack frame is only PtrSize aligned.
Normally we would prevent such values on stack, as the escape
analysis force values with higher alignment to heap. But for a
composite literal assignment like x = AlignedType{...}, the
compiler creates an autotmp for the RHS then copies it to the LHS.
The autotmp is on stack and may be under-aligned. Currently this
may cause an ICE in the typebits.Set check.
This CL makes it align the _offset_ of the autotmp to 8 bytes,
which satisfies the check. Note that this is actually lying: the
actual address at run time may not necessarily be 8-byte
aligned as we only align SP to 4 bytes.
The under-alignment is probably okay. The only purpose for the
autotmp is to copy the value to the LHS, and the copying code we
generate (at least currently) doesn't care the alignment beyond
stack alignment.
Fixes#54638.
Change-Id: I13c16afde2eea017479ff11dfc24092bcb8aba6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425256
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#54669
Change-Id: I34cbe729d187437ddeafbaa910af6ed001b2603f
Reviewed-on: https://go-review.googlesource.com/c/go/+/425461
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This matches types2 behavior.
For #54511.
Change-Id: Iea906e9fec7e334b7aa7f481de87373fa93d1c7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/425715
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The change in typexpr.go matches types2 behavior.
For #54511.
Change-Id: I79c922a94f2ee0440c1814140935c321439c7d25
Reviewed-on: https://go-review.googlesource.com/c/go/+/425714
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
There are only two tests that rely on the "ERROR HERE" markers;
yet those tests are trivialy adjustable (by adding an explicit
semicolon) such that they can just use the "ERROR" markers.
For #54511.
Change-Id: Idbb96ca8d35ae2584d195a4ac7c92640b8b492c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/425674
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This change updates the gctrace docs to include stacks and globals in
the format line, and prints lastStackScan for "# MB stacks" instead of
maxStackScan, which is more accurate.
Fixes#54649.
Change-Id: Ibff2c390c9c9bf2b24b5b4e98ca346cc98d7cb2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/425366
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
MarshalPKIXPublicKey, CreateCertificate, CreateCertificateRequest,
MarshalECPrivateKey, and MarshalPKCS8PrivateKey started raising a panic
when encoding an invalid ECDSA key in Go 1.19. Since they have an error
return value, they should return an error instead.
Fixes#54288
Change-Id: Iba132cd2f890ece36bb7d0396eb9a9a77bdb81df
Reviewed-on: https://go-review.googlesource.com/c/go/+/422298
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
When inlining function calls, we rewrite the position information on
all of the nodes to keep track of the inlining context. This is
necessary so that at runtime, we can synthesize additional stack
frames so that the inlining is transparent to the user.
However, for function literals, we *don't* want to apply this
rewriting to the underlying function. Because within the function
literal (when it's not itself inlined), the inlining context (if any)
will have already be available at the caller PC instead.
Unified IR was already getting this right in the case of user-written
statements within the function literal, which is what the unit test
for #46234 tested. However, it was still using inline-adjusted
positions for the function declaration and its parameters, which
occasionally end up getting used for generated code (e.g., loading
captured values from the closure record).
I've manually verified that this fixes the hang in
https://go.dev/play/p/avQ0qgRzOgt, and spot-checked the
-d=pctab=pctoinline output for kube-apiserver and kubelet and they
seem better.
However, I'm still working on a more robust test for this (hence
"Updates" not "Fixes") and internal assertions to verify that we're
emitting correct inline trees. In particular, there are still other
cases (even in the non-unified frontend) where we're producing
corrupt (but at least acyclic) inline trees.
Updates #54625.
Change-Id: Iacfd2e1eb06ae8dc299c0679f377461d3d46c15a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425395
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Elapsed returns the measured elapsed time of the benchmark,
but does not change the running state of the timer.
Fixes#43620.
Change-Id: Idd9f64c4632518eec759d2ffccbf0050d84fcc03
Reviewed-on: https://go-review.googlesource.com/c/go/+/420254
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: hopehook <hopehook@qq.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Given a composite literal type S, rather than always printing
(S literal) for a composite literals, print S{} if the literal
has no elements, and print S{…} as a short form (suitable for
error messages) if there are elements. This matches types2 and
also Go1.17 compiler behavior (except that the original compiler
would print ... rather than …). Using … rather than ... makes
it clearer that we don't have real Go syntax, and it's also more
compact.
For #54511.
Change-Id: I5991e8060232f16ecbf4a1fe4ae091598fc76b68
Reviewed-on: https://go-review.googlesource.com/c/go/+/425006
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
On LR architectures, morestack (and morestack_noctxt) are called
with a special calling convention, where the caller doesn't save
LR on stack but passes it as a register, which morestack will save
to g.sched.lr. The stack unwinder currently doesn't understand it,
and would fail to unwind from it. morestack already writes SP (as
it switches stack), but morestack_noctxt (which tailcalls
morestack) doesn't. If a profiling signal lands right in
morestack_noctxt, the unwinder will try to unwind the stack and
go off, and possibly crash.
Marking morestack_noctxt SPWRITE stops the unwinding.
Ideally we could teach the unwinder about the special calling
convention, or change the calling convention to be less special
(so the unwinder doesn't need to fetch a register from the signal
context). This is a stop-gap solution, to stop the unwinder from
crashing.
Fixes#54332.
Change-Id: I75295f2e27ddcf05f1ea0b541aedcb9000ae7576
Reviewed-on: https://go-review.googlesource.com/c/go/+/425396
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Some tests in misc/cgo/testsanitizers had been disabled on ppc64le
until recently, due to an intermittent error in the tsan tests,
with the goal of trying to understand the failure.
After further investigation, I found that the code for tsan within
gcc does not work consistently when ASLR is enabled on ppc64le. A
fix for that problem was integrated in gcc 9.
This adds a check to testsanitizers to determine the gcc compiler
version on ppc64le and skip the test if the version is too old.
A similar check is needed for asan too.
Updates #54645
Change-Id: I70717d1aa9e967cf1e871566e72b3862b91fea3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/425355
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Also:
- fine-tune the implementation for some of the new builtin functions
- make sure the go/types code is an exact as possible copy of the
types2 code
- fix the description and examples for errorcodes.go
Follow-up on CL 423754.
For #53003.
Change-Id: I5c70b74e90c724cf6c842cedc6f8ace26fde372b
Reviewed-on: https://go-review.googlesource.com/c/go/+/425454
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
For "type T interface{ M() }", go/types users expect T's underlying
interface type to specify T as the receiver parameter type (#49906).
The unified importer handles this by cloning the interface to rewrite
the receiver parameters before calling SetUnderlying.
I missed in CL 425360 that these interfaces would need to have
Complete called too.
Manually tested to confirm that this actually fixes "go test -race
golang.org/x/tools/go/analysis/internal/checker" now (when both CLs
are ported to the x/tools importer).
Updates #54653.
Change-Id: I51e6db925db56947cd39dbe880230f14734ca01c
Reviewed-on: https://go-review.googlesource.com/c/go/+/425365
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
To support concurrent use of the go/types API, importers need to call
Interface.Complete on constructed interfaces before returning.
There's an issue that the interfaces may contain embedded defined
types, whose underlying type isn't known yet. This issue will
eventually go away once CL 424876 lands, but that CL needs to wait for
CL 424854 to re-land, which needs to wait for CL 421879 to land...
In the mean time, this CL implements the same solution used by the
indexed importer: maintaining a list of constructed interfaces, and
calling Interface.Complete on them after the SetUnderlying loop and
just before returning the imported package.
Updates #54653.
Change-Id: I0f42c915a4b7d28c628bbab7ac2eab2415c7858f
Reviewed-on: https://go-review.googlesource.com/c/go/+/425360
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Add content generated by 'relnote -html'. This covers all of known
TODOs available by 2022-08-24 such that relnote produces no output
when -exclude-from=doc/go1.20.html flag is used.
For #54202.
Change-Id: Icd9be5364bc73c3de56d5d3039e6f313908af38e
Reviewed-on: https://go-review.googlesource.com/c/go/+/425354
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
This is a follow up of CL 425101 on RISCV64.
According to RISCV Volume 1, Unprivileged Spec v. 20191213 Chapter 7.1:
If both the high and low bits of the same product are required, then the
recommended code sequence is: MULH[[S]U] rdh, rs1, rs2; MUL rdl, rs1, rs2
(source register specifiers must be in same order and rdh cannot be the
same as rs1 or rs2). Microarchitectures can then fuse these into a single
multiply operation instead of performing two separate multiplies.
So we should not split Muluhilo to separate instructions.
Updates #54607
Change-Id: If47461f3aaaf00e27cd583a9990e144fb8bcdb17
Reviewed-on: https://go-review.googlesource.com/c/go/+/425203
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This initial release notes template is based on previous releases.
CL 425354 adds initial content generated by 'relnote -html'.
For #54202.
Change-Id: I36e15723edc9610d61986ba226ee84c2b30a33af
Reviewed-on: https://go-review.googlesource.com/c/go/+/425334
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
These tests invoke the system C compiler and linker.
Skipping them saves a little over half a second of time in short mode.
Updates #54423.
Change-Id: I3e8aa7b53c0c91f7d1e001ec2cd5f7b4954de52d
Reviewed-on: https://go-review.googlesource.com/c/go/+/425206
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Ever since 'go build' was added (in CL 5483069), it has used an atexit
handler to clean up working directories. At some point (prior to CL
95900044), Init was called multiple times per builder, registering
potentially many atexit handlers that execute asynchronously and make
debugging more difficult.
The use of an AtExit handler also makes the Builder (and anything that
uses it) prone to races: the base.AtExit API is not designed for
concurrent use, but cmd/go is becoming increasingly concurrent over
time. The AtExit handler also makes the Builder inappropriate to use
within a unit-test, since the handlers do not run during the test
function and accumulate over time.
This change makes NewBuilder safe for concurrent use by registering
the AtExit handler only once (during BuildInit, which was already not
safe for concurrent use), and using a sync.Map to store the set of
builders that need cleanup in case of an unclean exit. In addition, it
causes the test variant of cmd/go to fail if any Builder instance
leaks from a clean exit, helping to ensure that functions that create
Builders do not leak them indefinitely, especially in tests.
Updates #54423.
Change-Id: Ia227b15b8fa53c33177c71271d756ac0858feebe
Reviewed-on: https://go-review.googlesource.com/c/go/+/425254
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Ever since 'go build' was added (in CL 5483069), it has used an atexit
handler to clean up working directories.
CL 154109 introduced 'cc' command to the script test framework that
called Init on a builder once per invocation. Unfortunately, since
base.AtExit is unsynchronized, the Init added there caused any script
that invokes that command to be unsafe for concurrent use.
This change fixes the race by having the 'cc' command pass in its
working directory instead of allowing the Builder to allocate one.
Following modern Go best practices, it also replaces the in-place Init
method (which is prone to typestate and aliasing bugs) with a
NewBuilder constructor function.
Fixes#54423.
Change-Id: I8fc2127a7d877bb39a1174e398736bb51d03d4d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/425205
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL changes the inliner to process transitive inlining iteratively
after the AST has actually been edited, rather than recursively and
immediately. This is important for handling indirect function calls
correctly, because ir.reassigned walks the function body looking for
reassignments; whereas previously the inlined reassignments might not
have been actually added to the AST yet.
Fixes#54632.
Change-Id: I0dd69813c8a70b965174e0072335bc00afedf286
Reviewed-on: https://go-review.googlesource.com/c/go/+/425257
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
If a struct or array is comparable, then we can leverage rtype.equal,
which is almost always faster than what Go reflection can achieve.
As a secondary optimization, pre-compute Value.Len and Value.NumField
outside of the loop conditional.
Performance:
name old time/op new time/op delta
IsZero/ArrayComparable 136ns ± 4% 16ns ± 1% -88.28% (p=0.008 n=5+5)
IsZero/ArrayIncomparable 197ns ±10% 123ns ± 1% -37.74% (p=0.008 n=5+5)
IsZero/StructComparable 26.4ns ± 0% 9.6ns ± 1% -63.68% (p=0.016 n=4+5)
IsZero/StructIncomparable 43.5ns ± 1% 27.8ns ± 1% -36.21% (p=0.008 n=5+5)
The incomparable types gain a performance boost since
they are generally constructed from nested comparable types.
Change-Id: If2c1929f8bb1b5b19306ef0c69f3c95a27d4b60d
Reviewed-on: https://go-review.googlesource.com/c/go/+/411478
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I5987eed00ee825421abe62699a06e9b66499f35f
Reviewed-on: https://go-review.googlesource.com/c/go/+/425016
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
So next CLs can revert changes to "internal/singleflight" in CL #82795,
then replace it with "golang.org/x/sync/singleflight" instead.
For #31697
Change-Id: I873ce30d7e051539aa6dc5d4f21e558869a6d132
Reviewed-on: https://go-review.googlesource.com/c/go/+/423654
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Change-Id: Ied16c3be47c863a94d46bd568191057ded4b7d0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/416734
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
This causes a problem in the test sometimes. With a mapping like:
00400000-00411000 r--p 00000000 fe:01 4459044 /tmp/go-build1710804385/b001/pprof.test
00411000-00645000 r-xp 00011000 fe:01 4459044 /tmp/go-build1710804385/b001/pprof.test
The removed code would make the first mapping 0x400000-0x645000. Tests
then grab the first few addresses to use as PCs, thinking they are in
an executable range. But those addresses are really not in an
executable range, causing the tests to fail.
Change-Id: I5a69d0259d1fd70ff9745df1cbad4d54c5898e7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/424295
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
JoinPath would fail to remove relative elements from the start of
the path when the first path element is "".
In addition, JoinPath would return the original path unmodified
when provided with no elements to join, violating the documented
behavior of always cleaning the resulting path.
Correct both these cases.
JoinPath("http://go.dev", "../go")
// before: http://go.dev/../go
// after: http://go.dev/go
JoinPath("http://go.dev/../go")
// before: http://go.dev/../go
// after: http://go.dev/goFixes#54385.
Change-Id: I6d22cd160d097c50703dd96e4f453c6c118fd5d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/423514
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Detect rotate instructions while still in architecture-independent form.
It's easier to do here, and we don't need to repeat it in each
architecture file.
Change-Id: I9396954b3f3b3bfb96c160d064a02002309935bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/421195
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
Reviewed-by: Ruinan Sun <Ruinan.Sun@arm.com>
Run-TryBot: Keith Randall <khr@golang.org>
From the append docs in the builtin package:
As a special case, it is legal to append a string to a byte slice, like this:
slice = append([]byte("hello "), "world"...)
Change-Id: Ib14039a7476873b12a3aefccd8863e8d628b9249
Reviewed-on: https://go-review.googlesource.com/c/go/+/425102
Reviewed-by: hopehook <hopehook@qq.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
